Messages 2.1.1.1 and 8.1 - MTI features for OpenID Request Object and Request File

[Michael Jones]

There's an active discussion going on about whether the OpenID Request Object and Request File should be mandatory to implement for OPs.

If the Request Object is not, we would need to define alternative MTI OP behaviors, likely including how to handle max_age, auth_time, preferred_locales, acr, requests for specific claims, and possibly other features that are currently enabled by the Request Object.

I realize that we're not likely to forget this, but I still wanted to file this bug for us to track the issue, because resolving it is likely a blocker for the Implementer's Drafts.

[Michael Jones]

Per the working group decision on 4-Feb-13, Mike will refactor the request object to create a separate "claims" request parameter that is unsigned JSON and move the other request object parameters to be top-level parameters. Then the request object becomes a potentially signed collection of top-level parameters, with simple processing rules.

We expect this to help us move towards consensus on the MTI issues.

[Nat Sakimura]

Unlike currently specified, in addition to adding the new claims top level parameter, I would like to propose to change the processing rule as follows:

1. If the scope include 'openid", the start OpenID Connect processing. If not, it is out of scope.
2. If 'request' parameter is present, disregard all the query parameters and just read everything including scope etc. out of request object.
3. If 'request_uri' parameter is present, disregard all the query parameters but the 'state', 'nonce', 'id_token_hint', and 'login_hint'. This is because request file may be static (probably registered at the registration time to the authorization server) so that these dynamic parameter cannot be in the request file.

[Michael Jones]

Fixed #748 - Promoted "claims" to being a top-level parameter

→ <<cset d73e22ec3574>>

[Michael Jones]

Re-opened, since we still need to determine what features are going to be MTI.

Also, Nat's request_uri proposals below still need to be discussed.

[Michael Jones]

Fixed #748 - Changed OpenID Request Object processing rules so that the Request Object parameters are combined with those passed as OAuth 2.0 parameters, with the Request Object parameters taking precedence.

→ <<cset 06059e9049d2>>

[Michael Jones]

Reopened since we still need to resolve what features will be MTI for servers.

[Michael Jones]

We will apply the decisions made during the 25-Feb-13 spec call. The notes were:

MTI Discussion: We went through the MTI lists in 9.1 and 9.2 Breno suggested that we repeat the MTI response_types from 2.1.1.1 in 9.1 Breno suggested that we write a comprehensive section on re-authorization We will say in 9.1 that ui_locales and claims_locales must not result in errors We will say in 9.1 that acr_values must not result in errors Tim stated that the spec should specify the use HTTP caching for the request_uri values

Breno would like more data on whether Request Object and request_uri should be MTI
    Mike will talk with Chuck on Thursday
There was general agreement that we could drop the "request" parameter from MTI
Breno suggested moving the request_uri MTI requirement to dynamic providers (9.2)
Nat suggested that request_uri could only be MTI when pre-registered
Breno suggested that we only need to support request_uri one way to be compliant - 
    with pre-registered URIs or with dynamic URIs
We decided to move request_uri MTI for dynamic OPs and remove the request parameter from MTI

[Michael Jones]

Fixed #748 - Defined MTI features for OPs.

→ <<cset fbb0dafc2789>>