Quorum was reached.
Approve minutes of UMA telecon 2016-09-01: Deferred.
Meeting next week? No, we are not meeting next week.
Let's use this name for now and do the big "names for everything" roundup when we get to it.
MITREid Connect implemented the original UMA RPT as a "true" OAuth access token – so, nothing special about the "UMA bearer token profile". And since UMA Core didn't say anything one way or another about refresh tokens, they didn't implement that.
Pros and cons:
PAT/RPT/AAT/(no RPT refresh token):
PAT/RPT/RPT refresh token/persisted claims token: (Note that the AAT really is gone, though there are a few rogue mentions still in the spec and there's more surgery to do, e.g. a true "UMA grant" flow specification needs to be written.)
Andi notes that if we've got "consent" tokens (mindful that we want to avoid that word!) floating around, we want to think about auditability. So it's time for a good pow-wow with the CIS WG, and also for discussing "notification endpoints" and such.
We're agreed that the "PCT" would be best applied for both interactively gathered and pushed claims both. Now, to examine how smooth or complex the RqP interaction could get. We looked at Eve's analysis of how "compressed" or "onerous" the flows could be. Justin notes that the RqP's authorization is not required for the token itself to persist the claims of both categories, so the "onerous" picture in the PCT case isn't really right. In other words, the RqP doesn't need an account at the AS. 't envisions a special claim that represents the RqP's authorization – that is, a claim with special semantics.
Should we have a separate spec for this special claim? It's sort of internal to the AS, so maybe we just define it right in the same UMA Core spec, and don't put it in any standardized registry.
Andi feedback: He'd like a single restatement of what we're trying to solve, why the existing design doesn't solve the problem, and why the new redesign does (we think) solve the problem. What are the security risks? What are the privacy risks? Would PII be leaked? What are the audibility and traceability characteristics? What are the performance characteristics? Let's do swimlanes comparing them. Justin might be able to "build the blasted thing" and Eve can commit to doing the foregoing explanation. We might be tantamount to spec'ing this as well. Let's do all this analysis in email.
As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah)
Non-voting participants: