Why are there two different ways to request acr?

[Brian Campbell]

A client can request acr using the acr_values parameter of the request or with the claim parameter of the request using id_token.acr.values.

In the former case it's a space delimited list and in the latter is a JSON array. The latter also necessitates the definition of the values member of an individual claims request, which isn't otherwise needed AFAICT.

I don't see the value in having two different ways to do the same thing? Can it just consolidate to using the acr_values parameter? It's simple in that it can be just a query parameter but it also can be signed/encrypted using the request object. Seems like it covers everything that's needed.

Using the claims request parameter does allow acr to be marked as 'Essential' but I don't see that there's any actual difference in behavior, per messages 2.6.1, "the Authorization Server MUST NOT generate an error when Claims are not returned, whether they are Essential or Voluntary."

BTW, which one takes precedence, if they are both present?

[Michael Jones]

It can be requested as a claim because it is a claim and that's general-purpose claim request behavior. However, not all implementations support requesting individual claims.

Therefore, we have an acr_values request parameter to request this even when individual claims requests aren't supported.

We could define which takes precedence if both methods are supported. Or we could say that the behavior is unspecified if both are used and the requested values differ. Or we could just say that using both is an error.

[Brian Campbell]

Well, there are lots of claims in an id_token that don't make sense for general-purpose claim request behavior - iss, aud, iat, nonce, auth_time (with a value), at_hash, c_hash, jump out for example. I still prefer to have only one way of requesting acr.

But if it must stay, defining precedence is good. I'd think acr_values should be preferred. Or calling it an error when both are used.

[Michael Jones]

We will say that it the behavior is unspecified if ACR values are requested by both mechanisms and that servers should return an error in this case.

[Michael Jones]

Fixed #866 - Two different ways to request acr

→ <<cset 3ea54420f1f3>>