Page Comparison

...

• Compare the identity to some policy with which it has been pre-configured in order to make a decision
• Convey the identity to the Authorizing User in an out-of-band a request for real-time consent to access (based on prior user instructions to do this) – for example, in an email or SMS message

This table summarizes specific motivations for use cases exploiting both of these choices, where the Requester's identity is either self-asserted or has been attested to by some trusted third party.

Use Case: Pre-

...

Configuration of Policy with Self-Asserted Label (Pending)

"Anyone can gain access if they introduce themselves."

Examples of resources that might be protected this way:

...

; these are policies that could be set up in an AM at any time:

• "Let anyone offering an identifying string access my RSS feed 'Blog'"
• "Let anyone offering an identifying string access my calendar 'Work Free/Busy'"

This use case is likely not to involve any sort of sophisticated matching of pre-authorization configured policy to a particular identifying string that any Requester can just make up. Rather, it is likely to involve a policy that freely gives access to relatively non-sensitive resources as long as the audit log entries can consistently use some sort of Requester-chosen label. This is marginally more interesting than merely recording IP addresses, assuming the Requester chooses to use a label that is intuitive and accurate on some level.

Use Case: Pre-

...

Configuration of Policy with Identity from Trusted/Whitelisted Issuer (Pending)

"Let (this identity, this list of identities) from (this issuer, one of these issuers) gain access."

Examples of resources that might be protected this way:

...

; these are policies that could be set up in an AM at any time:

• "Let Google's 'Carlos', 'Dahlia', and 'Evan' and Twitter's 'Frank' access my photo album, 'Soccer Practice'" (calendars, photos, and other resources that are already selectively shared today in a selective fashion by means of specifying email addresses or known usernames of intended recipients)
• Sharing the results of car-buying research with friends and family
• Protecting status update feedsWhere the Authorizing User is Alice Adams: "Let Amazon's 'AliceAdams02134' access my e-commerce personal datastore" (this is a special case)

In the case of Sally the car buyer, who is granting research access to her husband and friend, she could specify that Requesters acting on behalf of her husband's Google identifier or her friend's Twitter handle always get access to certain protected resources. If she can be sure that Google or Twitter has vouched for the requesting user on whose behalf the Requester is making its access request, this is a greater level of assurance that warrants her setting policies around specific identities even before people wielding those identities attempt access to the resource in question.

Likewise, it could be powerful to set up a policy ahead of time that says that Amazon.com, acting on behalf of a specific identity that represents the same person as the Authorizing Useris known to represent oneself, can get access to one's shipping address or vendor-neutral wishlist. Since the Authorizing User already knows all the identities they wield he himself wields in various applications, setting up policies to grant a set of social networking applications (acting on these identities' behalf) access to one's social graph or geolocation information at other applications already in the "known circle" (as in the distributed services scenario).

...

• Are there special optimizations – and/or concerns (sayfor example, about privacy) – in the situation where an Authorizing User is granting access "to themselves" in the guise of other applications and digital identities? Policies that specially mention all the digital identities under which the same person travels can be considered privacy-sensitive information since they expose a kind of "federation" of those identities.

• It is not UMA's responsibility to solve the problems that a People Service or a Portable Contacts API. However, could it neatly integrate with such solutions in order to allow relationship manager applications implementing an AM endpoint to provide more sophisticated ACL management?

Use Case: Real-Time Consent with Self-Asserted Label (Pending)

...

Examples of resources that might be protected this way; these are real-time messages conveyed to the Authorizing User for a "yes" or "no" answer:

...

• "Someone purporting to be 'BelleCare Dental' is requesting access to your calendar, 'All Free/Busy'."
• "Someone purporting to be 'Eve Maler' is requesting access to your photo album, 'IIW 2009B'."

There are two circumstances for arriving at this combination:

• The Authorizing User has recently provisioned a particular party with the URL for a resource that is UMA-protected (or a way to discover the URL), and is thus expecting that party's Requester app to come along shortly and attempt access.
  
  This is often somewhat similar to how IM handles and email addresses are shared and heuristically authenticated today: Alice and Bob exchange, say, Skype handles in a phone face-to-face conversation, and sometime soon thereafter "Someone purporting to be 'Bob'" approaches Alice in Skype asking to be approved. (The difference is that Skype really does authenticate some user against a "Bob" Skype handle, whereas here the label is entirely self-asserted, perhaps having been typed into a web form field by the requesting user (or the requesting entity's representative) when resource access was first attempted.

• The Authorizing User has freely published the URL for a resource that is UMA-protected, and the Requester approaches without prior notice (known as the Hey, Sailor pattern).
  
  This use case involves a user who is satisfied with self-assertion of Requester identity for this resource, so presumably the resource is not terribly sensitive or high-value.

Use Case: Real-Time Consent with Identity from Trusted/Whitelisted Issuer (Pending)

"Verified Requester 'Solid' wants access."

Examples of resources that might be protected this way; these are real-time messages conveyed to the Authorizing User for a "yes" or "no" answer:

• "Google's 'CPABobBaskin345' is requesting access to your spreadsheet, 'CF2010'."
• OpenID "=JeffH' is requesting access to your photo album, 'IIW2009B'.

This use case provides stronger protection than the self-asserted version for gathering real-time consent in the Hey, Sailor pattern.