Messages 5.1.3 - Behavior of "acr" as an Essential Claim

[Michael Jones]

There's currently a contradiction between our statements about "acr" as an Essential Claim, which requires an error to be returned if a requested "acr" value can't be provided and our general statements about claims, which say that an error should not be returned if a claim can't be provided.

PAPE worked not by returning an error, but by requiring that the returned "acr" value reflect reality. I think that's we should do for Connect too.

5.1.3 says:

If the acr Claim is requested as an essential Claim in the id_token member with values as a parameter, the Authorization Server MUST return an acr Claim value that matches one of the requested values. The Authorization server MAY ask the user to re-authenticate with additional factors to meet the requirements. If this is an essential Claim and the requirement cannot be met, then the Authorization Server MUST return an error. The Client MAY make this Claim optional by not including "essential": true in the acr Claim request. If the Claim is not essential and the requested value for the user cannot be provided, the Authorization server SHOULD return the session's current acr as the value of the acr Claim. If the Claim is not essential, the Authorization server is not required to provide this Claim in its response.

Whereas, 2.1.1.1.3 says:

By requesting Claims as essential, the client indicates to the user that releasing these claims will ensure a smooth authorization for the specific task requested by the user. Note that even if the claims are not available because the user did not authorize their release or they are not present, the Authorization Server MUST NOT generate an error when essential claims are not returned.

[Vladimir Dzhuvinov]

What was the original intent for requiring an error to be returned?

Was that to check if a particular ACR is supported? Clients now have a chance to find out if a desired ACR is supported in Discovery and Registration.

Also, I could imagine that the OP does not return at all to the client if the requested authentication level is not supported or fails to be performed.

From that perspective it looks like the special error requirement for "acr" could be safely dropped and its treatment made consistent with the others.

[Michael Jones]

We can add language saying that the OP may fail the authentication if essential acr requests can't be satisfied.

[Michael Jones]

Fixed #763 - OPs MUST treat the inability to return an Essential requested "acr" Claim value as a failed authentication attempt

→ <<cset 26126ebb1e53>>