UMA 1.0 Core Protocol

...

Following are handy links to the UMA specs and related materials.

Content	URL	Description
UMA Core	http://docs.kantarainitiative.org/uma/draft-uma-core.html	This is the pretty-printed latest version, available on the Kantara site.
OAuth RReg	http://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html	This is the pretty-printed version of a module that covers resource set registration, which UMA and other OAuth-based specs can use.
UMA Core I-D	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.)

...

OAuth RReg I-D	https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg	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.)
UMA Binding Obligations	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.)
UMA on GitHub	https://github.com/xmlgrrl/UMA-Specifications	This is the GitHub repository for the spec and issues.
UMA issues	https://github.com/xmlgrrl/UMA-Specifications/issues	This is a direct link to the issues list.
Spec short link	http://tinyurl.com/umav1	This is a short link you can use to direct people back to this page.

Recent breaking changes

Following is a catalog of notable changes.

From I-D rev 05 to 06:

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