Child pages
  • terms_id_scenario

Versions Compared

Key

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

...

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 a third party.


Strength of identification

Pre-configured policy

Real-time consent

Self-asserted label

"Anyone can gain access if they introduce themselves"

"Someone purporting to be 'Random' wants access"

Identity from trusted/whitelisted known issuer

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

"Verified Requester 'Solid' (verified by 'Known') wants access"

Use Case: Pre-Configuration of Policy with Self-Asserted Label (Pending)

...

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 identifier access my RSS feed 'Blog'"
  • "Let anyone offering an identifying string identifier access my calendar 'Work Free/Busy'"

This use case is likely not to involve any sort of sophisticated matching of pre-configured policy to a particular identifying string identifier 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 meaningful on some level.

Use Case: Pre-Configuration of Policy with Identity from

...

Known Issuer (Pending)

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

...

  • 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

...

Known Issuer (Pending)

"Verified Requester 'Solid' (verified by Issuer 'Known') 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:

...