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

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.  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 <jricher@mit.edu> wrote:

Addressing these two inline:

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

Hi all,

As per chat in the 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
http://kantarainitiative.org/mailman/listinfo/wg-uma