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.
"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: