Clarification on handling of standard claims in request object

[AG-IAM]

Description

The "claims_supported" attribute in the DH metadata configuration shows the list of claims supported by DH.

How the additional claims not supported by DH be handled at DH's end?

In the below link, the section "Supporting claims" , mentions ADR to identify the claims supported by DH before constructing Request object. Can this be added in the standards? https://cdr-support.zendesk.com/hc/en-us/articles/5081838045967-Guidance-for-Profile-Scope-and-Standard-Claims

Area Affected

The /token call to DH fails with Invalid claims error when the claims not supported by DH are present in the request object.

Change Proposed

ADRs should identify the claims supported by the data holder before creating a consent request. If the data holder does not support the claim(s), the ADR should not include the claim(s) in the request to the data holder.

[perlboy]

If a Data Holder is failing to provide a token because unsupported claims were requested it is non compliant. In fact I'm not aware of any valid invalid_claims oauth2 error code.

From the OIDC specification 5.3.2:

For privacy reasons, OpenID Providers MAY elect to not return values for some requested Claims. If a Claim is not returned, that Claim Name SHOULD be omitted from the JSON object representing the Claims; it SHOULD NOT be present with a null or empty string value.

And from 5.5:

Any members used that are not understood MUST be ignored.

The Standards also say:

Other [OIDC] Standard Claims MUST be ignored and not authorised.

A Holder rejecting on the specified basis above is non-compliant and should rectify their implementation.

[jimbasiq]

Thinking from a "serving the consumer" perspective, we should aim to be as resilient as possible in our implementation. It makes sense to me that any invalid claims should be thrown on the floor by the DH and they should process the request to the best of their ability.

[CDR-CX-Stream]

This issue was discussed in the MI19 meeting on 15 May 2024. There was general consensus that a standards change requiring ADRs to identify the claims supported by the data holder before creating a consent request is not necessary. This is already an expectation as outlined in the Guidance for Profile Scope and Standard Claims.

It was preferred that further guidance regarding how data holders handle requests for unsupported claims be provided instead.

According to OIDC specifications, “If a Claim is not returned, that Claim Name SHOULD be omitted from the JSON object representing the Claims; it SHOULD NOT be present with a null or empty string value” (5.3.2, as noted in perlboy’s comment) and "Other members MAY be present. Any members used that are not understood MUST be ignored" (5.5). This implies that unsupported claims should be ignored and that an authorisation request should not fail if unsupported claims are present.

Current CDR guidance indicates if a data holder does not offer the optional phone number, email address and mailing address related claims, they should ignore this requested claim during authorisation and do not need to show the Contact Details data cluster in the authorisation flow.

The DSB are seeking further input from the community whether more guidance is required or a standards change is necessary.

[CDR-CX-Stream]

Update from MI19 meeting on 29 May 2024:

• Participant asked if there are other examples where unsupported scopes may happen, and how this might change with Rich Authorization Request (RAR) and purpose based consents.
• There was also a query on whether there was a need for data holders to build some logic into authorisation screens. If so, there may be need for more than just guidance. DSB noted that there potentially may be expectation for this.
• General consensus was guidance is appropriate to resolve this issue based on the assumption it's addressing edge cases, if not then a closer look at the standards would be required.
• ACTION: DHs to compare what is advertised on OpenID configuration with authorisation requests to determine if any discrepancies exist and whether ADRs are checking endpoints before requesting unsupported claims.
• ACTION: DSB to continue analysis of how ADR and DH should handle unsupported scopes in different scenarios, including the considerations mentioned above.