Re: [WG-UMA] Questions about MPD

I think you’re confusing the authorization grant with the authorization code, which is one mechanism used as part of an authorization grant. The authorization grant is really a concept — it’s “what you do to get a token”, and so the ticket qualifies. The text in the OAuth2 spec is confusing to say the least, it’s something that the community wrestled with for ages and I’m personally not that much of a fan of the results. I’m not sure where you’re getting that the user doesn’t need to log in to use the authorization endpoint, as the text very explicitly states:

The authorization server MUST first verify the identity of the resource owner.

So translating this to UMA, that means that the RqP MUST be identified to use that endpoint. This is fine in the narrow ecosystem deployments where all the users have an account at the AS (which is what I understand to be ForgeRock and Gluu’s current deployments), but it’s problematic in wide deployments where Bob’s never heard of Alice’s AS and vice versa. But mostly it’s problematic if you’ve got an existing OAuth server, which is almost certainly going to require an authenticated session to use the authorization endpoint. This is the reason we couldn’t really deploy UMA with AAT’s as intended in our use case, because the RqP doesn’t have an account capable of generating plain OAuth tokens. And honestly we don’t *want* external people to be able to come in and generate arbitrary plain OAuth tokens, so that would require us to have all kinds of special hooks and checks to make sure that they’re generating only the “right” kind of token. All said, it’s ridiculously complicated and not something I’d want to implement. And if the RqP can make a plain OAuth token — well then again I say, don’t use UMA, use OAuth. You’re arguing to remove permission tickets and have the requesting party start at the authorization server and use the authorization endpoint. What does UMA buy you in that case? Nothing that I can see — you’re not really doing UMA at all anymore. What you’re describing is OAuth, but with Alice being able to set a policy at the AS that identifies and allows Bob to access stuff. In other words, Alice can turn Bob into an OAuth resource owner. That’s great, I can build that into my OAuth server and call it a day! But it’s not UMA anymore, and I think it’s confusing to style it as such. — Justin

On Jun 30, 2016, at 5:03 PM, James Phillpotts wrote:

I'm not sure I agree about the authorize endpoint. The appropriate bits from the OAuth2 spec are:

1.3 https://tools.ietf.org/html/rfc6749#section-1.3. Authorization Grant

An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines [...] an extensibility mechanism for defining additional types.

and

3.1 https://tools.ietf.org/html/rfc6749#section-3.1. Authorization Endpoint

The authorization endpoint is used to interact with the resource owner and obtain an authorization grant. The authorization server MUST first verify the identity of the resource owner. The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.

There is nothing here that specifies that the resource owner has to be able to login to the authorization endpoint, where as it is clear that the permission ticket does not qualify as an Authorization Grant.

I think it would be perfectly reasonable to use the authorization endpoint first, order to obtain a code grant that can then be exchanged for the token. The AS would have the opportunity to redirect to the claims gathering endpoint.

If you really don't think it fits with the authorization endpoint, I would prefer we consider adding a different endpoint - the permission ticket just isn't an authorization grant - I don't see how we can get around that.

Cheers James

On 30 June 2016 at 21:28, Justin Richer mailto:jricher@mit.edu> wrote: Addressing these two inline:

...

On Jun 30, 2016, at 1:30 PM, James Phillpotts mailto:james.phillpotts@forgerock.com> wrote:

Hi all,

As per chat in the join.me http://join.me/ session, I have a couple of questions/observations about the MPD flow we have been discussing: Why are we using the Authorization Grant for the ticket, which is actually the context for the forthcoming authorization that the AS has to assert? Should we be initiating the Client's interaction with the AS at the Authorize endpoint, rather than the token endpoint?

Sending the RqP to the authorization endpoint presumes that the AS allows the RqP to log in and use the normal OAuth flow. This is the same assumption made with the AAT, and it’s precisely something I think we need to get away from. Additionally, the functionality required at the claims endpoint is beyond what’s required at the authorization endpoint.

I think it would be an interesting optimization for the client to send the RqP straight to the claims endpoint first instead of going to to the token endpoint and being told need_info. There’s absolutely nothing in the current MPD protocol design that precludes this, actually, it’s just not how clients have been written to date.

...

How can the Client maintain a "token session" for Bob so that he doesn't have to reassert claims (and potentially, consent for claim use) every time he gets a new ticket for a future request? It was suggested after the call ended that we could send a consent token that the Client can send back with future requests. Could we issue a signed jwt token (analagous to OpenID Connect id_token, but issued by the UMA AS for presentation back to it, complete with all claims thus far acquired)?

The content and structure of such a token should be completely up to the AS, since it’s issued by and read by the AS and only carried by the client. It could be a structured token, or it could simply be a reference to an internal stateful data store at the AS. Both ought to be valid options and I see no reason that we need to specify this.

— Justin

...

Cheers James _______________________________________________ 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