*authorizing user:* An UMA-defined variant of an \[ [OAuth20|#OAuth20]] resource owner; a web user who configures an authorization manager with policies that control how it makes access decisions when a requester attempts to access a protected resource at a host. Wiki Markup *authorization manager (AM):* An UMA-defined variant of an \[ [OAuth20|#OAuth20]] authorization server that carries out an authorizing user's policies governing access to a protected resource. Wiki Markup
protected resource: An access-restricted resource at a host. unmigrated-wiki-markup
*host:* An UMA-defined variant of an \ [[OAuth20|#OAuth20] ] resource server that enforces access to the protected resources it hosts, as decided by an authorization manager.
token validation URL: The URL at an authorization manager that a host can use to validate an access token.
*claim:* A statement (in the sense of \ [[IDCclaim|#IDCclaim]]). Claims are conveyed by a requester on behalf of a requesting party to an authorization manager in an attempt to satisfy an authorizing user's policy. Wiki Markup *requester:* An UMA-defined variant of \ [[OAuth20|#OAuth20] ] client that seeks access to a protected resource. Wiki Markup
requesting party: A web user, or a corporation (or other legal person), that uses a requester to seek access to a protected resource.
Requirements for the resource owner
- The resource owner MUST be able to choose a different AM for each Host
- (The resource owner MUST be able to choose a different AM for each protected resource)
Requirements for the protected resource
In this step the following needs to be achieved:
- The Host needs to get an Access Token from the AM to later be able to verify Access Tokens from Requesters. Lets name them AM-Host Access Tokens or AH-AT for short.
- The Resource Owner needs to define conditions the Requesters need to fulfill before access t the protected resource is granted. This can e.g. be "is from domain twitter.com". This is done in terms of claims the Requester must send. Claims are basically attributes it sends and which can be verified eventually by the AM.
- The AM needs to know some details about the Host, e.g. the title and description. This is important as in communication with the Resource Owner it needs to tell it some details about the which protected resource the Requester actually wants access to. So maybe it even needs to be described on a resource by resource basis? The user might not really know much about "xyz wants access to method POST on http://someapi.com/mrtopf/
The protocol involves some steps:
The AM provides the following information in it's XRD:
- the authorization endpoint URL for the Host to initiate an Access Token authorization (Host authorization endpoint)
- the token endpoint URL for the Host to exchange the temporary token with the access token (Host Token endpoint)
- the authorization endpoint URL for the Requester to initiate an Access Token authorization (Requester Authorization endpoint)
- the token endpoint URL for the Requester to exchange the temporary token with the access token (Requester token endpoint)
- (some endpoint for verifying access to protected resources. This will become clearer when thinking about Step 3)
(example XRD here)
The Host initiates an OAuth 2.0 Web Server flow to obtain an access token for the AM