UMA telecon 2016-12-01

Date and Time

Thursdays, 9-10am PT
- Skype: +99051000000481 / US +1-805-309-2350 / international lines / web calling interface / code 1782540
- Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line
- UMA calendar: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Roll call
Approve minutes of UMA telecon 2016-11-10
Logistics for upcoming meetings (calendar) and 2016 roadmap check-in
- Dec8/9: no meetings (consider meeting Wed afternoon or something?)
- Dec 15/16: meet as usual
- Dec 22: meet as usual; RSVP – Dec 23: no meeting
- FYI: End game for V2 specs looks like this:
  - WG vote to publish Draft Recommendations (consider this an "implementers' draft"?)
  - 45-day Public Review
  - If no changes, LC votes to certify Draft Recommendations for All-Member Ballot
  - Ballot takes 14+ days
  - If no changes, Recommendations are prepared for publication and published
  - Total: if no changes, up to 90 days
Work on UMA.next issues – Core is up to 09 and RReg is up to 02 – please review changes ahead of time if possible
- Core: token profiling, rhetorical
- To discuss specifically:
  - Set math (see forthcoming email for discussion points)
  - Remove policy-specific resource/scope description properties from RReg and add as extensions in Core?
  - AATs could be used for "stateful trust elevation"/step-up authentication; do we have any equivalent now, and if not, is this lack okay?
  - claim_token_profiles_supported: Provide real profiles for OIDC and maybe SAML?
  - uma_profiles_supported: What to do with the extensibility profiles?
  - Need to have IANA registry entries for both old uma-configuration and uma2-configuration?
  - Shoebox endpoint
  - Claims hashing
  - Other issue backlog review/cleanup
See the latest swimlane
AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2016-11-10: Moved 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

UMA'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:

Maciej
James

Browser not supported