Messages 2.1.1.1 and 8.1 - MTI features for OpenID Request Object and Request File
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.
Comments (8)
-
reporter -
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:
- If the scope include 'openid", the start OpenID Connect processing. If not, it is out of scope.
- If 'request' parameter is present, disregard all the query parameters and just read everything including scope etc. out of request object.
- 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.
-
reporter - changed status to resolved
Fixed
#748- Promoted "claims" to being a top-level parameter→ <<cset d73e22ec3574>>
-
reporter - changed status to open
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.
-
reporter - changed status to resolved
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>>
-
reporter - changed status to open
Reopened since we still need to resolve what features will be MTI for servers.
-
reporter -
assigned issue to
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
-
assigned issue to
-
reporter - changed status to resolved
Fixed
#748- Defined MTI features for OPs.→ <<cset fbb0dafc2789>>
- Log in to comment
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.