Missing claims due to backend error

[Victor Herraiz]

As in the documentation:

By requesting Claims as Essential Claims, the RP indicates to the End-User that releasing these Claims will ensure a smooth authorization for the specific task requested by the End-User. Note that even if the Claims are not available because the End-User did not authorize their release or they are not present, the Authorization Server MUST NOT generate an error when Claims are not returned, whether they are Essential or Voluntary, unless otherwise specified in the description of the specific claim.

• How should the OP behave in case of an error retrieving some of the requested claims?
• and if every claim retrieval fail?

‌

[Christian]

Since it is an error during a UserInfo-endpoint request I’d go with:

‌

5.3.3. UserInfo Error Response

When an error condition occurs, the UserInfo Endpoint returns an Error Response as defined in Section 3 of OAuth 2.0 Bearer Token Usage [RFC6750]. (HTTP errors unrelated to RFC 6750 are returned to the User Agent using the appropriate HTTP status code.)

‌

[Michael Jones]

If it’s possible for the server to simply not return the claims that it couldn’t obtain for any reason, but to return a successful authentication response, that’s nearly always preferable, as it gives RPs the maximum flexibility to handle the situation in the best way for it and the end-user. That said, if the situation reflects a true server error and you want a total failure to result, you can always return the HTTP 500 Internal Server Error error code.

[Victor Herraiz]

Thank you,

could the same answer apply to the id_token JWT?

[Victor Herraiz]

Michael, If we do not fail on a backend error there will be no difference between: we do not have the claim and we encounter a problem retrieving the claim.

[Victor Herraiz]

Any more feedback about this topic?

[Michael Jones]

Omitting claims that you can’t obtain but still returning a successful response is certainly preferably. Relying parties already have to be written to cope with missing claims, so that course of action shouldn’t require any extra work on the part of RPs. Whereas returning a hard error, such as 500 is unrecoverable and will result in confusing and frustrating user experiences.

I believe we should close this issue shortly on that basis.

[Michael Jones]

Closing during the 14-Jun-21 working group call, per the rationale cited in the comments.