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.
...
The UMA V2.0 specifications (Grant, FedAuthz) (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".(Note that drafts of 2, it is best to implement and use the features of both specifications.)
Note that drafts of V2.0 prior to late April 2017 used the 1.0.1 UMA1 organizing principle.)
| Anchor | ||||
|---|---|---|---|---|
|
(256)
See also the next section for for some endpoint naming changes.
| 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 | ||||
|---|---|---|---|---|
|
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 (
...
Now
...
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)
tbs
tbs: to be continued...
...
| Anchor | ||||
|---|---|---|---|---|
|
...
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
...