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.
...
Differences and changes noted are between V2.0 and V1.0.x generally. Where the distinction between V1.0 and V1.0.1 is important, it will be noted; otherwise "UMA1" is used.
...
| Anchor | ||||
|---|---|---|---|---|
|
...
UMA1 to UMA V2.0 (draft)
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)
...
- Sequence diagram for UMA Grant, highlighting key changes from UMA1
- Sequence diagram for FedAuthz, highlighting key changes from UMA1
Version Themes
The major themes of this major version are version, as determined by the Work Group's 2016 roadmap planning process, were to:
- Increase OAuth 2.0 alignment
- Improve Internet of Things readiness
- Improve readiness for "wide ecosystems", where the requesting party and AS have no pre-established relationship
...
The two specifications were divided differently. Core and RSR were recombined into Grant (tbs: link to final) and FedAuthz (tbs: link to final), 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 (this was previously the only portion specified in RSR, 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
It is now optional to implement the features appearing in FedAuthz; thus, this specification defines a conformance level. (To receive the full benefits of "user-managed access", it is best to implement and use the features of both specifications.)
Note that drafts until late April 2017, drafts of V2.0 prior to late April 2017 still used the UMA1 organizing principle.
| Anchor | ||||
|---|---|---|---|---|
|
(256)
See also Summary of API and Endpoint Changes for some endpoint naming changes.
...
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
...