No, that’s too proscriptive. If the client wants to use the same URI to do both, it should be allowed to. The important thing is that it’s two different values from the perspective of the AS. Thus two different field names in the client data model. The AS should never compare them to each other nor be given a hint that it should (as the text below suggests). — Justin

On Oct 17, 2016, at 4:18 AM, Eve Maler wrote:

Ah, okay. The rationale got lost in the shuffle. The original is in the right direction, but needs more explanation and disambiguation, I think:

"Because the claims redirection URIs of a client are intended for the exclusive use of requesting parties and not resource owners, if a client pre-registers redirection URIs at all, any claims redirection URIs must be different from any other redirection URIs to be used by the authorization endpoint during redirect-based OAuth flows."

Is this accurate?

Eve Maler (sent from my iPad) | cell +1 425 345 6756

On Oct 17, 2016, at 2:03 AM, Justin Richer mailto:jricher@mit.edu> wrote:

...

Yes, the separation is still very much necessary. Remember, we’re folding together the *back* channel and not the *front* channel, because the parties are different on the front channel in UMA vs. OAuth (namely, RqP vs. RO). The claims_redirect_uri and redirect_uri are all about returning data from the front channel. We’ve gotten rid of the rpt_endpoint because that was a special back channel endpoint that’s no longer necessary.

If we were using the authorization endpoint then we could use the same redirect_uri as in OAuth, but we’re not. Why aren’t we? Because then the RqP would need to be treated much like a RO at the resource server — which is to say, Bob needs to be treated like Alice. But it’s not Bob’s server and we can’t (and shouldn’t) assume that he’ll be treated the same as she will. Recall that this mistaken assumption is at the core of deployment issues with the AAT for anything beyond a very narrow ecosystem where everyone is using the same AS.

— Justin

...

On Oct 16, 2016, at 2:17 PM, Eve Maler mailto:eve@xmlgrrl.com> wrote:

Cigdem did a close reading of the spec draft, for which I'm grateful. In addition to finding an error in the config data example that I was able to fix in the forthcoming rev 05), she also noticed some ambiguous language here:

Sec 3.6.2 rev 04 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-04.html#rfc.section.3...: "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 additional 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 (either using a static process or throughRFC7591 (at line 1749) 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 (at line 1756) (Simple String Comparison)."

She commented: "Section 3.6.2, in the “claims_redirect_uri” description, I was a bit confused about what is a MUST and what is a should? Is it a MUST that the client pre-registers the claims_redirect_uri? Then the sentence, “If the URI is pre-registered” should not have an If?"

First, we could improve the language generally to do away with the passive and ambiguity (some of which came from the original OAuth passage https://tools.ietf.org/html/rfc6749#section-3.1.2).

But second, is it still necessary for us to be segregating UMA client redirect callback URIs from OAuth client callback URIs? With an UMA client adhering to a formal UMA extension grant of OAuth soon enough, will it be a distinction without a difference?

Here's a revision that attempts to fix the former problem and also keep the original semantic, in case we need it. Changes bolded. The sentence in bold red could be removed if we think it's pointless now.

"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 the authorization server MUST retain when redirecting the requesting party back, whether or not it adds any other 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 (either using a static process or through RFC7591 or [OIDCDynClientReg]). If the authorization server does require clients to register redirection endpoints, it MUST require clients using UMA grants to register claims redirection URIs distinct from clients using other OAuth grants. If a client has pre-registered a URI, then the URI it supplies here MUST exactly match one of its pre-registered claims redirection URIs, with the matching performed as described in Section 6.2.1 of RFC3986 (Simple String Comparison)."

Discussion and comment welcome, especially prior to next Friday's call so that we can take care of this issue expeditiously. Thanks!

Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

After James pinged me with some comments suggesting more normative-ness in a specific direction, I thought I'd try out this variant: "Note that claims redirection URIs are different from regular OAuth redirection URIs in that they are intended for the exclusive use of requesting parties and not resource owners. Therefore, authorization servers MUST NOT redirect requesting parties to regular pre-registered OAuth redirection URIs unless such URIs are also pre-registered as claims redirection URIs." *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Oct 17, 2016 at 1:51 PM, Eve Maler wrote:

In that case, wouldn't the following be sufficient?

"Note that claims redirection URIs are distinct from regular OAuth redirection URIs; they are intended for the exclusive use of requesting parties and not resource owners."

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Oct 17, 2016 at 1:02 PM, Justin Richer wrote:

...

No, that’s too proscriptive. If the client wants to use the same URI to do both, it should be allowed to. The important thing is that it’s two different values from the perspective of the AS. Thus two different field names in the client data model. The AS should never compare them to each other nor be given a hint that it should (as the text below suggests).

— Justin

On Oct 17, 2016, at 4:18 AM, Eve Maler wrote:

Ah, okay. The rationale got lost in the shuffle. The original is in the right direction, but needs more explanation and disambiguation, I think:

"Because the claims redirection URIs of a client are intended for the exclusive use of requesting parties and not resource owners, if a client pre-registers redirection URIs at all, any claims redirection URIs must be different from any other redirection URIs to be used by the authorization endpoint during redirect-based OAuth flows."

Is this accurate?

Eve Maler (sent from my iPad) | cell +1 425 345 6756

On Oct 17, 2016, at 2:03 AM, Justin Richer wrote:

Yes, the separation is still very much necessary. Remember, we’re folding together the *back* channel and not the *front* channel, because the parties are different on the front channel in UMA vs. OAuth (namely, RqP vs. RO). The claims_redirect_uri and redirect_uri are all about returning data from the front channel. We’ve gotten rid of the rpt_endpoint because that was a special back channel endpoint that’s no longer necessary.

If we were using the authorization endpoint then we could use the same redirect_uri as in OAuth, but we’re not. Why aren’t we? Because then the RqP would need to be treated much like a RO at the resource server — which is to say, Bob needs to be treated like Alice. But it’s not Bob’s server and we can’t (and shouldn’t) assume that he’ll be treated the same as she will. Recall that this mistaken assumption is at the core of deployment issues with the AAT for anything beyond a very narrow ecosystem where everyone is using the same AS.

— Justin

On Oct 16, 2016, at 2:17 PM, Eve Maler wrote:

Cigdem did a close reading of the spec draft, for which I'm grateful. In addition to finding an error in the config data example that I was able to fix in the forthcoming rev 05), she also noticed some ambiguous language here:

Sec 3.6.2 rev 04 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-04.html#rfc.section.3... : "*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 additional 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 (either using a static process or throughRFC7591 (at line 1749) 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 (at line 1756) (Simple String Comparison)."

She commented: *"Section 3.6.2, in the “claims_redirect_uri” description, I was a bit confused about what is a MUST and what is a should? Is it a MUST that the client pre-registers the claims_redirect_uri? Then the sentence, “If the URI is pre-registered” should not have an If?"*

First, we could improve the language generally to do away with the passive and ambiguity (some of which came from the original OAuth passage https://tools.ietf.org/html/rfc6749#section-3.1.2).

But second, is it still necessary for us to be segregating UMA client redirect callback URIs from OAuth client callback URIs? With an UMA client adhering to a formal UMA extension grant of OAuth soon enough, will it be a distinction without a difference?

Here's a revision that attempts to fix the former problem and also keep the original semantic, in case we need it. Changes *bolded*. The sentence in *bold red* could be removed if we think it's pointless now.

"*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 *the authorization server MUST retain when redirecting the requesting party back, whether or not it adds any other 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 (either using a static process or through RFC7591 or [OIDCDynClientReg]). *If the authorization server does require clients to register redirection endpoints, it MUST require clients using UMA grants to register claims redirection URIs distinct from clients using other OAuth grants.* *If a client has pre-registered a URI, then the URI it supplies here *MUST exactly match one of its pre-registered claims redirection URIs, with the matching performed as described in Section 6.2.1 of RFC3986 (Simple String Comparison)."

Discussion and comment welcome, especially prior to next Friday's call so that we can take care of this issue expeditiously. Thanks!

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma