Versions Compared

Key

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

...

V1.0.1V2.0Comments
.well-known/uma-configuration.well-known/uma2-configuration The same authorization server can have two different discovery endpoints, one serving UMA1 metadata and one serving UMA V2.0 metadata.

OAuth endpoints:

  • token endpoint
  • authorization endpoint

OAuth endpoints:

  • token endpoint
  • authorization endpoint
Previously, the token endpoint issued both PATs and AATs. In V2.0, the token endpoint issues PATs, and now RPTs as well; there are no AATs. (Note that the authorization endpoint is used for authenticating resource owners only, not requesting parties.)

Protection API:

  • resource set registration endpoint/API
  • permission registration endpoint
  • token introspection endpoint

Protection API:

  • resource registration endpoint/API
  • permission endpoint
  • token introspection endpoint
 
In the case of the first two endpoints, there are both design (primarily syntax; (tbs: link to section(s))) and naming differences, which also affects their corresponding metadata in the authorization discovery document.

Authorization API:

  • RPT endpoint
n/a-The prior function of the RPT endpoint is served by the OAuth token endpoint.
Requesting party claims endpointClaims interaction endpoint 

...

Changes to AS-Client, RS-Client, and AS-Requesting Party Interfaces (Now UMA Grant)

Authorization Server Rotates Permission Ticket

...

After the AS initially generates the permission ticket and the RS conveys it to the client, whenever the client subsequently approaches the AS token endpoint or redirects the requesting party to the AS claims gathering endpoint, the AS is required to rotate the value of the permission ticket every time it hands a ticket value back to the client. This action obsoletes any need for the Claims-Gathering Extension specification (see this explanation).

Token Endpoint Replaces RPT Endpoint

...

and Client-Side Communications Defined as Grant

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)

...

Changes to AS-RS Interface, the Protection API (Now Federated Authorization)

Extraneous URL Parts Removed From Resource Registration API

(155) tbs

scopes parameter renamed to resource_scopes in Introspection Response Object

(158) tbs

Anchor
local-validation
local-validation
Options to Validate Token Locally Explicitly Allowed

(261) tbs

Scope Description Documents No Longer Expected to Resolve at Run Time When Scopes Are URLs

(269) tbs

Resource and Scope Description Documents Gain Description Parameters

(271, 272) tbs

Resource Descriptions Lose uri Parameter

(?) tbs

Non-OAuth-Based Errors Removed Where Possible

(304) tbs

Enabled Requesting Multiple Permissions and Permissions With Zero Scopes

(317, ?) tbs

scopes Parameter in Resource Description Document Renamed to resource_scopes

(318) tbs

permissions Claim in Token Introspection Object Must Be Used

(322 (tbs: link)) If token introspection is used (see Options to Validate Token Locally Explicitly Allowed), the introspection object can no longer be extended to replace the permissions claim with an entirely different structure.

...

Anchor
to-v101
to-v101
From V1.0 to V1.0.1

...