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 specialized RPT endpoint was removed in favor of using the standard OAuth token endpoint (Grant Sec 3.3.1). A formal extension OAuth grant was defined (same section), working with regular OAuth capabilities and OAuth error codes to the extent possible (Sec 3.3.6). This enabled reuse of large portions of the threat model and the client type model, along with the ability to use for the client to request scopes and to authenticate using its own client credentials at the token endpoint (see the next section for additional discussion). (153, 165)
...
UMA2 ensures that the logic of downscoping during token refreshing is properly defined given that UMA scopes are bound to resources, and clarifies that the AS does not perform authorization assessment in this context (Grant Sec 3.6). (306)
Changes to AS-RS Interface
...
/Protection API (Now Federated Authorization)
Resource Registration Endpoint
Extraneous URL Parts Removed From Resource Registration API
(155) tbs
scopes parameter renamed to resource_scopes in Introspection Response Object
(158) tbs
...
(261) tbs
...
The API available at the resource registration endpoint required the path to contain the string resource_set. This string has ben removed (FedAuthz Sec 3.2). (155)
Scope Description Documents No Longer Expected to Resolve at Run Time When Scopes Are URLs
(269) tbsThe AS is no longer expected to resolve scope description details at resource registration time or at any other run-time requirement (FedAuthz Sec 3.1.1). (269)
Resource Descriptions Lose uri Parameter
The uri parameter for resource descriptions was removed.
Resource and Scope Description Documents Gain Description Parameters
...
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
...
Resource description documents and scope description documents each now have a new parameter, description, for a human-readable string describing the resource or scope (respectively) at length. (271, 272)
scopes Parameter in Resource Description Document Renamed to resource_scopes
The scopes parameter in the resource description document has been renamed to resource_scopes (FedAuthz Sec 3.1). (318)
Permission Endpoint
Enabled Requesting Multiple Permissions and Permissions With Zero Scopes
It is now possible for the RS to request multiple permissions on the client's behalf, not just one; this enables the RS to request "packages" of multiple resources that are likely to need to be accessed together. It is also possible for the RS to supply zero scopes on a requested permission (FedAuthz Sec 4.1); this is because the client can request its own scopes directly from the AS (for more discussion see Token Endpoint Replaces RPT Endpoint; Client-Side Communications Defined as Extension Grant). (317)
Token Introspection Endpoint
scopes parameter renamed to resource_scopes in Introspection Response Object
The scopes parameter in the token introspection response object has been renamed to resource_scopes (FedAuthz Sec 5.1.1). (158)
| Anchor | ||||
|---|---|---|---|---|
|
In UMA2, the RPT is explicitly a type of OAuth access token, and it has been clarified that the token can be self-contained and valided locally by the RS, or introspected at the AS at run time, or its cached value used as appropriate (FedAuthz Sec 5). (261)
permissions Claim in Token Introspection Object Must Be Used
(322) If token introspection is used (see see Options Not to Validate Use Token Locally Introspection Explicitly Allowed), the introspection object can no longer be extended to replace the the permissions claim claim with an entirely different structure. (322)
...
| 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
...