Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

UMA Release Notes

Abstract 

This document contains non-normative release notes produced by the User-Managed Access Work Group for various versions of the UMA specifications.

Status

This document is currently under active development.

Editor
  • Eve Maler
Intellectual Property Notice

The User-Managed Access Work Group operates under Kantara IPR Policy - Option Patent & Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable And Non discriminatory (RAND) (HTML version) and the publication of this document is governed by the policies outlined in this option.

Table of Contents 

Introduction

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 Semantic Versioning for its specification version numbers. In short:

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

From V1.0 to V1.0.1 (draft)

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 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.

The following themes animated the V1.0.1 release process:

  • Account for V1.0 lessons learned out of the gate
  • Timeline predictability and minimization of disruption for V1.0 implementers
  • Efficiency, speed, and accuracy in spec revisions
  • Issue solution consistency with OAuth 2.0 and OpenID Connect where possible
  • Prioritize blocking and critical bug fixes first, and then low-impact spec and implementation changes

Changes Affecting Authorization Server (and 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 client was instructed to present the ordinary OAuth redirect_uri endpoint to which the AS should redirect requesting parties back after claims gathering, but this was ambiguously specified and incorrect. Now the client has a unique endpoint, claims_redirect_uri, that it needs to register. (144)

Permission Ticket Lifecycle Management (+Client)

Previously, little guidance was offered on how to manage permission tickets. Now some implications are explored, particularly as they relate to client interaction. (172) (Core Sec 3.2.2)

Requested Permission and Permission Ticket Matching

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)

New and Changed 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)

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.

New and Changed 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, which is the only policy-setting context information passed from AS to RS. (185) (RSR Sec 4)

  • No labels