Child pages
  • UMA F2F 2009-11-02

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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

TBS

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:

Name of Potential Terms Scenario

Description

Always Authorize, or Just Audit, or Requester Whitelist

AM->R: (nothing). R->AM: yippee! I can get in!

Requester Agrees

AM->R: Here are the authorizing user's terms; accept them. R->AM: I agree.

Requester Supplies Policy

AM->R: Tell me your privacy and data usage policy. R->AM: Here it is.

Porn Uploading

AM->R: Prove to me you're over 18. R->AM: (claim).

Contract Exchange (a la Nat's work)

AM->R: Make me an offer. R->AM: (terms). (potentially cycles back and forth a few times after this, with AM/user choosing some terms over others)

But Wait, There's More

AM-R: I'll give you resource A if you meet terms X, but also resource B if you agree to terms Y. R->AM: (claims meeting terms X or Y)

Boolean

...

Next Meeting: UMA telecon 2009-11-12

...