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.
...
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Note that until late April 2017, drafts of V2.0 still used the UMA1 organizing principle.
| Anchor | ||||
|---|---|---|---|---|
|
...
Terminology Changes
(256)
See also Summary of API and Endpoint Changes for naming changes made to some of the endpoints.
| V1.0.1 | V2.0 | Comments |
|---|---|---|
| configuration data | metadata, discovery document | For better clarity and OAuth alignment |
| policies | authorization grant rules, policy conditions | For 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 and Endpoint Changes
These design changes include naming changes made to some of the endpoints.
| V1.0.1 | V2.0 | Comments |
|---|---|---|
.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:
| OAuth endpoints:
| 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:
| Protection API (now OPTIONAL):
| 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 server discovery document. |
Authorization API:
| - | The prior function of the RPT endpoint is served by the OAuth token endpoint. |
| Requesting party claims endpoint | Claims interaction endpoint |
...
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 | ||||
|---|---|---|---|---|
|
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
...