...
Following are handy links to the UMA specs and related materials.
| ContentSpecification | URL | Description | ||
|---|---|---|---|---|
UMA Core V1 Recommendation | http://docs.kantarainitiative.org/uma/ | draftrec-uma-core-v1_0.html | This is the pretty-printed latest version, available on the Kantara site. It may be more up to date than the version last contributed as an IETF I-D. | OAuth RRegFinal V1.0 version of the UMA Core Recommendation. |
UMA Core latest Recommendation | http://docs.kantarainitiative.org/uma/rec-uma-core.html | Latest version of the UMA Core Recommendation (V1.0 or later). | ||
UMA Core latest draft | http://docs.kantarainitiative.org/uma/draft-uma-core.html | Latest draft of the UMA Core specification before whatever the latest Recommendation is (V1.0 or later). | ||
OAuth RSR V1 Recommendation | https://docs.kantarainitiative.org/uma/rec-uma-core.html | Final V1.0 version of the OAuth Resource Set Registration Recommendation. | ||
OAuth RSR latest Recommendation | https://docs.kantarainitiative.org/uma/rec-uma-core.html | Latest version of the OAuth Resource Set Registration Recommendation (V1.0 or later). | ||
OAuth RSR latest draft | http://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html | This is the pretty-printed latest version of a module that covers resource set registration, which UMA and other OAuth-based specs can use, available on the Kantara site. It may be more up to date than the version last contributed as an IETF I-D.Latest draft of the OAuth Resource Set Registration specification before whatever the latest Recommendation is (V1.0 or later). | ||
UMA Core I-D rev 13 | https://tools.ietf.org/html/draft-hardjono-oauth-umacore-13 | IETF I-D of the UMA Core specification corresponding to the V1.0 Recommendation. | ||
UMA Core I-D | http://tools.ietf.org/html/draft-hardjono-oauth-umacore | This is the latest version contributed as an Latest 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-Dof the UMA Core specification (as of this writing, currently corresponding to V1.0, but could change). | |
OAuth RSR I-D rev 06 | https://tools.ietf.org/html/draft-hardjono-oauth-resource-regThis is the latest version contributed as an-06 | 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 Obligationsof the OAuth Resource Set Registration specification corresponding to the V1.0 Recommendation. | ||
OAuth RSR I-D | https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg | Latest IETF I-D of the OAuth Resource Set Registration specification (as of this writing, currently corresponding to V1.0, but could change). | ||
UMA Binding Obs | 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 or anywhere elseLatest UMA Binding Obligations specification. | ||
UMA Binding Obs I-D | https://tools.ietf.org/html/draft-maler-oauth-umatrust | Latest IETF I-D of the UMA Binding Obligations specification. | ||
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 Direct link to the issues list in GitHub. | ||
Spec short Short link | http://tinyurl.com/umav1 | This is a short link you can use to direct people back Short link to return to this page. |
Breaking and notable changes
Following is a catalog of notable changes.
UMA Core changes
- Notable changes:
- Enhanced the Security Considerations section.
...
- 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 supported. The name changed to dynamic_client_endpoint.
- 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.
...
OAuth RSR changes
- Breaking changes:
- Changed the PUT method for the purpose of resource set creation at the authorization server, to POST. This had other rippling changes, such as removing the usage of If-Match, the precondition_failed error, ETag usage, and the privacy considerations warning about mapping real resource set names to obscured names that remove personally identifiable information.
- Changed the name of the policy_uri property to user_access_policy_uri to differentiate it from the OAuth property of (formerly) the same name
- Other changes of note:
- Clarified that user_access_policy_uri is allowed on Create, Read, and Update, and also now allow it on Delete and List too.
- Enhanced the Security Considerations section.
...