...
This is a short link you can use to direct people back to this page.
Goals in 2012
Our main 2012Q1 spec goal was to revise the IETF I-D in time for consideration at the IETF 83 meeting 25-30 March 2012, incorporating resolutions to as many open issues as possible. We also wanted to resolve major spec issues as quickly as possible to support the several active implementers we're aware of. Though IETF 83 did not take up every one of the major issues presented by UMA, concentrating (from the UMA WG's perspective) on just the charter inclusion of authorization server/resource server separation and dynamic client registration, the UMA WG met its goals of resolving issues and publishing new spec revs.
Our main 2012Q2 spec goal is to support interop activities among UMA protocol implementers and to support efforts to use and deploy UMA. As part of this goal, we will continue to burn down issues and revise the spec, along with refining our trust model document and collecting new use cases.
Recent breaking changes
Following is a catalog of breaking changes made since the 18 Jan 2012 rev.
- The resolution to issue #19 involved a breaking change in the 2 Feb 2012 rev. The XRD-formatted AM metadata residing at /.well-known/host-meta is now JSON-formatted metadata residing at /.well-known/uma-configuration.
- The requester access token has been split into two tokens, and all of the tokens have been renamed. The host access token is now the PAT. The requester access token used at the AM's API is now the AAT, and consists of vanilla OAuth. The requester access token used at the host is now the RPT. The AAT does not use the client_credentials flow, as previously required, but rather typically uses the authorization_code flow.
- The token and user authorization endpoints for the different APIs at the AM have been joined together, and are now distinguished through the "protection" scope (for the protection API) and the "authorization" scope (for the authorization API).
- The token status description format and JSON media type, and the RPT/permission delivery response, have been updated to reflect the RPT naming.
- The configuration data format has changed to reflect all the changes above.
- The Phase 2/3 flow has changed and been simplified to match the requirements of the new AAT and RPT.
- The requester now asks for permission in a back-channel interaction, and the AM now produces a need_claims error that instructs the requester to use a redirect-based claims-gathering flow (renamed from "authorization flow").
Other recent changes of note that do not affect implementations:
...
Recent breaking changes
Following is a catalog of notable changes.
- Breaking changes:
- Section 1.5: The authorization server configuration data now allows for providing a dynamic client registration endpoint (now defined by the official OAuth dynamic client registration spec), rather than just serving as a flag for whether the generic feature is support.
- Sections 3.1.1 and 3.1.2: The am_uri header has been renamed to as_uri due to terminology changes (see below).
- Section 3.1.2: The OAuth error "insufficient_scope" is now a central part of the authorization server's response to a client with a valid RPT and insufficient scope. This aligns UMA more closely with OAuth as a profile thereof (stay tuned for more possible tweaks in this general area, e.g. in WWW-Authenticate).
- Other changes of note:
- Terminology has been changed wholesale from UMA-specific terms to OAuth-generic terms.
- Authorization manager (AM) is now authorization server.
- Host is now resource server.
- Authorizing user is now resource owner.
- Requester is now client.
- Some additional terms and concepts have been tweaked, enhanced and clarified.
- Scope is now scope type (likely to change back due to feedback).
- Authorization data is now defined as a generic category, of which permissions are an instance.
- RPT now stands for requesting party token instead of requester permission token.
- UMA is more explicitly defined as a profile of OAuth.
- References have been added to the OAuth token introspection spec proposal, though it is not fully used yet (stay tuned for breaking changes here).
- The resource set registration process (phase 1) has been moved to a separate modular spec that is designed to be usable by other OAuth-based technologies along with UMA.
- Terminology has been changed wholesale from UMA-specific terms to OAuth-generic terms.