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

...

• Charles Andres
• Alan Karp
• Henrik Biering
• Joseph Holsten
• Jeff Stollman

Minutes

Thomas offered to be the serve as a notes-taker for for most of the day.. Thank you!

New AI summary

...

...

...

Roll call

Quorum not reached.

...

Other updates from the wider UMA world

...

Maciej will speak on UMA at Devoxx in Antwerp soon. His paper for the MW4SOC conference will be published shortly.

Alan has worked on "transitive access" research, and will submit a scenario focusing on this. Our "requester delegate scenario" is related to this.

Over lunch, Alan demonstrated Tyler Close's work on "the Introducer" with some others (including Mike Hanson), which may offer one solution for the resource discovery problem in cases where the authorizing user wants to send the requesting party a link to a protected resource.

UMA for newbies

We reviewed the UMA entities, basic lexicon, trust a token/get a token/use a token protocol flow, the spec module map, and trusted claims (which Eve suggested should layer on top of the core protocol as an extension). The "Bob at Gmail" problem involves Alice wanting to grant access to Bob in his "bob@gmail.com" embodiment, perhaps through an access control list (ACL) that lists this email address. How can Bob show up, using some requester app, in a way that proves he is bob@gmail? This is illustrative of the trusted-claim problem.

In UMA terminology, we need to distinguish a "requester" (a software tool that implements an UMA protocol endpoint) and a "requesting party" (an individual or company that may assume legal liability for gaining authorized access).

The Liberty Alliance's Identity Web Services Framework (ID-WSF) solved for patterns like this, but it was considered by some as having too many components, and many web developers today consider it as being too complex.

There are many ways for Alice to provision knowledge of the resource to the requesting party. If the latter is Bob, for example, she can email the resource URL to him, hand him a business card with the resource location printed on it, or publish information about it openly on her blog. (Information cards and discovery services could also be employed.)

User stories: add, review, prioritize, decide

We reviewed the new User Stories page. Eve is trying to use some analogues of Agile techniquies to develop UMA user stories.

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.

...

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.

[(After the meeting, 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.

...

(After the meeting, in further discussions over beers, Eve suggested a more RESTful approach that could kill more birds with one stone, since we do have a design principle for RESTfulness and resource orientation. The host could POST a new resource registration construct at the AM representing the managed resources of a particular user, could add to it with PATCH, could GET its state at any time, and so on. We suspected suspect Paul Bryan would approve. ! Maciej intends to take this idea forward.)

Proposal draft issues: We collected the following comments and issues on the proposal draft (in addition to the RESTful idea above, which may supersede some of these):

• Should it be possible to "boxcar" the registration of multiple resources? The current "uri" parameter could have a comma-separated list as its value, as long as the same available scopes applied to all of them.

• Is it okay not to explicitly label scopes in the request message (e.g. with a "scopes" parameter)? Maciej and Lukasz felt that it would be possible to accommodate extension parameters by requiring them to be named "x-something".

• Is it okay to only have single-language display names for the scopes? We felt yes, since the host would already know the user's preferred language (if it even offered its interface in multiple languages) and so would have the opportunity to pick the most suitable display names for that user.

• Can we solve a use case where the user just indicates to "protect" (manage) resources at the host without going through all the steps of actually selectively sharing them? (For example, this might come into play when the user wants to ensure that some or all of their resources are "non-public", as you can do when uploading a bunch of photos to Flickr in batch.) We believe so, since the resource registration piece involves only host-AM communication and doesn't have to have the redirect-the-user-to-the-AM piece on the end.

Next Meetings

• WG telecon on Thursday, 11 Nov 2010, at 9-10:30am PT (time chart) - Maciej to chair