Quorum was reached.
MOTION: Approve the amended minutes of UMA telecon 2015-07-30. APPROVED by unanimous consent.
This sync schedule is working really well.
No update. Eve hasn't moved the repo over.
Issues 153 and 154
Not meaning to guess Justin's exact thought process in any way...
Observation #1: AS has a special "RPT endpoint", making up the entirety of the special "UMA authorization API", at which the UMA client asks for a special UMA "RPT" with authorization data on Bob's behalf, that acts suspiciously just like an ordinary OAuth token endpoint. If it were more like an OAuth token endpoint, greater UMA-OAuth alignment could be achieved.
Observation #2: The UMA "authorization API token" (AAT) is an extra layer and hindrance to the entire OAuth-friendly cycle in this case, particularly because it appears to require that Bob have a login at the AS.
Discussion: Isn't the last bit, about the login, just an implementation decision? He has to either be SSO'd into the AS, or have a local login at the AS, or be offered a federated ("NASCAR-like" or whatever) login option at the AS. More accurately stated, he has to be able to establish an authenticated relationship with Alice's AS.
Observation #3: If the AAT flow were entirely removed and the RPT endpoint were turned into a ordinary token endpoint, then Bob's client would approach it to ask for "an access token" (perhaps of some UMA-flavored type?).
Discussion: Eve contends that, since we are trying to keep everything as much the same as possible, then this new "UMA-flavored grant flow" would still (so far) have the the client approach the RS, fail, get a ticket, go to the AS's (now) token endpoint, ask for a token, and engage in the trust elevation flow we have already designed.
Observation #4: Instead of using an AAT in the header of the token request, it would use its client credentials to identify itself, basically using its own recognizance.
Discussion: Where else is the AAT required in headers? Is it required in the redirect of Bob for claims-gathering? No, there are other security measures imposed. What about in the case of an autonomous web service client? We think that this could use pushed claims to the token endpoint as well.
More discussion: The AAT isn't very high-value! So a kind of "merge" to elevate what was the AAT flow up into what was the RPT flow to become an analog of a typical OAuth flow looks attractive. That means the claims flow would be the very first thing Bob does – no AAT step before. That seems kind of clean as a UX, if we're not missing anything like Bob's consent. And we don't think we're missing that, because that's what the OAuth flow is designed to do. The RPT represents everything the AAT did, but more. Why didn't we consider this before? In fact, we did.
More discussion: In both the authorization API circumstances and the newly imagined grant flow circumstances, how does Bob know exactly what claims the client is pushing?
Observation #5: UMA is still OAuth++ or value-add or something, in that the protection API that makes the AS and RS loosely coupled and makes possible trust establishment between them (using OAuth) is added on top, and in that Bob is a completely autonomous actor wrt Alice (which is why the grant flow we're considering has trust elevation as a key part of it), and in that the grant flow we're considering has asynchronicity as a key part of it. All the value-add still seems to adhere even if the AAT isn't part of the picture.
Discussion: Regarding the Privacy concerns: if the Client does a POST on the RPT to get the AuthzData added to it, the AS can still decide to return a new RPT to the Client (if the presented RPT had AuthzData for another RS attached to it). So that could be a AS-privacy setting? According to the APAC discussion yesterday, the answer appears to be yes. We can use a MUST to force the AS to mint a new token per RS. (Justin also noted in email that if the client tries to present a token from RS1 for upgrading with authorization data for RS2, the AS should not allow that.)
Discussion: Is UMA all pseudonymity-based? The AS knows Alice by AliceID(AS). The AS knows Bob through some set of claims, potentially. Each RS knows Alice by AliceID(RSn). Each PAT is a kind of pseudonymous federated ID by which both the AS and that RS know Alice. Each client has a set of access tokens (in the putative new solution) with a set of permissions, but not identifiers.
Discussion: How would the client manage multiple access tokens? All it knows is that it's trying to access a resource. How would it know that the token it has been given is new for this RS? What if the spec said this (bold is new)?
"If the client did not present a token in the request for authorization data, the authorization server creates and returns a new token. If the client did present a token in the request, the authorization server returns the token with which it associated the requested authorization data, which MAY be either the token that was in the request or a new one. In any case, the authorization server MUST return a new token when the client presents a token that is associated with a different resource server."
Summarizing our sense: Generally positive about most aspects, but there is a concern about how clients handle the token situation, and some uncertainty about ensuring that the requesting party really has a chance to authorize the interaction.
Next steps:
Regrets for next time: Andi, Robert, François, Ishan, James, Domenico. Ooh, next week is going to be tough for quorum, so everyone else please try and attend if they can!
As of 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike)
Non-voting participants:
Regrets: