5.3 (ed) The title is confusing and the last two belongs to a later section.

Rationale

5.3 is a setup phase for the OP to obtain an access token (and refresh token) to obtain the current user's claims from CP. By doing so, the user can avoid making new grant dialogue at every RP request. Just marking it as “Authentication Request” does not help readers to understand what is going on here.

Accordingly, the content need to be updated as well.

Proposal

Change the title from “5.3 Authentication Request” to “5.3 OP User Setup Phase at the CP”

Additionally, replace the content as follow.

5.3.1 The OP making an Authorization Request to the CP to obtain Access Token and Refresh Token

In this phase, the OP obtains an access token (and optionally refresh token) that is bound to the current user so that the OP can obtain the claims about the current user from the CP subsequently without taking the user to the CP and show them the consent dialogue for every RP requests.

Authentication requests to the CP by the OP are made using the OpenID Connect Authorization Code Flow with PKCE [@RFC7636] or FAPI 1.0 Advanced Security Profile.

Requests for specific claims MUST be made using scope values, claims values, or and/or Request Objects in the Authentication Request.

The CP MUST show the dialogue to the user to obtain their grant.

After obtaining the grant, the CP returns code that is used by the OP to access the token endpoint to obtain Access Token and Refresh Token if possible. These tokens are used in the RP Request Phase.

5.3.2 OP specifically asking claims to be returned from the Claims Endpoint of the CP

defines the following top-level member to the Claims request JSON object:

c_token Optional. Requests that the listed individual Claims be returned from the Claims Endpoint. If present, the listed Claims are being requested to be added to any Claims that are being requested using scope values. If not present, the Claims being requested from the Claims Endpoint are only those requested using scope values. This top-level member is a JSON object with the names of the individual Claims being requested as the member names and the values are defined as in 5.5.1 of OpenID Connect 1.0 OIDC.

OpenID Claims Aggregation supports the requesting of additional claims and verified claims defined in OpenID Connect for Identity Assurance 1.0 OpenID.IDA for the c_token member of the Claims request JSON object.

When the c_token member is used, the request MUST also use a response_type value that results in an Access Token being issued to the Client for use at the claims endpoint.

‌

Rationale

Proposal

Comments (1)