Versions Compared

Key

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

Abstract 

This document contains non-normative release notes produced by the User-Managed Access Work Group explaining how new versions of the UMA specifications differ from previous ones.

...

This document includes final release notes for the UMA V1.0.1 Recommendations and incomplete draft release notes for the UMA V2.0 Draft Recommendations. Please see the Disposition of Comments document for additional changes made to UMA V2.0.

Editor
  • Eve Maler
Intellectual Property Notice

...

This document contains non-normative release notes produced by the User-Managed Access Work Group explaining how new versions of the UMA specifications differ from previous ones. Please see the Disposition of Comments document for additional changes made to UMA V2.0; these changes will be incorporated into this document as well as time allows. (tbs: complete all "tbs:" tasks throughout once the specifications reach Recommendation status)

The UMA specifications use Semantic Versioning:

...

See also Summary of API and Endpoint Changes for naming changes made to some of the endpoints.

V1.0.1V2.0Comments
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)

Anchor
api-endpoint-changes
api-endpoint-changes
API and Endpoint Changes

These design changes include naming changes made to some of the endpoints.

V1.0.1V2.0Comments
.well-known/uma-configuration.well-known/uma2-configurationThe 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 (now OPTIONAL):

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

Authorization API:

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

Authorization Server Discovery Document and Metadata Changes

...

Previously, the security considerations around accepting policy-setting context information from an incompletely trusted AS were not covered. Now they cover the user_access_policy_uri property, which is the only policy-setting context information passed from AS to RS. (185) (RSR Sec 4)

Specification Reorganizations

The specifications, particularly Core Sec 3, were reorganized in the fashion of OpenID Connect, with the goal of giving a subsection to every request and response message. Other notable changes include:

...

Anchor
pre-v1.0
pre-v1.0
Pre-V1.0 Changes

Following is a catalog of notable changes to the specifications in the pre-V1.0 timeframe.

Core Changes

Internet-Draft Rev 11 to Rev 12

...

  • We decided not to progress this specification in its current form, so we will let it expire and will not reference it from Core.

...


...