...
Minutes
Roll call
Quorum was not? reached.
Approve minutes
Approve minutes of UMA telecon 2016-11-10: tbs
Logistics
tbsMoved by Andi, seconded by John: APPROVED by unanimous consent.
Logistics
No meetings next week at all (no Dec 8 or Dec 9 meeting).
Dec 15 and Dec 16: regular meetings.
Dec 22: WG meeting. Dec 23: no Legal meeting.
Eve reviewed the "spec end game" timeline as shown above.
Work on UMA.next issues
AI: James: Send a note to the list about the question of a locally validatable RPT and whether to recommend something about its format.
AI: Eve: Send a note to the list laying out the current situation wrt scopes.
tbsUMA's essential characterization: Previously we called it a profile. Now it's called a framework, including mention of its extension grant. What's the right characterization? Though UMA has fewer MAYs and SHOULDs than OAuth, it's still general. Framework, application, extension, profile... Only profile is outright inaccurate if it's the only word used. John W suggests "make use of" instead of "leveraging".
AI: Justin: Please look at the new Note wording in Core 09 Sec 1.4 to see if a) it's okay and b) this wording could replace some instances of the wording that now appears in multiple places in the spec.
Set math: Eve left out a relevant step in her set math email; the set of scopes that the RS registered at the AS could have a bearing on later steps. If the client only ever registered for n scopes out of m possible ones, then even if it later asks for more, the n scopes are a hard mask/limiting factor. Registering for scopes is simply a part of client registration, so we don't have to talk about the mechanism at all, just the effects of it.
Today, clients register for scopes, and the scopes map in some relationship to resources (API calls/endpoints) determined by the API publisher (or the open API that the publisher adheres to). The same is true of UMA, except that the relationship is reified in the RReg interface by virtue of the resource description document that is registered from RS to AS, through a resource ID. (Note that there is an I-D floated in the OAuth WG that has a similar kind of resource ID...) What's weird is registering for scopes – which describe a strange universe of resources – vs specific resources or resource types or suchlike. Apparently the OAuth WG is discussing the latter as client registration upgrades.
How can a client dynamically add a scope that they didn't register for in the beginning? Or delete? Well, shouldn't that be for the client registration protocol to figure out? But if the policy conditions have been satisfied, maybe the authorization assessment should still result in granting the permission with the scope requested.
Maybe we can "future-proof" against client registration getting smarter and allowing registration for resources or resource types or something.
AI: All: Please review and respond to the "Set math discussion setup" email so we can decide key set math questions as expeditiously and thoroughly as possible.
Instructions:
- Revise abstract and intro to account for characterization discussion.
- Define "resource" as separate from "protected resource". Put an xref to the Sec 1.4.3 explanation about how an RS MAY manage complex resources.
Attendees
As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah)
...
- Domenico
- Sal
- Nagesh
- Andi
- Eve
- Mike
- Cigdem
- Sarah
Non-voting participants:
...
- François
- Justin
- John W
- George
- Ariel – responsible for IAM and data protection at TIAA
- Kathleen
- Ishan
- Scott S
Regrets:
- tbsMaciej
...
- James