Why are there two different ways to request acr?
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?
Comments (4)
-
-
reporter 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.
-
- changed milestone to Final
-
assigned issue to
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.
-
- changed status to resolved
Fixed
#866- Two different ways to request acr→ <<cset 3ea54420f1f3>>
- Log in to comment
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.