Dear Takahiko and Vittorio,
1. I may be digressing from the main thread, but since you mentioned about
returning error code
"unmet_authentication_requirements", I thought it appropriate to suggest
ammendments in the same thread.
2. We may need to elaborate a little more on how this error code is
returned to the client application as the same might be opaque to the
client application if included in the access token. Refer Section 1.4 of
draft OAuth 2.1 regarding access tokens being opaque to the client
applications.
"An access token is a string representing an authorization issued to the
client. The string is considered opaque to the client, even if it has a
structure."
3. Refer Section 5 of draft Step Up Authentication.
"That is, the requested acr value is included in the access token if the
authentication operation successfully met its requirements, or that the
authorization request fails in all other cases, returning
unmet_authentication_requirements as defined in [OIDCUAR]."
The phrase "authorization request" may be replaced by "authentication
operation" in the above quoted para as it is likely to create confusion
with the standard "authorization request" which may not include the acr
values.
Regards
Jaimandeep Singh
On Fri, 4 Nov, 2022, 12:27 pm Vittorio Bertocci, <vittorio=
40auth0....@dmarc.ietf.org> wrote:
>
> "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
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
