UMA F2F 2010-11-01
Date and Time
- WG F2F on Monday, 1 Nov 2010, colocated with IIW XI at 11am-5pm PT (time chart)
- No dial-in
- No telecon this week
- Boole room in the Computer History Museum
Agenda
Let's meet 11am-1pm, then do a working lunch (order in pizza?), then finish with a long afternoon stretch.
- Let's use #umaf2f along with #iiw as hashtags for the day
- "IPR benediction"
- Identify note-takers
- Roll call
- Agenda-bashing
- Approve minutes of 2010-10-28 meeting
- Reminder of next week's telecon and time change (see Next Meetings below)
- Action item review
- Bounty program status
- Other updates from the wider UMA world
- Brief "UMA 101" session as necessary for newbies in the room
- User stories: add, review, prioritize, decide
- Resource/scope registration: go through latest proposal and issues and decide
- AOB
Attendees
- Fletcher, George
- Hardjono, Thomas
- Machulak, Maciej
- Maler, Eve
- Moren, Lukasz
Non-voting participants:
- Charles Andres
- Alan Karp
- Henrik Biering
- Joseph Holsten
- Jeff Stollman
Minutes
Thomas offered to be the notes-taker for for most of the day.
New AI summary
George: Write up "problem B" as a user experience description that can be turned into a user story.
Eve: Put the public-private continuum language and diagram into the Lexicon.
@@More TBS - figure out how to get all new user stories into place
Roll call
Quorum not reached.
Approve minutes of 2010-10-28 meeting
Deferred due to lack of quorum.
Action item review
- 2010-08-26-6 Eve Open Ping Denise Tayloe of Privo to see if she has interest in taking custodian scenario forward.
- 2010-09-02-1 Thomas Open Categorize all existing scenarios by their distinctive aspects. We'll discuss this today and decide whether to change this one.
- 2010-10-07-2 Sal, Domenico Open Propose the next version of the trusted claims solution, making appropriate simplifying assumptions.
- 2010-10-28-1 Eve Closed Work with Sal and George to put together a set of flow options/user stories for review at the IIW F2F.
Bounty program status
Two indications of submission interest have been sent in so far. The deadline for submission interest is 11:59pm Pacific time tonight.
Other updates from the wider UMA world
@@TBS
User stories: add, review, prioritize, decide
We reviewed the new User Stories page. The page isn't very complete yet; Eve put in a sampling of user stories to test the columnal design, column sorting, and general "feel". Epics are tightly associated collections of stories; she has made epics all be in the "UX" category so that they focus on a human being's desire for some benefit. Some stories are "negative", in that they express some (typically malicious) entity's desired outcome that we want to avoid if at all possible.
It was observed that the stories zoom from high-level to low-level, and the "so that..." (motivation) portion of the descriptions could useful become more motivational and less technical/mechanistic even for the lower-level stories. Apparently the Ruby community likes to move the "so that..." portion earlier, in which case it would make sense to rephrase it as "in order to...". But since this is a fairly invasive change without obvious huge benefit we're likely to keep it in the current order.
Many new stories were suggested over the course of the rest of the meeting.
Resource/scope registration: go through latest proposal and issues and decide
The "share" pattern and other patterns: At first through discussing the "Register resources and available scopes" story and the pending "Request registration of resources and available scopes" story, and then through general discussion and examination of the latest proposal, we drilled down into the likely tasks an authorizing user might want to perform to try and figure out the flows that need to be supported. The proposal supports the first of these stories but not the second.
The goal in the SMART project was to enable a user to click on a "share" button while visiting the host, and then be redirected to the AM to map a policy to that resource. The project also has the goal for the host to accurately display to the user the status of a resource (whether it has been registered at the AM or not). These generally fall under what we started calling "problem A", acknowledged to be likely in-scope for UMA 1.0 based on the SMART UX study experiences.
We also considered the possibility that the user might want to remain at the host while associating a policy with a resource for lowest possible UX friction, which we called "problem B", and to cancel protection for a particular resource while visiting the AM, which we called "problem C".
Managed vs. unmanaged: We came up with some new terminology and assumptions to help us figure out the connection between protocol features and desirable user experiences. We believe it's likely that a host will want to offer to protect some or all of a user's resources there with the same AM, rather than offering to split the protection of resources among multiple AMs.
[Joseph later observed that migration to outsourced authorization could be a reason why a host would offer to protect only some resources with that single AM.]
Any resources that a host ends up not registering with an AM are what we decided to call unmanaged. An unmanaged resource could be totally public or totally private, for example, and in both cases its existence is entirely unknown to the AM. It's expected that whatever a host does when access is attempted to such a resource, it does not engage in the step-2 "UMA dance" of issuing a 401 and sending the requester to the AM for an access token.
A managed resource could be said to be protected by the AM (in that a 401 with AM info is now in place no matter what), and it is prepared to be selectively sharable, governed by which policy ultimately gets attached to it.
The public-private continuum: There are useful things an AM can offer in managing a resource, ranging from the "public" end – access tokens could be issued to all comers, but the user could track, monitor, audit, and observe analytics of access in various ways (see, e.g., the null scenario) – to the "hidden" end – either the user might not have mapped a policy to particular resource at all, so that access tokens are always denied to all comers, or the user might have mapped a very draconian policy to the resource so that it turns out no one is worthy of getting an access token.
It should be noted that AMs could offer user preference settings that allow for policies to be mapped to registered resources in some default pattern so that there are no resources that remain unmapped. Also, to the extent that a host does not need to resort to outsourcing token validation at the AM, and to the extent that an access token is long-lived, the AM is not exposed to every single successful access of a managed resource and so its analytics and audit logs might be more coarse-grained; perhaps this is amenable to an AM user preference setting too.
Problem B: Currently, the SMART host sample apps allow a user to click on a "Share" button, which (much like the Picasa-to-Piknik "Edit" flow) redirects the user to a different site, namely the AM site, so that they can associate a policy with that resource before getting redirected back. (The host actually registers the resource with the AM "silently" from the user's perspective before they get redirected.)
It was observed that the portion of this flow that might require the user to log in at the AM (if there's currently no active session there) before doing policy stuff could add to the user's burden. So we went down a path of exploring what it would look like for the AM to do something like "policy registration" at the host, to give it the names of policies that could be associated with that host's resources.
One idea we discussed was somehow using the host's already-existing host access token to help log the user in silently, vs. having the user log in as themselves. But this got hairier the more we thought about it; first of all, the host would be allowing the user to impersonate the host...which after all was delegated its authorization from the user. We found the semantics of this to be ugly. Secondly, the host likely has a subset of the user's rights at the AM, with the user's rights normally totally disjoint from the host's rights. So we gave up on this.
Ultimately we gained rough consensus not to target a solution for problem B in UMA 1.0. Although reducing friction is nice, it felt like premature optimization, which perhaps lots of other efforts (such as various "identity in the browser" efforts) would be trying to solve in a more elegant fashion. Also, this would add a lot of protocol overhead and state management and give hosts lots more responsibility for authorization jobs than we had intended to give them.