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
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma