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 permission ticket generation ecosystem has been 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. An authorization process is still ongoing while the authorization server is still generating permission tickets. (275, 279, 298)
Only One Pushed Claim Token Now Allowed at a Time
In UMA1, the mechanism for claim token pushing was a JSON-encoded request message sent to the RPT endpoint, optionally including with a claim_tokens array each of whose objects had a format parameter and a token parameter. In UMA2 (Grant Sec 3.3.4), , due to increased alignment with OAuth, this structure was flattened and the request message – now sent to the token endpoint as application/x-www-form-urlencoded format – contains each of the inner parameters only once. (If it is desired to send multiple claim tokens in a single request message, a compound claim token format could be defined.)
RPT Upgrading Logic Improved
...
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
...