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

On 7/21/2016 4:10 AM, James Phillpotts wrote:

Sorry for leaving this thread hanging for so long - I've been thinking about it quite a bit.

I still don't much like the permission ticket as a grant (and no, Justin, I'm not confusing grant and code). Even if we don't use the authorization endpoint, I'd prefer that the RqP had to be sent with the ticket had to be taken to the claims gathering endpoint first and from there they get a token that they can use as a grant at the access token endpoint that shows that the ticket has been authorized.

When the client gets the ticket, it can go straight to the claims endpoint if it wants to without going to the token endpoint first. It could also push claims immediately if it wants to. The first, empty round-trip is the general case where the client is particularly dumb and does only what it's told to do next, and the truth is the client always has a choice at that stage.

That said, I don't feel disagree strongly with the way it's currently designed. The other half of the internal argument in my head has been "what about the case when Alice has made her resource public, so no claims are needed to grant access" - in this case, the permission ticket as given to the Client by the RS is sufficient to issue an access token, so why should the RqP have to be sent to a different endpoint first.

Correct -- if the policy is public, or if the client's identity is enough, then the ticket is all that's needed and you get the access token immediately on the first "empty claims" call to the token endpoint exactly as you describe.

Cheers James

PS - On the related discussion about authentication/login, RFC 4949 is worth a quick read for the definition of authentication vs login - the former being the verification of a claim about a system entity, where as the latter is an act in which the system entity acquires a session, generally through the authentication of certain claims it offers in that act (e.g. username/password). In this sense UMA claims gathering is a form of authentication, but not (necessarily) login.

I personally wouldn't even call the claims gathering endpoint an authentication event. Authentication is one of many ways the RqP can interact with the AS here, but far from the only. The claims being gathered may have nothing to do with the identity or authenticity of the RqP, though I agree that generally they are. This is in contrast to the OAuth authorization endpoint wherein the resource owner needs to be authenticated both as per the spec and as per every implementation I've seen. -- Justin

On 1 July 2016 at 18:08, Justin Richer mailto:jricher@mit.edu> wrote:

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 mailto:james.phillpotts@forgerock.com> 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

I don’t think this even needs to be a SHOULD. It’s entirely an internal implementation detail. — Justin

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

WRT the second question, you're right that we don't need to specify the form this takes, but we probably should describe that the AS SHOULD do so, and name the property of the token response that can be used for that purpose.

J.

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