Versions Compared


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


The UMA V2.0 specifications (GrantFedAuthz) (tbs: link to final) are in Draft Recommendation form. This section will be completed, and updated as required, as the specifications progress to Recommendation status. (tbs: add links to sections throughout)

Version Themes

The themes of this major version are to:


The two specifications were divided differently. Core and RSR were recombined into Grant (tbs: link to final) and FedAuthz (tbs: link to final), divided in this wayas follows:

  • All communications of the client and requesting party with the AS moved to appear in Grant. This specification formally defines an extension OAuth grant.
  • The communications of the resource owner and resource server with the AS moved to appear in FedAuthz. This includes:
    • Policy setting (outside the scope of UMA)
    • PAT issuance
    • Protection API
      • Resource registration (formerly this was previously the only portion specified in RSR)
      • The RS's permission requests at the AS (formerly in Core)
      • The RS's token introspection at the AS (formerly in Core)

It is now optional to implement the features appearing in FedAuthz; thus, this specification defines a conformance level. However, it is best to implement both specifications to (To receive the full benefits of "user-managed access", it is best to implement and use the features of both specifications.)

(Note that drafts of 2V2.0 prior to late April 2017 used the 1.0.1 UMA1 organizing principle.)

Summary of Terminology Changes


See also the next section for also  for some endpoint naming changes.

configuration datametadata, discovery documentFor better clarity and OAuth alignment
policiesauthorization grant rules, policy conditionsFor better consistency
protection API token (PAT)protection API access token (PAT)For better clarity

resource set, resource set registration

resource, resource registration (protected while registered)

For better clarity and OAuth alignment

authorization API

UMA grant (an extension OAuth grant)

Result of redesign (tbs: point to 153/165 subsection)
authorization API token (AAT)goes away; a new related token is persisted claims token (PCT)Result of redesign (tbs: point to 154/264 subsection)

register a permission (for permission ticket)

request (one or more) permission(s) (on behalf of a client)

For better clarity

trust elevation

authorization process and authorization assessment

Result of redesign (tbs: point to 266/310/317 subsection)

claims pushing + claims gathering = (n/a)

claims pushing + claims gathering = claims collection

For better consistency

step-up authentication

(n/a); just authorization process

Result of redesign (tbs: point to 154/264 subsection and 266/310/317 subsection)

RPT as an UMA access token

RPT as an OAuth access token

Result of redesign (tbs: point to 153/165 subsection)

Summary of API and Endpoint Changes

These design changes include some endpoint naming changes.


UMA's endpoint and feature discovery mechanism was defined in total by its V1.0.1 Core specification. V2.0 makes use of the OAuth discovery mechanism instead. V2.0 also eliminates metadata fields already defined by the OAuth discovery or OpenID Connect specification. The Grant (Sec 2) and FedAuthz (Sec 2) specifications each define only the metadata fields they require. (59, 157, 159, 305)

Changes to AS-Client


, RS-Client, and AS-Requesting Party Interfaces (




UMA Grant


All client-involved interfaces were codified in V2.0 as the UMA grant, an OAuth extension grant.


Permission Ticket Rotation


The specialized RPT endpoint was removed in favor of using the standard OAuth token endpoint. A formal extension OAuth grant was defined, working with regular OAuth capabilities and OAuth error codes to the extent possible. This enabled reuse of large portions of the threat model, the client type model, the ability to use client credentials to be authenticated at the token endpoint (see the next section for additional discussion). (153, 165)

tbs: to be continued...

Changes to


AS-RS Interface


, the Protection API


(Now Federated Authorization)





From V1.0 to V1.0.1