Redirect URI is ambiguous in claims gathering flow

[jricher]

§3.4.1.2.2 details using a user redirection as a means of claims gathering. It uses the redirect_uri parameter to direct the user back to the client, and it says that this value "must match" something, but it doesn't define clearly enough what it must match. If this is intended to be the redirect_uri defined in the OAuth client model, then this conflates processing responses from the authorization endpoint and responses from the remote RQP claims gathering endpoint. This is not likely the desired behavior, and the spec should specify a separate field from the client model. The best way to do this would be to extend the model as defined in the OAuth Dynamic Client Registration document, perhaps claims_redirect_uri.

The current text:

redirect_uri
    OPTIONAL. The URI to which the client wishes the authorization server to direct the requesting party's user agent after completing its interaction. The URI MUST be absolute, MAY contain an "application/x-www-form-urlencoded" formatted query parameter component that MUST be retained when adding addition parameters, and MUST NOT contain a fragment component. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint. If the URI is pre-registered, this URI MUST exactly match one of the pre-registered redirection URIs, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison).

[jricher]

As a note, this is not really 1.0 errata as it would require extension of the OAuth client model in a potentially incompatible fashion.

[xmlgrrl]

Proposed, discussed, and reviewed in UMA telecon 2015-08-27 (though the WG definitely needs to review closely over the next week). We can close this, presuming Maciej has already implemented amendments made on the call.

[jricher]

In §3.6.2.2, the reference to claims_redirect_uri is still ambiguous. Proposed new text:

claims_redirect_uri
    OPTIONAL. The URI to which the client wishes the authorization server to direct the requesting 
party's user agent after completing its interaction. The URI MUST be absolute, MAY contain an 
"application/x-www-form-urlencoded" formatted query parameter component that MUST be retained 
when adding addition parameters, and MUST NOT contain a fragment component. The authorization 
server SHOULD require all clients to register their claims redirection endpoints prior to utilizing the 
claims endpoint (either using a static process or through [RFC7591] or [OIDCDynClientReg]). 
The claims redirection URIs of a client MUST be registered distinct from the client's redirection
URIs as used at the authorization endpoint during redirect-based OAuth flows. If the URI is 
pre-registered, this URI MUST exactly match one of the pre-registered claims redirection URIs, with the 
matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison).

Also I would say it MUST (not SHOULD) require registration otherwise it's an open redirector.

[jricher]

Same notes for later text in the section talking about "redirection URI", they should all be "claims redirection URI" to be disambiguated from the normal redirection URI.

[jricher]

Additional new text needed in §7.1, with particular mention that claims_redirect_uris is distinct from redirect_uris.

[xmlgrrl]

In UMA ad hoc telecon 2015-09-08 (which had quorum), this was the discussion and conclusion:

"The changes would, we feel, convince a quick reader used to OAuth spec reading that this redirection URI is something distinct!"

We'll keep the change and close the issue.