Retirement of OIDC Hybrid Flow

[CDR-API-Stream]

Description

As part of the FAPI 1.0 transition, the OpenID Connect Hybrid Flow authentication flow has been deprecated but not officially retired. Authorization Code Flow must be supported. Whilst Data Holder MAY continue to support OIDC Hybrid Flow, this was intended to provide a safe transition of the ecosystem on to Authorization Code Flow. This change proposes the retirement of OIDC Hybrid Flow with a planned future retirement data after which ONLY Authorization Code Flow shall be supported.

Intention and Value of Change

This change simplifies the ongoing support and maintainability of the security properties which Data Holders must support. This further aligns to the FAPI 2.0 Security Profile where OIDC Hybrid Flow is not supported. Specifically section 5.3.1.1 (2) states that Authorisation Servers:

shall reject requests using ... the hybrid flow as described in [OIDC]

Area Affected

Security Profile -> Authentication Flows

Change Proposed

The following changes are proposed:

• Remove:

  Specifically the OIDC Hybrid Flow outlined at section 3.3 of [OIDC].

• In relation to Authorization Code Flow, remove the obligation qualification

  From July 4th 2022,

• Simplify the Baseline Security Provisions to remove reference to OIDC Hybrid Flow

• Remove phased obligations and requirements in the Baseline Security Provisions:

~Data Holders MUST support the OIDC Hybrid Flow.~ ~From July 10th 2023 (FAPI 1.0 Migration Phase 4),~ ~Data Holders MAY retire support for the OIDC Hybrid Flow.~

• Remove the Security Profile -> Authentication Flows -> OIDC Hybrid Flow support

• Disallow the use of ID Token Encryption, or alternatively remove their support in Dynamic Client Registration (Registration Request using JWT). Applies to:

  • id_token_signed_response_alg
  • id_token_encrypted_response_alg
  • id_token_encrypted_response_enc

• Remove ID Token encryption supported parameters in the OIDD defined in the "Security Profile -> Security Endpoints":

  • id_token_encryption_alg_values_supported
  • id_token_encryption_enc_values_supported
  • id_token_signing_alg_values_supported

• Remove "Security Profile -> Client Registration -> ID Token Algorithm Selection Considerations"

• Remove support for response_type "code id_token" in DCR registration and authorisation requests.

• Remove the following OIDC Hybrid Flow requirements from "Security Profile -> Tokens"

  In addition to the mandatory claims specified in section 2 of the [OIDC] standard, required claims for ID Tokens as part of Hybrid Flow authentication MUST align to section 3.3 (Authentication using the Hybrid Flow) of the [OIDC] standards and section 5.2.2 and section 8.4.3 of the [FAPI-1.0-Advanced] profile.

  ...

  OIDC Hybrid Flow requirements

  In accordance with [FAPI-1.0-Advanced], ID Tokens MUST be signed and encrypted when returned to a Data Recipient Software Product from both the Authorisation End Point and Token End Point.

  Hashing value for state and authorisation code

  The following requirements apply to the OIDC Hybrid Flow:

  • The c_hash value MUST be generated according to section 3.3.2.11 of [OIDC].
  • The s_hash value MUST be generated according to section 5.1.1 of [FAPI-1.0-Advanced].

• Include the following requirement in the baseline ID token requirements:

  The ID Token returned from the ~Authorisation~ Token End Point MUST NOT contain any Personal Information (PI) claims.

• Remove and/or update associated non-normative examples

• Set a retirement date be agreed, for example Y25 # 2: 2025-05-12

[markskript]

Skript can confirm that we have been able to successfully re-DCR with every active data holder using the ACF flow, so we support the decommissioning of the Hybrid flow.

[CDR-API-Stream]

This change has been staged here: https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/release/1.33.0...maintenance/666

The intended end-state is available for review here: https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/release/1.33.0...maintenance/666-end-state

https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/maintenance/666...maintenance/666-end-state

[CDR-API-Stream]

This issue was discussed in the MI 21 meeting. It was noted that the proposed obligation date would give Data Holders slightly less than six months to implement the change. The change was still supported with the current proposed obligation date. Feedback to date has indicated that few Data Holders still support OIDC Hybrid Flow.