UMA F2F 2009-11-02

Date and Time

• Day: Monday, 2 Nov 2009
• Time: 1:00-5:00pm PT (meeting held locally; no dial-in)
• Location: Boole room, Computer History Museum, Mountain View, CA (directions)

...

NEW emerging design principle: Complexity: Complexity should be moved to borne by the AM endpoint vs. the host or requester, if possible. Comment: We anticipate dozens of AMs (maybe lots more if corporations have them), hundreds of thousands of hosts, and hundreds of millions of requesters.

...

Referrals are transient; their only purpose is to correlate a host's view of a requester's identifier with the AM's view of that same requester. Once the link is made, the referral stuff can go away. (The host and AM can happily manage that state separately afterwards.) The ID provided by the host can be the user ID, the session ID, or whatever is handy.

ISSUE for later: How and whether to request the "protected status" of a resource: To answer this question, a host would pretty much have to go through the same dance as for a request for actual access! It might be protected against requester A but not requester B, or protected with a real-time user consent loop, etc. We'll wait to see what real scenarios arise that need to be solved, and perhaps it will turn out that they can tolerate imprecision/latency. Before a host gives out the 401, it already knows intrinsically whether the resource is protected by some AM, and it has the ability to tell the requester this (whether this is a good idea or not we don't know yet). It just doesn't yet know whether the requester is going to be authorized to access it.

Since we're now out of the authentication business, keep in mind that whatever the host does in response to the initial approach of the requester is up to it. It can assign a pseudonymous form of identifier (possibly literally using a cookie-based method), or really anything. If the host needs to protect the privacy of the requester according to its own policies or applicable laws or whatever, it's up to the host to choose an ID wisely. We don't really care about protecting the requester's privacy, however; the whole point of letting the authorizing user control access is to let them do so on whatever criteria, and as part of that process the requester is simply going to have to authenticate, even if weakly.

OAuth (the subject of our design principle #2) actually brings two different use cases to the table: service authentication and a "read/write" framework for service access. Both are valuable to us.

NEW emerging design principle: Authentication: We want to stay out of the authentication business as much as we can. Comment: There are many technology choices here, and we want to be agnostic as to the right one for the job. Some scenarios may need stronger authentication and they should be free to use the right mechanism for the job. And setting up all pairwise relationships may be subject to some trust framework (e.g., some AMs might get blacklisted).

...

• Focus on scenarios and use cases involving user-driven terms, policies, and demands for claims
• Understand where the IMI model of claim requests and responses may be able to help us

...

We walked through Eve's screen mockup (see slide 8 that shows how policies and terms might be set, and brainstormed what features the protocol might need to support.

The box on the top represents a set of (presumably standardized but currently totally made-up) contract terms that a user might want to offer a requester, such that if the requester meets the terms (which might involve agreeing, paying, etc.) they will get authorized for access.

The box on the bottom left represents a length-of-access policy that the user might want to set, which the AM can act on unilaterally (without requester input). We discussed whether the "Once (unlimited tries till success)" option is practical; for non-GET types of service access it is practical (and, in fact, it's a requirement that we need to satisfy), but for GET types of access it's not practical because of the nature of HTTP. The actual option for length of access in a "one-time" GET case would probably be something like "as many times as you like in the 10 minutes (or hour etc.) after your first attempt at access". The user experience shouldn't expose this complexity, however! It could say "once" as a first approximation, and offer a link for an advanced explanation of how it really works.

NEW pending requirement: Something about ensuring that it's possible for AMs to offer a "POST once" setting, as this is critical for payments and the like.

It was suggested that we should offer UX best practices for policy, as OAuth and OpenID do. Whatever policies and terms we highlight in such materials will be likelier to be adopted. As well, it was suggested that we should provide examples of how to solve for personal-datastore types of basic data.

The box on the bottom right represents what we anticipate to be a likely case in some scenarios (such as "hey, sailor", where the user widely advertises a link that's UMA-protected): the authorizing user wants the AM to contact him when the authorization request comes in, asking for real-time consent. It's possible that this policy also has consequences for terms, in that the requester probably should be informed (or even be asked to agree with the fact that) the user may choose not to consent even if the requester has jumped through some hoops already to get authorized.

It was suggested that a condition people might want to make for access is "I'll offer you access to this, if you offer similar access to your stuff." This might be especially important for more peer-to-peer (person-to-person) types of sharing; we invite scenarios on this.

The Information Sharing WG's car-buying scenario highlights the potential need for data-sharing terms to have some specificity to the type of data being shared.

NEW issue: Do we need a new DP for "value of access"? It should range from low to high, which may impact security options chosen.

We need to do some serious scenario-building to guide our work on terms negotiation. Here are some ideas we brainstormed, with nicknames:

Next Meeting: UMA telecon 2009-11-12

...