UMA telecon 2014-03-27

Owned by Eve Maler
Last updated: Mar 27, 2014

UMA telecon 2014-03-27

Date and Time

  • All-hands meeting Thu Mar 27 8:30-10am PT (time chart) - N.B.: US has changed clocks by now - "summertime skew" (UK 7 hours later at 3:30pm, Europe 8 hours later at 4:30pm)

Agenda

Minutes

Roll call

Quorum was reached.

MOTION: Thomas moves to accept the minutes of March 6 and read into today's minutes all of the focus group meeting notes as appropriate. APPROVED.

Action item and event review

Thomas report 60 people registered for the Private Health Data Workshop. Awesome.

IIW: Jin, Mark, George, Adrian, and (we believe) Roland will attend.

AI: Eve: Ask Roland if he's interested to run an IIW session walking through his UMA implementation and test suite.

EIC: Domenico and Maciej are presenting on UMA (User-Managed Access: Key to Life Management Platforms), and we discovered through tweets during the webinar that Prabash from WSO2 is touching on UMA in his EIC talk as well. Mark points to a previous discussion about a panel discussion at EIC; he was willing to be a panelist but isn't sure if it's being held.

Domenico is working on an update on the Italian Wikipedia entry for UMA.

Interop planning

Mark is not committing to an implementation by IIW, but that might happen. Keith is doing some work using UMA libraries, so that could contribute to the overall interop picture (if not contributing a new independent implementation); in about a month, he'll be able to share status and a demo.

Webinar followup

Attendee/registrant analysis: Eve is constructing a list of people to follow up with. Mark is willing to take part in these discussions.

AI: Eve: Ask Joni to be sure to update all the registrants with the slide and recording links.

 AI: Eve, Mark: Follow up with potential implementors and deployers.

UMA for IoT

A somewhat related topic that keeps coming up lately is UMA for Internet of Things (IoT). George notes that often the provider (RS?) is in a position to do the management of access (AS?). Eve comments that some profiling or special bindings might need to be done to IoT-specific protocols over and above HTTP. Thomas points to the new IETF group called Authentication and Authorization for Constrained Environments (ACE) that just got started. George plans to discuss all this at IIW. Adrian comments that cardiac defibrillators are treated as "self-owning" along the lines of our older Device-Managed Access discussion: the operator/manufacturer is something like the resource owner, and the person in whom the device is implanted is sort of a licensee. This enables the RO to be singular in the architecture, while enabling the granting of "admin" (further rights-granting) scopes to others so that they can act a bit like owners. Auto-updating software, such as Apple-controlled OS updates, have a similar cast to them.

The question of end-user ownership is a tricky one, e.g., if a consumer buys a light bulb and brings it home, what should they be allowed to do? The light bulb works by setting up its own network address, and you have to onboard it to your local network. Would you be in a requesting party role at this point?

AI: George, Domenico, Adrian: Follow up with Twitter guy on UMA for IoT, to learn about progress on any implementation and profiling.

Complex resource sets and scopes

We analyzed Roland's initial test of the complex resource sets/scopes proposal. We validated that his use of the proposal is accurate (barring putting the email address in the resource set name, which we're not crazy about (smile), but it's not relevant to the questions before us). We also validated that he is achieving "graphs" of overlapping complex resource sets. Because his use case only needs a scope of "read", this simplifies the analysis. We discussed the more difficult case of mentioning scopes in the "simpler" levels. Eve had proposed an additive rule, to make it very obvious what scopes apply in case case.

Mark asks about multiple inheritance. George asks what happens if the attempted access fails given the scope associated with the current permission ticket. Eve describes how the RS is in control of every facet of its grain of access. If it never registered the possibility that a client could do Write access on a particular resource set, then if the client attempts it, it's the RS's fault that the resource set registration was incomplete. If it did register the possibility and RPT introspection reveals that the client only has permission to Read access, then that's a signal to the RS to (probably) register a requested permission to get Read access in addition.

The original purpose of Roland's use case was to simplify Alice's ability to set policy over different attribute release buckets. But scopes are another level of complexity. Scopes came from the goal of wanting to constrain delegated access by requesting parties. Bob might be able to view a photo, but Carl might also be allowed to print it.

Eve would like to see us try applying our current and proposed resource set registration paradigms to more real-world APIs and web apps.

Roland further noted that the AS has the power to issue permissions that cover less than what the RS registered for. Eve adds that the RS also has the power to register a requested permission that's insufficient for what the client attempted. When is this okay (where there's a legitimate use case for it)? When is it possible to technically forbid it? When do we need to lean on the Binding Obligations level of disallowance? Obviously, both of these are very inefficient in terms of protocol activity just to give back to the client something that won't work! We try to put some wording in Core, and a little in Binding Obligations, to disallow/discourage this. Currently, clients are allowed to be even dumber than OAuth clients, in that they don't have to know about scopes or resource sets or anything; they just need to have discovered the availability of the RS's resource/API out of band wrt UMA.

We currently say in Sec 3.2 of Core: "In response to receiving an access request accompanied by an RPT that has insufficient authorization data, the resource server uses the protection API's permission registration endpoint to register a permission with the authorization server that would be sufficient for the type of access sought." This is hard to make into a testable assertion, though we've sort of tried; it depends on client-RS communication that's out of band wrt UMA.

We're far from done with this topic, but it's clearly the next really important area to push forward. Eve would like to consider where "simple" and "complex" are even the right terms; are we heading to "classes" and "instances"??

Note that Roland has suggested an optimization of the current proposal, involving embedding "simple" resource set descriptions into "complex" resource set descriptions. He has done a rough implementation of this and find that it's more performant.

Claim profiles review

AI: Lukasz, Maciej: Revise the claim profiling spec based on the notes from March telecons.

Attendees

As of 26 March 2014, quorum is 7 of 12.

  1. Eve
  2. Mark
  3. Domenico
  4. Keith
  5. Jin
  6. Thomas
  7. Lukasz
  8. Sal

Non-voting participants:

  • Zhanna
  • Adrian
  • George

Regrets:

  • Maciej
  • Roland

Next Meetings

  • Focus meeting Thu Apr 3 8:30-10am PT (time chart) - all back in sync
  • Focus meeting Thu Apr 10 8:30-10am PT (time chart)
  • Focus meeting Thu Apr 17 8:30-10am PT (time chart)
  • All-hands meeting Thu Apr 24 8:30-10am PT (time chart)