Terms Negotiation Scenario: Require Requester Identification (Pending)

Submitted by: Eve Maler

If the Requester can identify itself (and the requesting party standing behind it) to the Authorizing User's satisfaction, it can allow for various policies and decisions to flow, resulting in the Requester gaining access.

An AM could make use of Requester identification in two ways: by comparing its identity to some policy with which it has been configured already, or by conveying the identity to the Authorizing User in an out-of-band request for real-time consent to access (based on prior user instructions to do so).

This table summarizes specific motivations for use cases exploiting both of these choices.

Use Case: Pre-Authorization with Self-Asserted Label (Pending)

This use case is likely not to involve any sort of sophisticated matching of pre-authorization policy to a particular 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.

Use Case: Pre-Authorization with Identity from Trusted/Whitelisted Issuer (Pending)

In the case where the Requester is able to wield an identity that is verified by a particular issuer (such as Twitter or particular OpenID providers), or one of a whitelist of such issuers, the Authorizing User may choose to set up policies that pre-authorize access based on this greater level of assurance. It could be powerful, for example, to pre-authorize Amazon.com to get access to one's shipping address or vendor-neutral wishlist, or to pre-authorize a set of social networking applications to get (read and/or write) access to one's social graph or geolocation information at other applications already in the authorized circle.

The Authorizing User could also, if identities of friends and family at sites such as Google and Twitter are known, create "ACLs" (access control lists) that enumerate the allowed parties per resource or host. (Note that design principle DP9 protects Authorizing User privacy at the expense of parties standing behind the Requester; some authorization policy depends on knowing the identity of those who approach the resource looking for access.)

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

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, and is thus expecting that party's Requester app to come along shortly and attempt access. This is often how IM handles and email addresses are shared and heuristically authenticated today: Alice and Bob exchange Skype handles in a phone conversation, and sometime soon thereafter "Someone purporting to be 'Bob'" approaches Alice in Skype asking to be approved.

• 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)

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