Versions Compared

Old Version 6

changes.mady.by.user Eve Maler

Saved on

compared with

New Version 7

changes.mady.by.user Eve Maler

Saved on

Key

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

UMA Release Notes

Abstract 

...

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

...

Anchor

...

to-v101
to-v101
From V1.0 to V1.0.1 (draft)

The UMA V1.0 specifications (Core, RSR) were approved in March 2015. The UMA V1.0.1 specifications (Core, RSR) are currently (Sep 2015) in draft form; the Work Group's goal is to see their finalization by the end of 2015. The following release notes are therefore also in draft form. They are catalogued by their impact on software entities, with references to relevant GitHub issues. Where possible, specific section numbers are referenced; they link to discussions and related commits.

...

Previously, little was said about privacy implications of requesting party claims being transmitted to the AS. Now this section has been greatly expanded. (211) (Core Sec 8.2)

Changes Affecting Resource Server (+Client) Implementations

Following are specification changes in V1.0.1 that affect resource servers, and possibly clients that interact with them as well (denoted with (+Client) in the title).

...

Previously, the security considerations around accepting policy-setting context information from an incompletely trusted AS were not covered. Now they cover the user_access_policy_uri property, which is the only policy-setting context information passed from AS to RS. (185) (RSR Sec 4)

Specification Reorganizations

The specifications, particularly Core Sec 3, were reorganized in the fashion of OpenID Connect, with the goal of giving a subsection to every request and response message. Other notable changes include:

...

3. Error Messages (go)
4. Security Considerations
5. Privacy Considerations
6. IANA Considerations
7. Example of Registering Resource Sets
8. Acknowledgments
9. References
9.1. Normative References
9.2. Informative References
3. Error Messages (go)
4. Security Considerations
5. Privacy Considerations
6. IANA Considerations
7. Example of Registering Resource Sets
8. Acknowledgments
9. References
9.1 Normative References
9.2 Informative References

 

...

Anchor
pre-v1.0
pre-v1.0
Pre-V1.0 Changes

Following is a catalog of notable changes to the specifications in the pre-V1.0 timeframe.

Core Changes

Internet-Draft Rev 11 to Rev 12

From I-D rev 11 to rev 12:

  • Notable changes:
    • Enhanced the Security Considerations section.

Internet-Draft Rev 10 to Rev 11

From I-D rev 10 to rev 11:

  • Breaking changes:
    • Section 3.4: not_authorized_permission error code: Changed to not_authorized.
    • RPT handling: Changed extensively to remove the RPT issuance endpoint and enable the authorization data request endpoint to do all RPT issuance duties. Permission ticket issuance is now handled on an "eager" basis, when a client either without an RPT or with an invalid or insufficient-authorization-data RPT approaches the RS seeking access. This affects several sections:
      • Section 1.4: configuration data
      • Section 3: introduction
      • Section 3.1.1 and 3.1.2: client approaching RS
      • Section 3.2: RS registering permission
      • Section 3.4: RPT issuance and authorization data addition
      • Section 5.2: Extensibility profile implications
    • Section 1.4:
      • Changed the claim_profiles_supported property in the configuration data to claim_token_profiles_supported
      • Changed the user_endpoint property in the configuration data to authorization_endpoint, to match the final IETF RFC 6749 name in OAuth 2.0
      • Changed the authorization_request_endpoint property in the configuration data to rpt_endpoint, to distinguish it more fully from the OAuth endpoint and to shorten it
      • (Also affects Section 5) Changed how uma_profiles_supported works, so that the API extensibility profiles don't have reserved keywords but rather use the regular URI mechanism for indicating profiles
    • Section 3.3.2:
      • Names of several properties in the permissions structure for the RPT "Bearer" token introspection response have changed to align them with JWT names: expires_at to exp, issued_by to iat
      • The JWT "scope" property at the top level is now disallowed in favor of "scopes" at the permissions level.
    • PAT and AAT OAuth scopes:
      • Renamed from URIs to simple strings: "uma_protection" and "uma_authorization"; the JSON scope description documents provided to enable the old URIs to resolve no longer have any relation to the UMA Core spec
  • Other changes of note:
    • Section 3.1.1 and Section 3.1.2: Extraneous host_id removed from example of RS's response to client.
    • Enabled explicit use of OAuth-based authentication protocols such as OpenID Connect for OAuth protection driving PAT and AAT issuance.
    • Identifiers for spec-defined profiles now use https instead of http
    • Migrated the claim profiling spec's requesting party claims endpoint configuration data to the core spec, and made it optional to supply.
    • Migrated the claim profiling spec's "need_claims" extensions to the core spec, broadened it to "need_info", and gave it "error_details" hints in the core spec.
    • Section 3.1.1: Requirement for RS to return 403 to a tokenless client has been softened to a SHOULD.
    • Section 3.3.2: The token introspection response has been aligned with the latest token introspection spec. nbf has been added at the permissions level, exp is now optional, and all permissions-level properties that duplicate JWT-level claims in intent now get overridden by any JWT-level claims present in the response. Finally, the "permissions" JWT claim has been registered with IANA.
    • Extensive new redirect-pattern claims gathering support added
    • Extensive new security and privacy considerations added
    • Section 1.4:
      • issuer property: Now required to match the actual published location of the config data.
      • Dynamic client configuration: When OIDC dynamic client configuration is used, this is now more intelligently handled through a reserved keyword "openid" that indicates that the OIDC configuration data should be consulted for the relevant endpoint.
      • pat_grant_types_supported and aat_grant_types_supported: Broadened to allow them to be strings even when not based on the OAuth grant type strings, similarly to token profiles.
      • issuer property: Now required to match the actual published location of the config data.
      • Dynamic client configuration: When OIDC dynamic client configuration is used, this is now more intelligently handled through a reserved keyword "openid" that indicates that the OIDC configuration data should be consulted for the relevant endpoint.
      • pat_grant_types_supported and aat_grant_types_supported: Broadened to allow them to be strings even when not based on the OAuth grant type strings, similarly to token profiles.

Internet-Draft Rev 08 to Rev 09

 From I-D 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.

Internet-Draft Rev 07 to Rev 08

From I-D rev 07 to 08:

  • 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 I-D 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.)

Internet-Draft Rev 05 to Rev 06

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.

RSR changes

Internet-Draft Rev 04 to Rev 05

From I-D rev 04 to rev 05:

  • 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.

Internet-Draft Rev 03 to Rev 04

From I-D rev 03 to rev 04:

  • Breaking changes:
    • Removed the "status: xxx" property from all the AS responses in the RSR API.
  • Other changes of note:
    • ("04" to "05") Added a new optional resource_uri parameter to the resource set description, to support resource discovery at an authorization server.
    • Scopes bound to resource set descriptions can now be strings rather than being required to be URIs that resolve to scope description documents.
    • The _rev property has been removed from the resource set registration API. It can be added back as an extension for those who want it.

Claim Profiles changes

Claim Profiles Rev 00

Claim Profiles 00:

  • We decided not to progress this specification in its current form, so we will let it expire and will not reference it from Core.

 

...