UMA Release Notes
...
This document contains non-normative release notes produced by the User-Managed Access Work Group for various versions of the UMA specifications.
The Work Group has decided to use uses Semantic Versioning for its specification version numbers. In short:
Given a version number MAJOR.MINOR.PATCH, increment the:
...
The UMA V1.0 specifications (Core, RSR) were approved in March 2015. The UMA V1.0.1 specifications (Core, RSR) are currently (Sep 2015) in draft form; the Work Group's goal is to see their finalization by the end of calendar 2015. The following release notes are therefore also in draft form. They are catalogued by their impact on software entities, with references to the relevant GitHub issues that drove this release. Where possible, specific section numbers will be are referenced; follow the issue number links to find related commit links and see the exact specification wording that changedthey link to discussions and related commits.
The following themes animated the V1.0.1 release process:
- Account for V1.0 lessons learned out of the gate
- Timeline Achieve timeline predictability and minimization of disruption for V1.0 implementers
- EfficiencyAchieve efficiency, speed, and accuracy in spec specification revisions
- Issue Achieve issue solution consistency with OAuth 2.0 and OpenID Connect where possible
- Prioritize Within the allotted time, prioritize first blocking and critical bug fixes first, and then low-impact spec specification and implementation changes
Changes Affecting Authorization Server (
...
+Client) Implementations
Following are specification changes in V1.0.1 that affect authorization servers, and possibly clients that interact with them as well , (denoted with (+Client) in the title).
AS Now Has Unique Redirect URI Endpoint for Claims Gathering (+Client)
...
Previously, the wording about base64url-encoding pushed claims was ambiguous about whether double-encoding was necessary in the case of claim formats that were already base64url-encoded. Now it has been clarified that double-encoding should not be performed. (206) (Core Sec 3.6.2)
...
Enhanced Security Considerations
Previously, the security considerations around accepting policy-setting context information from an incompletely trusted RS only covered "bad icon URIs". Now they cover all such policy-setting context information, following roughly the OAuth example. (151) (RSR Sec 4)
Previously, the security considerations around client-pushed claims were explored only in a very cursory fashion in the body of the text. Now they are treated at length in a new subsection. (160) (Core Sec 7.4.1)
...
Enhanced Privacy Considerations
Previously, little was said about privacy implications of requesting party claims being transmitted to the AS. Now this section has been greatly expanded. (211) (Core Sec 8.2)
Changes Affecting Resource Server (and +Client) Implementations
Following are specification changes in V1.0.1 that affect resource servers, and possibly clients that interact with them as well , (denoted with (+Client) in the title).
Caveat About Protected Resource API Constraint
...
Previously, the value of the as_uri property that the RS returns to the client was described somewhat vaguely as the authorization server's URI. Now it has been clarified to be the issuer URI as it appears in the AS configuration data of the AS. (199) (Core Sec 3.3.1)
New
...
Security Considerations
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)
...