User-Managed Access (UMA) Grant for OAuth 2.0 Authorization

The UMA grant uses the OAuth endpoints in some special ways and defines some new endpoints:

• The OAuth token endpoint handles client requests for, and issues, RPTs. The UMA grant type is defined for use on the requesting party's behalf rather than the resource owner's behalf.
• The OPTIONAL claims interaction endpoint, defined in Section 3.3, plays a role somewhat similar to OAuth's authorization endpoint, but for use by the requesting party rather than the resource owner. For interactive claims-gathering, the client SHOULD register a claims_redirect_uri with the authorization server (as defined in Section 3.3.2).
• The configuration document discovery endpoint, defined in Section 2.2, enables the client to discover other relevant endpoints. The authorization server MUST declare all of its endpoints, other than the configuration document discovery endpoint itself, in the configuration document (see Section 2).

Different choices of phase order, claim collection style, and use of the error_details hints inside need_info might be best suited for different deployment ecosystems. For example, where no pre-established relationship is expected between the resource owner's authorization server and the requesting party, initial requesting party redirection and a redirect_user hint may be a useful pattern, at which point the authorization server might either authenticate the requesting party locally or serve as a relying party for a remote identity provider. Where a common authorization server also functions as an identity provider for all resource owners and requesting parties, having the client push claim tokens sourced from that central server itself with a pre-negotiated format and contents may be an alternate useful pattern.

Depending on the deployment ecosystem and the sufficiency of claims initially provided, the authorization process can be simple or complex. The client has several options for influencing the token request, as defined in Section 3.3.1.

The authorization server conducts the authorization process in three phases, with some potential variation in order and looping as follows:

• A claims collection phase. Two kinds of claims collection involving the UMA grant are possible: claims pushing by a client and interactive claims gathering with an end-user requesting party. This phase occurs first in the authorization process in the following circumstances:
  • When the client redirects an end-user requesting party to the authorization server for interactive claims gathering as its first step after receiving a permission ticket. For this to happen, the client needs the authorization server to have statically declared a claims interaction endpoint in its configuration document.
  • When the client requests an RPT at the token endpoint with pushed claims as its first step after receiving a permission ticket.
• An authorization assessment phase (as defined in Section 3.3.4). This phase involves the authorization server assembling and evaluating policy conditions, scopes, claims, and other relevant information in evidence in order to mitigate access authorization risk. This phase occurs first in the authorization process when the client requests an RPT at the token endpoint as its first step after receiving a permission ticket without pushing any claims.
• An authorization result phase (as defined in Section 3.3.4). In this phase, the authorization server either returns a success code (as defined in Section 3.3.5), an RPT, and an optional PCT, or an error code (as defined in Section 3.3.6). If the error code is need_info or request_submitted, the authorization server provides a permission ticket, giving the client an opportunity to continue within the same authorization process.

The flow in Section 1.3 illustrates an authorization process that starts with claims collection (client-pushed claims), followed by authorization assessment resulting in a need for more claims, followed by claims collection again (interactive claims gathering with the requesting party), followed by a second round of authorization assessment resulting in RPT issuance.

If the resource server is able to provide a permission ticket from the authorization server, it responds to the client by providing a WWW-Authenticate header with the authentication scheme UMA, with the issuer URI from the authorization server's configuration document in an as_uri parameter and the permission ticket in a ticket parameter.

For example:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: UMA realm="example",
  as_uri="https://as.example.com",
  ticket="016f84e8-f9b9-11e0-bd6f-0021cc6004de"
...

If the resource server is unable to provide a permission ticket from the authorization server, then it includes a header of the following form in its response to the client: Warning: 199 - "UMA Authorization Server Unreachable".

For example:

HTTP/1.1 403 Forbidden
Warning: 199 - "UMA Authorization Server Unreachable"
...

Without an authorization server location and permission ticket, the client is unable to continue.

The client makes a request to the token endpoint by sending the following parameters:

grant_type

REQUIRED. MUST be the value urn:ietf:params:oauth:grant-type:uma-ticket.

ticket

REQUIRED. The most recent permission ticket received by the client as part of this authorization process.

rpt

OPTIONAL. Supplying an existing RPT gives the authorization server the option of upgrading that RPT instead of issuing a new one (see Section 3.3.4 for more about this option). Note: An RPT is bound to a specific resource owner, but it is outside the scope of this specification for a protected resource's location to reveal the resource owner's identity to the client, so the client may not be aware of which RPT it received is bound to which resource owner.

scope

OPTIONAL. A string of space-separated values representing requested scopes. For the authorization server to consider any requested scope in its assessment, the client MUST have pre-registered the same scope with the authorization server. The client should consult the resource server’s API documentation for details about which scopes it can expect the resource server's initial returned permission ticket to represent as part of the authorization assessment (see Section 3.3.4).

pct

OPTIONAL. If the authorization server previously returned a PCT along with an RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that some claims represented by a PCT are likely to contain identity information about a requesting party, a client supplying a PCT in its RPT request MUST make a best effort to ensure that the requesting party using the client now is the same as the requesting party that was associated with the PCT when it was issued. IThe client MAY use the PCT for the same requesting party when seeking an RPT for a different resource or at a different resource server entirely. See Section 5.1.2 for additional PCT security considerations. See Section 3.3.5 for the form of the authorization server's response with a PCT.

claim_token_format

OPTIONAL. If this parameter is used, it MUST appear together with the claim_token parameter. A string specifying the format of the claim token in which the client is directly pushing claims to the authorization server. The string MAY be a URI.

claim_token

OPTIONAL. If this parameter is used, it MUST appear together with the claim_token_format parameter. A string containing directly pushed claim information in the indicated format, base64url encoded if it is not already so encoded. The client MAY provide this information on a first or subsequent request to this endpoint. The client and authorization should have pre-negotiated any claim token format features that require special interpretation. For example, if the referenced format equates to OpenID Connect [OIDCCore] ID tokens and the claim token contains audience restrictions, the client and authorization server should together determine the proper audience values that enable successful token consumption (see Section 5.4.1 relevant security considerations).

Example of a request message with no optional parameters (line breaks are shown only for display convenience):

POST /token HTTP/1.1
Host: as.example.com
Authorization: Basic jwfLG53^sad$#f
...
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket
&ticket=016f84e8-f9b9-11e0-bd6f-0021cc6004de

Example of a request message that includes an existing RPT for upgrading, a scope being sought that was previously registered with the authorization server, and a PCT and a claim token for consideration in the authorization process:

POST /token HTTP/1.1
Host: as.example.com
Authorization: Basic jwfLG53^sad$#f
...
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket
&ticket=016f84e8-f9b9-11e0-bd6f-0021cc6004de
&rpt=sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv
&scope=read
&pct=c2F2ZWRjb25zZW50
&claim_token_format=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23IDToken
&claim_token=eyj0...

This specification provides a way to define profiles of claim token formats for use with UMA (see Section 4). The authorization server SHOULD document the profiles it supports in its configuration document.

The client redirects an end-user requesting party' to the claims interaction endpoint for whatever interactive claims-gathering processes the authorization server requires, such as presenting a questionnaire, a local or federated login form, or an opportunity to authorize persistent storage of claims for use in a later authorization process (the latter potentially being associated with a PCT). One motivation for such redirection could have been receipt of an authorization failure response containing an error_details structure with a redirect_user hint (see Section 3.3.6).

Redirecting the requesting party to the authorization server is one option for the client in beginning to engage with the authorization server as part of an authorization process. The other option is to seek issuance of an RPT at the token endpoint (see Section 3.3).

If the client intends to redirect an end-user requesting party to the claims interaction endpoint before approaching the token endpoint, this process assumes, in addition to the other assumptions in Section 3.3, that the authorization server has statically declared its claims interaction endpoint in its configuration document.

The client constructs the request URI by adding the following parameters to the query component of the claims interaction endpoint URI using the application/x-www-form-urlencoded format:

client_id

REQUIRED. The client's identifier issued by the authorization server.

claims_redirect_uri

OPTIONAL. The URI to which the client wishes the authorization server to direct the requesting party's user agent after completing its interaction. The URI MUST be absolute, MAY contain an application/x-www-form-urlencoded-formatted query parameter component that MUST be retained when adding additional parameters, and MUST NOT contain a fragment component. The authorization server SHOULD require all clients to register their claims redirection endpoint. Claims redirection URIs are different from the redirection URIs defined in [RFC6749] in that they are intended for the exclusive use of requesting parties and not resource owners. Therefore, authorization servers MUST NOT redirect requesting parties to pre-registered redirection URIs defined in [RFC6749] unless such URIs are also pre-registered specifically as claims redirection URIs. If the URI is pre-registered, this URI MUST exactly match one of the pre-registered claims redirection URIs, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison).

ticket

REQUIRED. The most recent permission ticket received by the client as part of this authorization process.

state

RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user agent back to the client. The use of this parameter is for preventing cross-site request forgery.

Example of a request issued by a client application (line breaks are shown only for display convenience):

GET /rqp_claims?client_id=some_client_id&state=abc
&ticket=016f84e8-f9b9-11e0-bd6f-0021cc6004de
&claims_redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fredirect_claims HTTP/1.1
Host: as.example.com

At the conclusion of a successful interaction with the requesting party, the authorization server returns the requesting party to the client, adding the following parameters to the query component of the claims redirection URI using the application/x-www-form-urlencoded format:

ticket

REQUIRED. A permission ticket that allows the client to make further requests to the authorization server during this authorization process. The value MUST NOT be the same as the one the client used to make its request.

state

OPTIONAL. The same state value that the client provided in the request. It MUST be present if and only if the client provided it.

Note: Interactive claims-gathering processes are out of scope of this specification. The purpose of the interaction is for the authorization server to gather information for its own authorization assessment purposes. This redirection does not involve sending any of the information back to the client.

Prior to its redirecting the end-user requesting party back and preparatory to issuing a PCT, the authorization server MAY use the interactive claims-gathering process to gather authorization for persisting claims across authorization processes.

The client MUST ignore unrecognized response parameters. If the request fails due to a missing, invalid, or mismatching claims redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the requesting party of the error and MUST NOT automatically redirect the user agent to the invalid redirection URI.

If the request fails for reasons other than a missing or invalid claims redirection URI, the authorization server informs the client by adding an error parameter to the query component of the claims redirection URI as defined by Section 4.1.2.1 of [RFC6749].

Example of a response issued by an authorization server (line breaks are shown only for display convenience):

GET /redirect_claims?&state=abc
&ticket=cHJpdmFjeSBpcyBjb250ZXh0LCBjb250cm9s HTTP/1.1
Host: client.example.com

When the authorization server has received a request for an RPT from a client (see Section 3.3), it assesses whether the client is authorized to receive the requested RPT and determines the results.

The authorization server MUST apply the following conceptual authorization assessment calculation in determining authorization results. Note: As this calculation is internal to authorization server operations, its particulars are outside the scope of this specification.

In this assessment calculation, let a set called ClientRegistered stand for the scopes for which the client pre-registered at the authorization server, either dynamically or through some static process. Let a set called ClientRequested stand for the scopes the client most recently requested at the token endpoint. Let a set called PermissionTicket stand for the scopes associated with the permission ticket presented by the client at the token endpoint.

1. Determine the set of requested scopes as follows: RequestedScopes = PermissionTicket ∪ (ClientRequested ∩ ClientRegistered).
2. Determine all operative policy conditions, and claims and other relevant information serving as input to them, for each scope assocated with RequestedScopes and evaluate its authorization status. Note: Claims and other information gathered during one authorization process may become out of date in terms of their relevance for future authorization processes. The authorization server is responsible for managing such relevance wherever information associated with a PCT, or other persistently stored information, is used as input to authorization, including policy conditions themselves. Note: Since the authorization server's policy expression and evaluation capabilities are out of scope, any one implementation might take a simple or arbitrarily complex form, with varying abilities to combine or perform calculations over claims and their values. For example, logical operations such as accepting "either claim value A or B" as correct may be possible.
3. For each scope that passes the evaluation, add it to a set called CandidateGrantedScopes.

In the authorization results phase, the authorization server examines the CandidateGrantedScopes set to determine whether to issue an RPT and what permissions should be associated with it.

• If the value of CandidateGrantedScopes is null, the result is authorization failure and the authorization server MUST subsequently issue one of the error codes (Section 3.3.6).
• If the value is non-null and CandidateGrantedScopes = RequestedScopes, then the authorization server MUST subsequently respond with a success code and issue an RPT (upgrading as appropriate; see below).
• If the value is non-null and CandidateGrantedScopes < RequestedScopes, the authorization server MUST subsequently issue either an RPT containing CandidateGrantedScopes (upgrading as appropriate; see below), or one of the error codes. The reason for the two options is that granting only partial scopes may not be useful for the client's and requesting party's purposes in seeking authorization for access.

The authorization server MAY implement RPT upgrading. It is RECOMMENDED for the authorization server to document its practices regarding RPT upgrades and to act consistently with respect to RPT upgrades so as to enable clients to manage tokens efficiently. If the authorization server has implemented RPT upgrading, the client has submitted an RPT in its request, and the result is success, the authorization server adds the permissions from the client's previous RPT to the RPT it is about to issue, setting the value of the upgraded property in its response containing the upgraded RPT to true (see Section 3.3.5).

The following example illustrates authorization assessment and partial results:

• Assume two resources at a resource server, photo1 with scopes view, print, and download and photo2 with scopes view, print, download, and link.
• The resource owner has set policy conditions that allow access to photo1 only by requesting parties that can provide claims proving they are family members, and that allow access to photo2 only by requesting parties that can provide claims saying they agree not to download, sell, or market any photo.
• The client has pre-registered with the authorization server for download scope (so ClientRegistered contains download).
• The client attempts what the resource server interprets as view access to photo1.
• The nature of the resource server's API results in the authorization server's issued permission ticket representing a request for view and print scopes for photo1 on the client's behalf (so PermissionTicket contains view and print).
• The client requests download scope on the requesting party's behalf while requesting an RPT from the authorization server (so ClientRequested contains download).
• The authorization server determines that RequestedScopes contains view, print, and download.
• Based on the authorization server's evaluation of policy conditions associated with these scopes, CandidateGrantedScopes contains only view and print and not download (the dynamically requested scope), which is less than in RequestedScopes.
• The authorization server has a choice whether to issue an RPT in this case.

Note: While a reasonable approach for most scenarios is to implement the classic security stance of default-deny ("everything that is not expressly allowed is forbidden"), corner cases can inadvertently result in default-permit behavior. For example, it is insufficient simply to assume that all resources have some non-zero set of claims required for access, and then accept an empty set of supplied claims as sufficient for access.

If the authorization server's assessment process results in issuance of permissions, it returns an HTTP 200 (OK) status code with a response body containing the RPT with which it has associated the requested permissions. The authorization server MAY return a refresh token. See Section 3.6 for more information about refreshing an RPT.

The authorization server MAY add the following properties to its response:

pct

OPTIONAL. A correlation handle representing claims and other information collected during this authorization process, which the client is able to present later in order to optimize future authorization processes on behalf of a requesting party. The PCT MUST be unguessable by an attacker. The PCT MUST NOT disclose claims from the requesting party directly to possessors of the PCT. Instead, such claims SHOULD be associated by reference to the PCT or expressed in an encrypted format that can be decrypted only by the authorization server that issued the PCT. See Section 3.3.2 for more information about the end-user requesting party interaction option. See Section 5.1.2 for additional PCT security considerations.

upgraded

OPTIONAL. Boolean value. If the client submits an RPT in the request and the authorization server includes the permissions of the RPT from the request as part of the newly issued RPT, then it MUST set this value to true. If it sets the value to false or the value is absent, the client MUST act as if the newly issued RPT does not include the permissions associated with the RPT from the request.

The authorization server MAY include any of the parameters defined in Section 5.1 of [RFC6749] on its response, except that it is NOT RECOMMENDED to include the scope parameter. This is because RPTs are associated with scopes that are associated with specific resources.

If the authorization server is upgrading an RPT, and the RPT string is new rather than repeating the RPT provided by the client in the request, then the authorization server SHOULD revoke the existing RPT, if possible, and the client MUST discard its previous RPT. If the authorization server does not upgrade the RPT but issues a new RPT, the client MAY retain the existing RPT.

Example:

HTTP/1.1 200 OK
Content-Type: application/json
... 

{  
   "access_token":"sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
   "token_type":"Bearer"
}

Example with a PCT and an upgraded property in the response:

HTTP/1.1 200 OK
Content-Type: application/json
...

{  
   "access_token":"sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
   "token_type":"Bearer",
   "pct":"c2F2ZWRjb25zZW50",
   "upgraded":true
}

If the client's request to the token endpoint is insufficient for granting an RPT, the authorization server responds using an error code and corresponding HTTP status code.

invalid_grant

If the provided ticket was not found at the authorization server, or the provided ticket has expired, or the client is not authorized to have these permissions added, or any other original reasons to use this error response are found as defined in [RFC6749], the authorization server responds with the HTTP 400 (Bad Request) status code.

invalid_scope

At least one of the scopes included in the request does not match an available scope for any of the resources associated with requested permissions for the permission ticket provided by the client. The authorization server responds with the HTTP 400 (Bad Request) status code.

request_submitted

The authorization server requires intervention by the resource owner to determine whether the client is authorized to have these permissions. The authorization server responds with the HTTP 403 (Forbidden) status code. It MUST include a ticket object.

ticket

REQUIRED. A permission ticket that allows the client to make a further request to the authorization server's token endpoint as part of this same authorization process, likely some time later in "polling" fashion, when the resource owner might have completed some approval (or denial) action. The value MUST NOT be the same as the one the client used to make its request.

need_info

The authorization server needs additional information in order to determine whether the client is authorized to have these permissions. The authorization server responds with the HTTP 403 (Forbidden) status code. It MUST include a ticket object, and it MAY also include an error_details object.

ticket

REQUIRED. A permission ticket that allows the client to make a further request to the authorization server's token endpoint as part of this same authorization process, potentially immediately. The value MUST NOT be the same as the one the client used to make its request.

error_details

OPTIONAL. Provides hints about information the authorization server needs to perform authorization assessment. On receiving such hints, the client has the opportunity to engage, or engage the requesting party, in claims collection flows. At least one of its two sub-properties MUST be supplied.

required_claims

An array containing objects that describe the required claims, with the following properties:

name

OPTIONAL. A string (which MAY be a URI) representing the name of the claim; the "key" in a key-value pair.

friendly_name

OPTIONAL. A string that provides a more human-readable form of the attribute's name, which may be useful as a "display name" for use in user interfaces in cases where the actual name is complex or opaque, such as an OID or a UUID.

claim_type

OPTIONAL. A string, indicating the expected interpretation of the provided claim value. The string MAY be a URI.

claim_token_format

OPTIONAL. An array of strings specifying a set of acceptable formats for a token pushed by the client containing this claim (see Section 3.3.1). Any one of the referenced formats would satisfy the authorization server's requirements. Each string MAY be a URI.

issuer

OPTIONAL. An array of strings specifying a set of acceptable issuing authorities for the claim. Any one of the referenced authorities would satisfy the authorization server's requirements. Each string MAY be a URI.

redirect_user

The claims interaction endpoint URI to which to redirect the end-user requesting party at the authorization server to continue the process of interactive claims gathering. For example, the authorization server may require the requesting party to fill out a CAPTCHA to help prove humanness. If the requesting party is not an end-user, then no client action would be possible on receiving the hint. If a static claims interaction endpoint was also provided in the authorization server's configuration document, then this value overrides the static value. Providing a value in this response might be appropriate, for example, if the URI needs to be customized per requesting party.

Example when the ticket was not found, or the ticket has expired, or the client's request for authorization has failed outright:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
...

{  
   "error":"invalid_grant"
}

Example of a need_info response with a full set of error_details hints:

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store
...

{  
   "error":"need_info",
   "ticket":"ZXJyb3JfZGV0YWlscw==",
   "error_details":{  
      "required_claims":[  
         {  
            "name":"email23423453ou453",
            "friendly_name":"email",
            "claim_type":"urn:oid:0.9.2342.19200300.100.1.3",
            "claim_token_format":[  
               "http://openid.net/specs/openid-connect-core-1_0.html#IDToken"
            ],
            "issuer":[  
               "https://example.com/idp"
            ]
         }
      ],
      "redirect_user":"https://as.example.com/rqp_claims?id=2346576421"
   }
}

Like ordinary OAuth redirection, UMA redirection for the purpose of gathering claims from an end-user requesting party (described in Section 3.3.2) creates the potential for cross-site request forgery (CSRF) through an open redirect if the authorization server does not force the client to pre-register its claims redirection endpoint, and server-side artifact tampering if the client does not avail itself of the state parameter. The client SHOULD check that the ticket value returned by an authorization server after a claims redirect is completed has not been maliciously changed, for example by a man in the browser, by using the state parameter. (See [UMA-Impl] for advice on ways to accomplish this.) Sections 4.4.1.8, 4.4.2.5, and 5.3.5 of [RFC6819] are apropos for the UMA claims-gathering redirection flow as well.

When a client redirects an end-user requesting party to the claims interaction endpoint, the client provides no a priori context to the authorization server about which user is appearing at the endpoint, other than implicitly through the permission ticket. Since the authorization server is free to gather any claims it wishes, the effect is to "late-bind" them to the permission ticket and the state string provided by the client, with the effect of enabling the authorization server not to trust client-asserted claims. This is a desirable result and reflects one reason why the authorization server might choose to demand use of the redirect flow over the push flow. However, the client has the opportunity to switch end-users -- say, enabling malicious end-user Carlos to impersonate the original end-user Bob, who might be represented by a PCT already in that client's possession and might even have authorized the issuance of that PCT -- after the redirect completes and before it returns to the token endpoint to seek permissions.

Another issue concerns the exposure of an RPT to a requesting party, which could maliciously pass the token to an unauthorized party.

To mitigate requesting-party switching and RPT exposure threats, consider the following strategies.

• Require that the requesting party legitimately represent the wielder of the bearer token on a legal or contractual level. This solution does not reduce the risk from a technical perspective.
• The authorization server, possibly with input from the resource owner, can implement tighter time-to-live strategies around the permissions in RPTs. This is a classic approach with bearer tokens that helps to limit a malicious party's ability to intercept and use the bearer token. In the same vein, the authorization server could require claims to have a reasonable degree of freshness (which would require a custom claims profile).
• A stronger strategy is to gather claims interactively from an end-user requesting party that demonstrate that some sufficiently strong level of authentication was performed.

A PCT is similar to a refresh token in that it carries extra power over the usage of an RPT. The authorization server and client MUST keep PCTs confidential in transit and storage, and MUST NOT share any PCT with any other entity other than the issuer or issued client, respectively. The authorization server MUST maintain the binding between a PCT and the client to which it was issued.

Given that a PCT represents a set of requesting party claims, a client supplying a PCT in its RPT request MUST make a best effort to ensure that the requesting party using the client now is the same as the requesting party that was associated with the PCT when it was issued. Different clients will have different capabilities in this respect; for example, some applications are single-user and perform no local authentication, associating all PCTs with the "current user", while others might have more sophisticated authentication and user mapping capabilities.

This section discusses the threats surrounding client claim pushing (see Section 3.3.1).

Because claim tokens of any format typically contain audience restrictions and an authorization server would typically not be in the primary audience for a claim token held or generated by a client, it is RECOMMENDED to document how the client, authorization server, and any additional ecosystem entities and parties will establish a trust relationship and communicate any required keying material in a claim token profile, as described in Section 4. Authorization servers are RECOMMENDED not to accept claim tokens pushed by untrusted clients and not to ignore audience restrictions found in claim tokens pushed by clients.

In the special circumstance when an authorization server is colocated with an OpenID Provider for the requesting parties within a deployment ecosystem, then it is able to act as an OpenID Relying Party for itself. This circumstance presents an opportunity for a technical optimization of the requirement for trust because the authorization server itself issued the OAuth client credentials for the client in question, and could reasonably be the singular aud value target in an OpenID Connect ID Token pushed by the client to the token endpoint.

• URI suffix: uma2-configuration
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 2.2 in this document

• Parameter name: ticket
• Parameter usage location: client request, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.1 in this document

• Parameter name: rpt
• Parameter usage location: client request, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.1 in this document

• Parameter name: claim_tokens
• Parameter usage location: client request, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.1 in this document

• Parameter name: pct
• Parameter usage location: client request, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.1 in this document

• Parameter name: pct
• Parameter usage location: authorization server response, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.5 in this document

• Parameter name: upgraded
• Parameter usage location: authorization server response, token endpoint
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.5 in this document

• Error name: request_submitted
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.1 in this document
• Error usage location: authorization server response, token endpoint

• Error name: need_info (and its subsidiary ticket and error_details structures)
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.3.1 in this document
• Error usage location: authorization server response, token endpoint

• Hint value: pct
• Change controller: Kantara Initiative User-Managed Access Work Group - staff@kantarainitiative.org
• Specification document: Section 3.7 in this document