"By reference": :)
1) There are two differences between acr_values and requesting acr as an
essential claim.
- the first one is that this document explicitly defines an oauth semantic
for *acr_values*, hence we define here the intended effect on the access
token. The same cannot be said for the *claims *parameter. To reiterate, we
did not bring *claims *in because it has A LOT more moving parts than what
is required to implement the stepup scenario.
- the second one is in how the two affordances are defined.
*acr_values* is defined as "Space-separated string that specifies the
acr values
that the Authorization Server is being requested to use for processing this
Authentication Request, with the values appearing in order of preference.".
It refers to the behavior of the authorization server, which is exactly the
semantic we want in the new scenario. All we are doing here is specifying
extra things we want to apply to the AT, without altering its syntax.
Requesting the acr claim is defined as... requesting the acr claim in the
ID token (the definition opens with "If the acr Claim is requested as an
Essential Claim for the ID Token") and applying the ACR is more of a side
effect (something that must be done in order to comply with the claims
request). The fact that the *claims *object has two top level members for
*id_token *and *userinfo *should make it clear beyond reasonable doubt that
it is not intended to affect access tokens, it only applies in cases where
an id_token is indeed present, etc etc.
2) per the above: the reason we don't mention it is not as much that it's
not very adopted or complex: it's that it pertains id_tokens specifically.
Not including it isn't disrespecting it, we are readily acknowledging the
OIDC origin of the primitives we are porting, it's that per the above the
claims syntax should be inconsequential in this context.
If you feel VERY strongly about it, we could add language in the deployment
considerations to preempt confusion on this point (e.g. reminding people
that the claims/essential mechanism defined in OIDC core is meant to work w
id_tokens and there are no guarantees it will have any effect on ATs, if
any). We'd rather not, mostly to adhere to the tenet of simplicity, but we
are interested in your take!
Thanks
V.
> On Thu, Nov 3, 2022 at 3:50 PM Takahiko Kawasaki <t...@authlete.com>
> wrote:
>
>> *This message originated outside your organization.*
>>
>> ------------------------------
>>
>> Thank you.
>>
>> 1) The same points are true to "acr_values".
>>
>> 2) The expressive power and popularity don't have to stop the spec from
>> kindly mentioning the standardized way which was defined 8 years ago.
>>
>> Taka
>>
>> 2022年11月3日(木) 22:04 Vittorio Bertocci <vitto...@auth0.com>:
>>
>>> Hi Takahiko,
>>> thanks for the comment!
>>> The use of the claims parameter for this use case is tricky.
>>> 1) if used as is, requesting a particular acr via claims isn't
>>> guaranteed to have any effect on the content of an access token, if an
>>> access token is even present: OIDC only defines the claims as having an
>>> effect on id_token and/or userinfo.
>>> 2) pulling in the claims parameter here would vastly exceed the scope of
>>> this specification, as the expressive power of claims goes well beyond
>>> requesting acr (possibly one of the reasons for which it doesn't enjoy
>>> widespread support) and defining its effects on access tokens would require
>>> a lot more work than what's needed to achieve the step up scenario.
>>> I hope this helps!
>>> Cheers,
>>> V.
>>> On Wed, Nov 2, 2022 at 10:30 AM Takahiko Kawasaki <t...@authlete.com>
>>> wrote:
>>>
>>>> *This message originated outside your organization.*
>>>>
>>>> ------------------------------
>>>>
>>>> Hello,
>>>>
>>>> If a client application wants to make the authorization server return
>>>> error=unmet_authentication_requirements when none of requested ACRs is
>>>> satisfied, the client application should request the "acr" claim as an
>>>> "essential" claim. A straightforward way is to embed
>>>> "acr":{"essential":true,"values":[...]} in the "claims" request parameter
>>>> (OIDC Core Section 5.5). (NOTE: the "acr_values" request parameter and the
>>>> "default_acr_values" client metadata cannot request claims as essential.)
>>>>
>>>> The draft of OAuth 2.0 Step-up Authentication Challenge Protocol
>>>> recommends that ACRs requested by the "acr_values" request parameter be
>>>> treated as required (= essential). The recommendation may be okay, but it
>>>> should be better for the specification to mention additionally that there
>>>> is a standardized way to request the "acr" claim as essential. That is, it
>>>> is better to introduce "acr":{"essential":true,"values":[...]} somewhere in
>>>> the specification.
>>>>
>>>> Best Regards,
>>>> Takahiko Kawasaki
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7JfV3rPtbY6zIZFPRwN30f70buuNs1WSBZIJ1vx5LBL5cXkhHMvSQpQpztdUVAc-TzcoRKGyRNTS$>
>>>>
>>>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
