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 47 Next »

UMA 1.0 Core Protocol specification

http://docs.kantarainitiative.org/uma/draft-uma-core.html

This is the pretty-printed latest version, available on the Kantara site.

http://tools.ietf.org/html/draft-hardjono-oauth-umacore

This is the latest version contributed as an IETF I-D. (It may be out of date with respect to the version linked above. We don't submit I-D revisions for every little edit.)

Binding Obligations for UMA Particiants ("trust") specification

http://docs.kantarainitiative.org/uma/draft-uma-trust.html

This is the pretty-printed latest version, available on the Kantara site. (It has not yet been contributed to the IETF.)

https://github.com/xmlgrrl/UMA-Specifications

This is the GitHub repository for the spec and issues.

https://github.com/xmlgrrl/UMA-Specifications/issues

This is a direct link to the issues list.

http://tinyurl.com/umav1

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:

  • 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.
  • No labels