Page Comparison

...

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.

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:

...