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.
...
Where a change relates to an a GitHub issue recorded in GitHub, the linked number is provided.
Differences and changes noted are between V2.0 and V1.0.x n generally. Where the distinction between V1.0 and V1.0.1 is important, it will be noted; otherwise "UMA1" is used.
...
The two specifications were divided differently. Core and RSR were recombined into Grant (tbs: link to final) and and FedAuthz (tbs: link to each final spec), as follows:
- All communications of the client and requesting party appear in Grant. This specification formally defines an extension OAuth grant.
- The communications of the resource owner and resource server with the AS appear in FedAuthz. This includes:
- Policy setting (outside the scope of UMA)
- PAT definition and issuance
- Protection API
- Resource registration (previously, RSR specified only this endpoint/API and Core specified everything else)
- The RS's permission requests at the AS
- The RS's token introspection at the AS
...
tbs: discuss implications, step-up authentication (154, 264)
Deprecated Response-Body Permission Ticket Return Option By RS Removed
In UMA V1.0.1 the RS was able to return the initial permission ticket to the client in the response body for backwards compatibility with UMA V1.0, but this option was deprecated; now this option has been removed. (233)
Permission Ticket Return By AS With Redirect-User Hint No Longer Deprecated
In UMA V1.0.1 the AS was able to return the permission ticket to the client along with the redirect_user hint, but the client was not supposed to depend on ticket accuracy, and the supply of this ticket was deprecated. Now all permission tickets directly supplied by the AS are rotated and the value is safe for the client to depend on. (233)
need_info Response Structured Flattened
...
It has been clarified that the AS can issue a refresh token and the client can use the refresh token grant to attempt to get a new RPT with it. See Grant Sec 3.3.5 and Sec 3.6. (238, 284)
Authorization Assessment Gains Precision
Inputs to authorization assessment and results calculation are more normative and precise. It is also now possible for permissions with zero scopes to be granted. See Grant Sec 3.3.4. (266, 310, 317)
Permission Ticket Ecosystem Rationalized
tbs: The permission ticket generation ecosystem was cleaned up; always generated is rationalized. In UMA2, a permission ticket is always generated, and the value rotated, in cases of a redirect back from the claims interaction endpoint and in cases of need_info and request_submitted errors from token endpoint requests, and never in cases of other errors. (153?, 154?, . An authorization process is still ongoing while the authorization server is still generating permission tickets. (275, 279, 298)
RPT Upgrading Logic Improved
tbs: Included UMA2 includes more comprehensive normative logic around RPT upgrading (281)
Token Revocation Clarifications
tbs: Clarified that token revocation is viable (295)
Downscaling Logic Clarifications
tbs: Ensured the logic of downscoping is properly defined given that UMA scopes are bound to resources; clarified AS does not perform authorization assessment in this context (306)
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 | ||||
|---|---|---|---|---|
|
(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
Resource Descriptions Lose uri Parameter
...
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.
...
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
...