Dear Vittorio,
Thank you for your explanation. I could understand the intention. No strong
opinion from my side, meaning I won't insist the spec should be modified.
One concern behind my suggestion was that the recommended way slightly
conflicts with the following paragraph in OIDC Core 1.0.
*"No
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
"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 *c
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 :
> Hi Takahiko,
> thanks for the comment!
> The use
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 havin
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,"v
