UMA 1.0 core protocol specification
- Latest version on Kantara site (nice formatting): http://docs.kantarainitiative.org/uma/draft-uma-core.html
- Latest version contributed as an IETF Internet-Draft: http://tools.ietf.org/html/draft-hardjono-oauth-umacore
- GitHub repository where spec text and issues are managed: https://github.com/xmlgrrl/UMA-Specifications
- Direct link to open issues: https://github.com/xmlgrrl/UMA-Specifications/issues
You can use http://tinyurl.com/umav1 to direct people back to this page.
Our main 2012Q1 spec goal is 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 know of several active implementers and want to resolve outstanding issues as quickly as possible to support interop activities in 2012H1.
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:
- Token types are now called token profiles, claim types are now called claim profiles, and these changes are reflected in the configuration parameter names.
- The token and claim profiles defined in this spec now have their own subsections that appear in the TOC for easier reference.