Quorum was reached.
Approve minutes of UMA telecon 2017-01-26 and 2017-02-02: APPROVED.
AI: Eve: Schedule 90-minute meetings out through Mar 2, and propose an ad hoc on Tuesday Feb 21, hopefully at the same bat time.
UMAnitarian no-host drinks get-together at Salt House, 545 Mission St, Thursday evening, 6pm+! Drop Eve a line if you think you can make it, or dm or email her that day/evening.
Example doc for permission requests: We worked through this doc and had lots of conclusions. See that doc for spec instructions.
Previous RPT:
James has weighed in in favor of a single RPT because of the burden, otherwise, on multi-user clients to manage potentially tens of millions of tokens without knowing which one works for which resource. A client can't provide multiple tokens to a resource to see which one works.
If you want stateless tokens, you need to keep state in the token. It could be made efficient in various ways, but does it provide an incentive to go stateful instead? Even if the client provides a previous RPT, the AS still has the choice to hand the client a very session-specific token in response. There are various TTL strategies possible. What are the right strategies to simplify client developer logic? We keep dancing around informing the client more precisely what's in the token or what went on between the AS and RS. So far we haven't added anything to the UMA flow to do it. Another way to do it, potentially, is say: Client, if you have a way to introspect the token, go ahead. Is that tenable?
(Justin's rant on OIDC's ID "tokens" not being tokens but rather assertions is somewhere in here.)
Revealing raw permission ticket contents doesn't seem smart because the client has no context to understand requested permissions if they go outside the access attempt. Could informing the client about actually granted scopes be a middle ground? If you pass in a previous RPT and the token was upgraded, you get an extra Boolean property in the response saying "yes, you were upgraded". If the property is empty, then the client knows it got a new one.
In UMA1, the previous RPT had a role that sort of covered both client coding complexity (managing fewer tokens) and RqP experience complexity. In UMA2, now that clients can request scopes and AATs have been supplanted by PCTs, the previous RPT is meant for the former purpose and the PCT is meant for the latter.
So how should authorization assessment be affected by both? Spec instructions:
Add guidance around the process of the AS deciding to issue upgraded tokens vs. not (the AS should pick one model vs. another), and the client having expectations of which one.
As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah)
Non-voting participants:
Regrets: