Page Comparison

...

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

From Core rev 10 to rev 11a-11e (not yet submitted to IETF; mistakenly published as revs 11, 12, 13 on the KI site!):

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

From Core rev 11 to rev 12:

• Changes of note:
  • Enabled explicit use of OAuth-based authentication protocols such as OpenID Connect for OAuth protection driving PAT and AAT issuance.

From Core rev 12 to rev 13:

• Breaking changes:
  • Scope identifiers for PAT and AAT now use https instead of http
  • Section 1.4: 1.4 ("12" to "13"):
    • Changed the claim_profiles_supported property in the configuration data to claim_token_profiles_supported
    Section 1.4:
    • Changed the user_endpoint property in the configuration data to authorization_endpoint, to match the final IETF RFC 6749 name in OAuth 2.0
    Section 1.4:
    • 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
  Changes We decided not to progress this specification in its current form, so we will let it expire and will not reference it from Core
  • Other changes of note:
    Identifiers
    • Section 3.1.1 and Section 3.1.2: Extraneous host_id removed from example of RS's response to client.
    • ("11" to "12") Enabled explicit use of OAuth-based authentication protocols such as OpenID Connect for OAuth protection driving PAT and AAT issuance.
    • ("12" to "13") Identifiers for spec-defined profiles now use https instead of http
    Migrated
    • ("12" to "13") Migrated the claim profiling spec's requesting party claims endpoint configuration data to the core spec, and made it optional to supply.
    Migrated
    • ("12" to "13") 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.

  Claim Profiles 00 to ...:

  • • • Section 3.1.1: Requirement for RS to return 403 to a tokenless client has been softened to a SHOULD.

  From RSR rev 03 to rev 04a-04b (not yet submitted to IETF; mistakenly published as rev 04 on the KI site!):

  • Breaking changes:
    • Removed the "status: xxx" property from all the AS responses in the RSR API.

  From RSR rev 04 to rev 05:

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

  ...

  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.