Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

UMA

...

V1 Protocol (Historical)

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

Content
SpecificationURLDescription

UMA Core

http

V1.0.1 Recommendation

https://docs.kantarainitiative.org/uma/
drafthttp
rec-uma-core-v1_0_1.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 RReg

Final V1.0.1 version of the UMA Core Recommendation.

OAuth RSR V1.0.1 Recommendation

https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html
Final V1.0.1 version of the OAuth RSR Recommendation.

UMA Core V1 Recommendation

http://docs.kantarainitiative.org/uma/rec-uma-core-v1_0.html
Final V1.0 version of the UMA Core Recommendation (obsoleted by V1.0.1).

OAuth RSR V1 Recommendation

https://docs.kantarainitiative.org/uma/
draft
rec-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.
Final V1.0 version of the OAuth Resource Set Registration Recommendation (obsoleted by V1.0.1).

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 (expired).

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
of the UMA Core specification (corresponding to rev 14 and an expired "shell" specification pointing to V1.0.1; the WG has no intent to update it).

OAuth RSR I-D rev 06

https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06
IETF I-D of 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
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.UMA Binding Obligations
of the OAuth Resource Set Registration specification (corresponding to rev 07 and an expired "shell" specification pointing to V1.0.1; the WG has no intent to update it).

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 else
UMA Binding Obligations specification (now obsolete; see the UMA Legal work).

UMA Binding Obs I-D

https://tools.ietf.org/html/draft-maler-oauth-umatrust
Latest IETF I-D of the UMA Binding Obligations specification (corresponding to rev 03 and expired; the WG has no intent to update it).

UMA on GitHub

https://github.com/
xmlgrrl
KantaraInitiative/
UMA
wg-
Specifications
uma
This is the
GitHub repository for the spec
and issues
.

UMA issues

https://github.com/
xmlgrrl
KantaraInitiative/
UMA
wg-
Specifications
uma/issues
This is a direct http
Direct link to the issues list in GitHub.

UMAWG Twitter

https://
tinyurl
twitter.com/
umav1This 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 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.

From rev 06 to 07b (not yet contributed to IETF; this section will be updated when rev 07 is contributed):

...

  • oauth_token_profiles_supported: broken out into two, pat_profiles_supported and aat_profiles_supported.
  • uma_token_profiles_supported: renamed to rpt_profiles_supported.
  • oauth_grant_types_suppored: broken out into two, pat_grant_types_supported and aat_grant_types_supported.

...

umawg
UMA group Twitter handle.

UMAWG Facebook

https://www.facebook.com/UserManagedAccess
UMA group Facebook page.
http://tinyurl.com/umav1
Short link to return to this page.