Let's talk to Joni about a Kantara-hosted event that week.
Quorum was not reached.
All duly noted.
Eve shared news from this workshop hosted by MIT. Debbie Bucci and Eve are offering to co-chair this new profiling group at OpenID Foundation. More to come. The proposed name of the group is HEAlth Relationship Trust, or HEART.
Joni is helping Sal put in a submission for an UMA IoT authorization session that will have a Raspberry Pi demo.
Eve's company is helping her and Maciej put in a talk on "Kill the Password? Kill Impersonation! The UMA Delegation Advantage".
Maybe we want to have another UMArtinis or UMArgaritas cocktail hour (and training workshop at the same time?) during RSA. Let's talk to Joni about a Kantara-hosted event that week.
We discussed Eve's proposal. She has proposed one particular choice for AS behavior, but there are other choices:
George notes that in OAuth-land, if consent is given after retrying a scope not initially given, then that state is kept on the back end and re-associated with a token later on a retry. This is "RPT-like" in that the AS is keeping entitlement state, so to speak, on the back end. This helps the user experience, and seems to argue for enriching the RPT if possible. If we pick one way now, Eve's theory is that we should pick a way that's friendly to users; in the future, when we get more best-practice experience, perhaps we can broaden the options. George notes that UMA manages the challenge with a permission ticket as the "error" that lets the user (the RqP operating the client) retry the request. In fact, whether the AS has a new or old RPT is just a matter of a persistent or refreshed correlation handle for its back-end state, so the rationale for choosing the RPT "refreshment" is not about UX but about an implementation choice. Is there, in fact, a reason to choose one implementation flavor vs. another? The client has to deal with what they're handed back either way, so maybe we stay out of the decision.
We discussed how the RS also has a choice in registering permissions. For example, it could choose to register a "parsimonious" scope when there's no RPT in the request and a "generous" scope when there's an RPT in the request. This too is an implementation choice.
Are there auditability implications of handing out a new RPT? This is totally an implementation choice.
We got consensus on the proposal, with the change that the AS has the choice to change the RPT string that was in the request or keep it. We still need to discuss whether the previous RPT (if a new one is issued) is invalidated or not. Is this also an implementation choice? When you get into multiple servers and multiple users, it's easiest to just invalidate the existing token! Statelessness may be your friend in all those circumstances. And the audience (of an OIDC token) might be specific to one client. Maciej would like to be sure to discuss this further in light of the existing spec text.
AI: Eve: Send revised eager permission registration proposal to the list.
AI: Eve: Send updated prioritized list of V0.9 issues to the list.
Eve brought up the idea to change terminology in order to diminish the impact of the "three tokens": should the RPT be "access token", and should we make the AAT pronounceable?
Non-voting participants:
We will hold all-hands meetings (calling the roll) through the fall and early winter as much as possible; voting participants please attend! You can subscribe to the UMA calendar (and ask the chair to send you an event invitation) to see the times in your local time zone. Keep in mind that when the clocks change, we experience "summertime skew"; our home time zone is Pacific so non-US meeting times may shift.