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. 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...
AAT Removed in Favor of PCT
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
The JSON nested object structure of the need_info error response from the AS has been flattened. Now it directly contains a permission ticket and either a required_claims or a redirect_user hint (or both). See Grant Sec 3.3.6. (237, 308)
New Refresh Token Clarity
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 in cases of redirect back from 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?, 275, 279, 298)
RPT Upgrading Logic Improved
tbs: Included 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)
...
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
...