Core 5.5 - Claims parameter requirements

[Mark Haine]

In Section 5.5 it is not clear whether all implementations should support both openid and userinfo as ways for specific claims to be returned. It also does not state that the claims request parameter must have at least one of the top level elements. There are cases where support for one or other only may be desirable.

There is a companion issue #1228 raised to add an additional item of metadata to the discovery spec in support of this.

This issue has emerged due to work being done on both SIOP and eKYC & IDA

‌

Initial draft wording to add…

“When the claims parameter is supported one or more of the available top-level members must be present

The claims_responses_supported Discovery result indicates which of the top-level members of the claims request the OP supports.”

[Tom Jones]

why wouldn’t scope be sufficient in many cases?

[Michael Jones]

The claims request parameter is not mandatory to implement (MTI). There is a claims_parameter_supported Discovery value saying whether an OP supports it or not. If you support this, you should support its parameters.

[Michael Jones]

Note that since claims is defined in a final specification, we cannot make normative changes to its description.

[Mark Haine]

Problem statement:

Section 5.5 of OpenID core is unclear about the requirement for top level elements of the claims request parameter.  This results in a risk that OpenID provider implementations may exhibit different behaviour in this regard.  This could mean that a relying party may need to apply different logic depending on which OpenID provider they are interacting which would be an interoperability issue.

Proposal:

The intent is to clarify behaviour of an optional element of OIDC Core in order that interoperability of implementations is more certain.

The proposed clarification does not change behaviour of mandatory elements of OpenID Connect Core and we have confirmed that there would be no impact relating to conformance and certification of OpenID Connect Core or FAPI, and no impact on known uses of the claims request parameter such as Open Banking UK and the yes.com ecosystem.

The proposed changes will be delivered as erata for future inclusion as the feature involved (the claims request parameter ) is defined in OIDC Core and the changes are clarifications of that feature’s behaviour.

Next step:

Write a PR with the proposed changes

[Nat Sakimura]

On 2021-06-17 call, it was clarified that this issue is asking for clarification on the claims parameter if only one of the userinfo or id_token members are required or if both or none are.

[Michael Jones]

As discussed during the 17-Jun-21 working group call, it’s already the case that OPs can return the claims that make sense in the context no matter what claims the RP requested. Therefore, even if claims were requested for the ID Token and/or the UserInfo Endpoint, whether to supply those claims is at the discretion of the OP - including the OP having the option to not return them at all.

I’ll review the current spec language to make sure that this is already clear.

[Nat Sakimura]

Any updates? @Michael Jones

[Michael Jones]

It seems to me that there’s enough language in the description of the “claims” parameter to make it clear that support is optional and that if individual “claims” members are not understood, one can ignore them as well. For instance, the spec says “Other members MAY be present. Any members used that are not understood MUST be ignored.“

Also, “Support for the claims parameter is OPTIONAL. Should an OP not support this parameter and an RP uses it, the OP SHOULD return a set of Claims to the RP that it believes would be useful to the RP and the End-User using whatever heuristics it believes are appropriate.“

And “For privacy reasons, OpenID Providers MAY elect to not return values for some requested Claims.“

In short, there’s lots of text telling RPs that the claims they request may not be the set that they receive, and they need to be prepared for this eventuality. Also, OPs need to be prepared for claims requests that they don’t know how to fulfill, in which case they’re expected to something reasonable and hopefully useful, rather than treating it as an error condition.

No, that doesn’t provide a closed-form answer to your original question, Mark, but I think it does provide lots of useful guidance to implementations.

Are you OK with us resolving this issue on that basis, Mark?

[Mark Haine]

The original intent behind this issue and the companion issue #1228 was to help RPs by making it clear which top level elements of the claims request are supported in a particular implementation. It is not really about whether any of the scenarios are allowed at a protocol level.

I unxefrstand that it is nor realistic to implement a change to the Core spec but I think it would be useful to add something in to errata at some point to clarify this area for implementers and I think @Joseph Heenan has some wording in mind for that.

[Joseph Heenan]

I think we probably could give a little more guidance to RPs. This is otherwise is a bit of a minefield for interoperability if you’re trying to produce a generic RP (as opposed to one targeting one particular deployment/implementation) that uses the claims parameter.

The suggested text would be something along the lines of:

“There is currently no standard interoperable mechanism for an OP to indicate in whether it supports returning claims in the id_token, the userinfo, or both. OPs are free to support returning particular claims only in one location. Hence an RP wishing to achieve the best interoperability needs to request any claims to be returned in both the id_token and the user info, and to cope with the requested claims potentially only being returned in one of the requested locations.”

‌