Quorum was reached.
Approve minutes of UMA telecon 2017-01-26: Deferred.
Currently our Core spec is inconsistent; we can't publish a WG draft for Last Call in this state.
266: Set math / resource and scope ecosystem:
What is the deal with the Protected Resource Metadata spec? Eve wondered if it has a hint of something in it that would be valuable for our current discussion. Just relates the history: Mike J created a "throwaway draft" just to save the idea somewhere on the Internet. The notion is to prevent a client from sending a token to a rogue endpoint. In the AOL case, if the Mail team creates a new endpoint, it's a way to have loose coupling and dynamic discovery of endpoints. But George agrees that the OAuth WG is not taking this up as a work item.
Eve's specific idea about the usefulness of the static declaration approach vs. the active registration approach was that, if OAuth is chosen as the security mechanism for the RReg endpoint (and OAuth is an awesome security mechanism), that choice requires a binding of whoever/whatever the resource owner is – natural or legal person (individual or enterprise) – to the resources. Static declaration allows the resource to be generic, without any RO context.
Proposal: Instead of having the RReg spec with a resource description document that passes the resource description by value and the scope description by reference (or a simple scope string), we develop a OAuth protected resource metadata spec that suffices for our needs, and then incorporate the RReg API into the UMA spec such that the RReg process simply binds a generic resource and its possible scopes together in an RO context with the PAT. Could this be achieved by simply extending Swagger?
But then the client, in order to request scopes, would need to know about resource IDs as well. But that was why Eve went in this direction; a smarter client should be this smart. Eve's fear is that our design where clients only know about scopes will incentivize design of APIs and scopes in the exact same direction that OAuth does now: pushing APIs to put all the "juice" into scopes, the way Salesforce does, so that a client with only id scope can ask for chatter_api scope. In FHIR, if you have read scope and ask for write scope, you might get it added to the three resources you already had in your RPT, but you can never request access to other resources you didn't already have access to except by attempting access to them, thus hinting to the RS that you want them. Eve's proposal using the "scenario 3" approach in the WSD is akin to the direction Phil had sketched where the token is bound specifically to resources (actually, the RPT already is, but the client doesn't know it).
In scenario 2, if we have a case of CandidateGrantedScopes that's partial, and the AS got a previous RPT,
Discussion: Are we clear about not choosing scenario 3, "super-smart client"? Ishan: The client would have to know the RO in some fashion. Yes, presumably OOB. Agreed. Kathleen: The RO might have set policy that requires the client (and presumably the RqP) to meet various clearances; that's all still true. Yes. Summary by George: What we'd "lose" if we don't go this route is to potentially access a new resource without first attempting access to it. Eve adds: Whatever existing encouragement there is in the current OAuth design center for scopes to have a lot of power, there still is, but there isn't any further power in that direction. Mike: We could have potentially avoided some round trips in the messaging, but our spec schedule would take a hit. George: But we can extend the token introspection endpoint, maybe add a hint, to improve the current messaging.
We have consensus not to go the super-smart client route for now.
Justin notes, as the token introspection spec editor, that the notion of the hint was yanked. But you can add parameters on the request. Adding the permission ticket seems unreasonable since it's meant to be ephemeral.
We have a couple of big decisions to make right now, then:
10 RS requests resourceA(scope1, scope2)
20 AS issues RPT resourceA(scope1)
30 RS introspects RPT, finds insufficient scope for request, GOTO 10
Open questions:
How does the AS deal with partial results? Specifically, is PermissionTicket inviolable?
How does the RS deal with rejected requests? Specifically how can it optimize? (James)
How does the PreviousRPT affect set math?
(optional) Can the AS optimize dealing with a previous RPT prior to engaging in assessment logic?
Publishing UMA endpoints in Swagger/OpenAPIs: Does anyone want to research this? Justin speaks against; some others may be interested. Mike will look into it. OpenAPIs.org. IPR compatibility is a question.
Ad hoc meeting on Tuesday during the same 90-minute period as today: George, James, Eve, Domenico, Kathleen?, Cigdem?, and Mike can attend.
Attendees
As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah)
Non-voting participants:
Regrets: