UMA
...
V1 Protocol (Historical)
Following are handy links to the UMA specs and related materials.
ContentSpecification | URL | Description |
---|
UMA Core |
httpdrafthttpThis 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 | | Final V1.0.1 version of the OAuth RSR Recommendation. |
UMA Core V1 Recommendation | | Final V1.0 version of the UMA Core Recommendation (obsoleted by V1.0.1). |
OAuth RSR V1 Recommendation | |
draft It may be more up to date than the version last contributed as an IETF I-DThis 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.Final V1.0 version of the OAuth Resource Set Registration Recommendation (obsoleted by V1.0.1). |
UMA Core I-D rev 13 | | IETF I-D of the UMA Core specification corresponding to the V1.0 Recommendation (expired). |
UMA Core I-D | |
This is the latest version contributed as an . 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 | | IETF I-D of the OAuth Resource Set Registration specification corresponding to the V1.0 Recommendation. |
OAuth RSR I-D | |
This is the latest version contributed as an . It may be out of date with respect to the version linked above. We don't submit I-D revisions for every little editof 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 |
ObligationsThis is the pretty-printed latest version, available on the Kantara site. It has not yet been contributed to the IETF or anywhere elseUMA Binding Obligations specification (now obsolete; see the UMA Legal work). |
UMA Binding Obs I-D | | 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 | |
xmlgrrlUMASpecificationsThis is the GitHub repository for the spec |
and issuesxmlgrrlUMASpecificationsThis is a direct httpDirect link to the issues list in GitHub. |
Spec short link | tinyurlumav1This 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 07:
- Breaking changes:
- Section 1.5: Some properties in the the authorization server configuration data have been renamed, and others broken out into multiple properties with different names. The wording around reserved keywords vs. URIs as string values was also cleaned up.
- 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.
- Section 3.4.2: Error code names were cleaned up.
- expired_requester_ticket: renamed to expired_ticket.
- invalid_requester_ticket: renamed to invalid_ticket.
- Other changes of note:
- Updated the token introspection spec citation and details.
- Updated the OAuth threat model citation.
- Enhanced the security considerations section.
- Broaden from defining successful access as 200 OK to defining it as 2xx Success.
- Explain that the PAT implicitly gives the "subject" of a requested permission.
- Fix resource_set_registration_endpoint keyword mention. (It was missing the last work.)
From rev 07 to 08:
...
| UMA group Twitter handle. |
UMAWG Facebook | | UMA group Facebook page. |
Short link | | Short link to return to this page. |