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)

...

• 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

...