UMA Release Notes
...
| Table of Contents | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
| Anchor | ||||
|---|---|---|---|---|
|
...
The UMA V1.0 specifications (Core, RSR) were approved in March 2015. The UMA V1.0.1 specifications (Core, RSR) are currently in draft form; the Work Group's goal is to see their completion 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 GitHub issues that drove this release. Where possible, specific section numbers will be referenced; follow the issue number links to find related commit links and see the exact specification wording that changed.
...
Previously, the matching of the "extents of access" of the requested permission registered by the RS and the permission ticket issued by the AS was implicit. Now it is spelled out. (175) (Core Sec 3.2)
Permission Ticket on Redirect Back to Client (+Client)
Previously, the AS was required to repeat the client’s permission ticket back to it in a ticket property when offering a redirect_user hint in error_details. Now this is optional and the client is encouraged to ignore the property's value, preparatory to removing the property entirely in a future UMA version. The reason is that the value can't be guaranteed good; repeating the value was in order to save the client work; and having the client check the value would ultimately have caused both sides work for no gain. (205) (Core Sec 3.5.4.2)
PUT Means Complete Replacement
Previously, the requirement for an Update method in resource set registration to completely replace the previous resource set description was implicit. Now it is spelled out. (177) (RSR Sec 2.2.3)
Default-Deny for Authorization Data Issuance
Previously, a naive implementation could have resulted in accidental default-permit authorization data issuance in some cases. Now a default-deny authorization assessment model has been made explicit, with an example given of how implementations could get into trouble. (194) (Core Sec 3.5.2)
base64url-Encoded Claims (+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)
New and Changed Security Considerations
...
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)
Changed 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 specification was missing an important caveat: Based on a client's initial RPT-free resource request, the RS needs to know the correct AS, PAT, and resource set ID to include in its follow-on call to the permission request endpoint at the AS. Thus, the API of the RS needs be structured so that it can derive this information from the client's request. Now this caveat appears in several locations. (161, 162, 225)
Adjustment of Other Protected Resource API Constraints (+Client)
Previously, the specification wording was inconsistent and problematic regarding how the RS responds to a client request accompanied by no RPT or an RPT with insufficient authorization data (assuming permission request success). Now the ability not to respond at all is more fully acknowledged; all responses intended to be interpreted in an UMA fashion are required to be accompanied by a WWW-Authenticate: UMA header; the permission ticket is required to be returned in a new ticket parameter in that header; complete freedom is given regarding the RS's choice of HTTP status code; and only in the case of a 403 choice is a ticket in a JSON-encoded body suggested, preparatory to removing the body option in a future UMA version. The rationale for this somewhat dramatic set of changes is that the original prescription to return HTTP status code 403 was incorrect; the specification gave too little guidance about responses other than 403 responses to be useful for client interoperability; and its requirement to return the permission ticket in a JSON-encoded body regardless of expected content type was an issue. (163, 164, 168) (Core Sec 3.3.1)
Solution for Permission Registration Failure (+Client)
Previously, the specification gave no guidance on how the RS should respond to the client in case of permission registration failure at the AS. Now, if the RS responds at all, it is required to substitute a Warning: 199 - "UMA Authorization Server Unreachable" header for WWW-Authenticate: UMA. (176) (Core Sec 3.3.2)
Authorization Server URI to Return to Client (+Client)
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 and Changed Security Considerations
...