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

"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).

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