Thanks for sending these, James. I hadn't actually captured them in the minutes (my bad).

Regarding the second question, this is exactly where I think we need to apply some caution and forward thinking. As noted in the final question in the minutes, trust elevation is a broad topic and claims are not the only mechanism possible; extensibility is important to account for. (Unless Justin's use of "claims" is meant to deliberately broaden well past its current definition? It applies exclusively to RqPs now.)

Other mechanisms we've discussed:
See also issue #249, wherein I discuss wanting a claims-like mechanism for Client Operators so that Alice can constrain uses of her data when it comes to the companies operating the apps she uses. (This straddles technical and legal topics.)


Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


On Thu, Jun 30, 2016 at 10:30 AM, 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?
  • 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)?
Cheers
James

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma