Page Comparison

Anchor
terms_id_scenario terms_id_scenario

...

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, the user can set policies and make decisions that result in appropriate Requesters gaining access.

...

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

"Anyone can gain access if they introduce themselves."

Examples of resources that might be protected this way:

• An otherwise open RSS feed for a blog
• A not-particularly-sensitive calendar

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. 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-Authorization with Identity from Trusted/Whitelisted Issuer (Pending)

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

This might apply in Examples of resources that might be protected this way:

• Sharing calendars, photos, and other resources that are already selectively shared today by means of specifying email addresses of intended recipients
• Sharing the results of car-buying research with friends and family
• Protecting status update feeds

In the case of Sally the car buyer, and granting access to her husband and friend. She , 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 pre-authorizationher setting policies around specific identities even before people wielding those identities attempt access to the resource in question.

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

The Authorizing User could also, if assuming 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.)

Issues:

• Are there special optimizations – and/or concerns (say, 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.

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

"Someone purporting to be 'Random' wants access."

Examples of resources that might be protected this way:

• TBS

There are two circumstances for arriving at this combination:

...

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