Should not fail an Auth server when cannot meet the `acr_values`?

[Jorge Oliva Fernandez]

From the specification is very clear for me that use of the acr_values is a "Voluntary" way of request claims (1) and also that a "Voluntary claim" is just a way to notify that a claim is useful for the RP (2), consequently seems like Authorization Server should not fail if is not able to provide this "Voluntary claim" what makes sense for me for example in the case that RP request a claim like birthdate and the OP didn't know the value of this claim or End-User doesn't consent this claim... but for the case of the acr claim when using the acr_values the spec indicate that this are the values that the Authorization Server is being requested to use for processing the request (4), what means that Auhtorization server more than probably try to ask the End-User to authenticate using the authentication methods that fulfils the requested acr and if the End-User cannot fulfil like in any other interaction the Authorization Server i guess that this should fail.

So my concrete question is, can an OP fail if the RP use the acr_values and when try to make End-User use the authentication methods (the one that meet this acr), End-user fail to authenticate or is not able to authenticate with this method?

An example would be, an RP request the acr_values=psw+otp and the OP present the pwd screen, End-User enter pwd correctly, then the OP present the OTP screen but End-User cannot provide this proof (because he lost the OTP device or any other reaso

n…), can the Auth Server return an error in this situation? If not what should be the behaviour in this case?

References:

1. In section 3.1.2.1. Authentication Request in acr_values definition say "The acr Claim is requested as a Voluntary Claim by this parameter."
2. In section 1.2. Terminology "Voluntary Claim: Claim specified by the Client as being useful but not Essential for the specific task requested by the End-User."
3. In section 5.5.1.1. Requesting the "acr" Claim say "If the Claim is not Essential and a requested value cannot be provided, the Authorization Server SHOULD return the session's current acr as the value of the acr Claim."
4. In section 3.1.2.1. Authentication Request in acr_values definition say "specifies the acr values that the Authorization Server is being requested to use for processing this Authentication Request,"

‌

[Tom Jones]

I think you are expecting too much from OIDC. It was designed in a simpler time when evanescent connections were not typical. It really worked well for SSO. Web Auth was actually designed to operate directly between the user and RP w/o engagement by the IDP. Now the mix is unpredictable and the onus is on the RP to meet privacy requirement.

Don’t forget that all authz is local to the server that contains the resource. If the conditions for entry are not met, access is not granted irrespective of what an IDP or user might expect. Zero trust architecture is the buzz word of choice today.

‌

[Joseph Heenan]

So this is an interesting question that recently got a bit more complicated:

Firstly, as 5.5.1.1 is a ‘should’ (i.e. similar to “recommended”) you can (if you feel you have a good reason to do so) ignore that recommendation and still be considered technically compliant with the specification.

However the stepup authentication draft in IETF, https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-06.html#section-5, says:

Although [OIDC] leaves the authorization server free to decide how to handle the inclusion of acr in ID Token when requested via acr_values, when it comes to access tokens in this specification it is RECOMMENDED that the requested acrvalue is treated as required for successfully fulfilling the request.

i.e. a failure to comply with an acr_values request is recommended to result in an error (the opposite of the recommendation in OIDCC 5.5.1.1).

‌

So to answer your question:

So my concrete question is, can an OP fail if the RP use the acr_values and when try to make End-User use the authentication methods (the one that meet this acr), End-user fail to authenticate or is not able to authenticate with this method?

Yes, it seems okay for an OP to do that.

[Nat Sakimura]

OIDC allows either 1) Returning a successful response with actual acr values. 2) Returning an error

In the case of 1), the RP can check the returned acr value and perform necessary step-up authentication. This is the recommended behavior in the case of OpenID Connect.

[Jorge Oliva Fernandez]

Thank so much for the responses,

I'm going to review the step up authentication draft but now looks very clear for me that OIDC recommend return a successful response with actual acr values but returning an error is still ok.

Best regards.

[Michael Jones]

This appears to be ready to close. Let’s plan to do so during the Friday federation editors' call unless a reason is stated to keep it open before that.

[Michael Jones]

Closing, since no reason was stated to keep it open after it was marked "Pending Close" in June.