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.

SpecificationURLDescription

UMA Core V1.0.1 Recommendation

https://docs.kantarainitiative.org/uma/

...

...

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://

...

...

...

...

...

...

core-v1_0.html
Final V1.0 version of the UMA Core Recommendation (obsoleted by V1.0.1).

OAuth RSR V1 Recommendation

https://

...

...

...

uma/rec-oauth-resource-reg.html
Final V1.0 version of the OAuth Resource Set Registration Recommendation (obsoleted by V1.0.1).

UMA Core I-D rev 13

https://

...

...

...

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://

...

...

Following is a catalog of breaking changes made since the 18 Jan 2012 rev.

  • The resolution to issue #19 involved a breaking change in the 2 Feb 2012 rev. The XRD-formatted AM metadata residing at /.well-known/host-meta is now JSON-formatted metadata residing at /.well-known/uma-configuration.
  • The requester access token has been split into two tokens, and all of the tokens have been renamed. The host access token is now the PAT. The requester access token used at the AM's API is now the AAT, and consists of vanilla OAuth. The requester access token used at the host is now the RPT. The AAT does not use the client_credentials flow, as previously required, but rather typically uses the authorization_code flow.
  • The token and user authorization endpoints for the different APIs at the AM have been joined together, and are now distinguished through the "protection" scope (for the protection API) and the "authorization" scope (for the authorization API).
  • The token status description format and JSON media type, and the RPT/permission delivery response, have been updated to reflect the RPT naming.
  • The configuration data format has changed to reflect all the changes above.
  • The Phase 2/3 flow has changed and been simplified to match the requirements of the new AAT and RPT.
  • The requester now asks for permission in a back-channel interaction, and the AM now produces a need_claims error that instructs the requester to use a redirect-based claims-gathering flow (renamed from "authorization flow").

Other recent changes of note that do not affect implementations:

...

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
Latest IETF I-D 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
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/KantaraInitiative/wg-uma
GitHub repository for the spec.

UMA issues

https://github.com/KantaraInitiative/wg-uma/issues
Direct link to the issues list in GitHub.

UMAWG Twitter

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