What should the claims field hold?

[Takahiko Kawasaki]

“6.4. Query Status of a Grant” explains the claims field as follows.

• claims: JSON array containing the names of all OpenID Connect claims (see [OpenID]) as requested and consented in one or more authorization requests associated with the respective grant.

What should the claims field hold when claims contained in the ID token and the UserInfo response are different from the consented ones? For example, the user may permit the profile scope and the special scope is expanded to name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at claims (cf. OIDC Core Section 5.4). However, it is rare that all the claims are included in the ID token and/or the UserInfo response.

Should the claims field contain all the consented claims even when they are not actually included in the ID token and the UserInfo response?

[Torsten Lodderstedt]

JSON array containing the names of all OpenID Connect claims (see [OpenID]) as requested by the client (acting as OpenID Connect RP) and consented by the End-User in one or more authorization requests associated with the respective grant.

[Jacob Ideskog]

Yes, it would be difficult if the GM response would try to answer what was issued in the tokens, it should only respond with what was granted by the user IMO. Token issuance is a separate concern for the AS/OP.

[Dima Postnikov]

Suggested wording added to this pull request: https://bitbucket.org/openid/fapi/pull-requests/289

[Brian Campbell]

`claims`: JSON array containing the names of all OpenID Connect claims (see [@!OIDC]) as requested by the client (acting as OpenID Connect RP) and consented by the End-User in one or more authorization requests associated with the respective grant. still seems like it could be potentially interpreted as requiring OIDC scopes to be 'expanded' into claims.

[Takahiko Kawasaki]

When special scopes (profile, email, address, phone) are included in the scope request parameter, some authorization servers may obtain consent on each of expanded claims one by one while others may skip the step and regard that the user has consented on all expanded claims. In addition, because authorization server implementations do not always support all the standard claims, even if the implementations adopt the policy “regard that the user has consented on all expanded claims”, the resultant set of consented claims may be different from the claim sets defined in OIDC Section 5.4. For example, if an authorization server supports only family_name and given_name claims, the result of expanding the profile scope will be just [family_name, given_name] and will not become [ name, family_name, given_name, middle_name, …].

I now feel that the specification should accommodate the implementation variants described above and that the exact definition of “consented claims” should be left to implementations. Although I created this issue, I now think that it will be wise to avoid trying to describe a strict definition of “consented claims”. In short, the current description seems to work without modification.

[Dima Postnikov]

Should we just add: “the definition of consent claims s left up to implementations when special scopes are used (e.g. profile). “

[Dima Postnikov]

PR merged