...
| 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. It may be more up to date than the version last contributed as an IETF I-D. |
OAuth RReg | 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. |
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 or anywhere else. |
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. |
...
Breaking and notable changes
Following is a catalog of notable changes.
...
- 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.)
- 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.
- Breaking changes:
- Section 1.3: TLS as defined and (mostly) required in OAuth (RFC 6749) is now a MUST in UMA for AS endpoints.
From rev 08 to 09:
- Breaking changes:
- (Technically breaking but not expected to have huge impact:) TLS/HTTPS is now mandatory for the AS to implement in its protection and authorization APIs.
- Other changes of note:
- It is no longer required for the client to redirect a human requesting party to the AS for the claims-gathering process.
- A new claims profiling framework (now in a separate spec) describes how to leverage one of several common patterns for claims-gathering: client redirects the requesting party to AS, client pushes claims to the AS.
- A new framework for API extensibility, and a matching series of extensibility profiles, appears in the core spec. It enables tighter coupling between the AS and RS, AS and client, and RS and client, respectively, but only in a controlled manner to foster greater interoperability in such circumstances.
- The SHOULD for the usage of the SAML bearer token profile for PAT issuance is now just a MAY.
- In Section 4.2, the example was corrected to remove a wayward "status" : "error" property.
- Clarified that no request message body is expected when the client uses the RPT endpoint at the AS.
- Added a success example in Section 3.4.2 showing how authorization data is added and the RPT is simultaneously refreshed, a new capability.