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

Issue #748 resolved
Michael Jones created an issue

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)

  1. Michael Jones reporter

    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.

  2. 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.
  3. Michael Jones 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.

  4. Michael Jones reporter

    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>>

  5. Michael Jones reporter

    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 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
  6. Log in to comment