Change id token encryption documentation to allow for use in Hybrid flow and ACF

[anzbankau]

Description

Decision Proposal 282 (https://github.com/ConsumerDataStandardsAustralia/standards/issues/282) introduced changes to the DCR metadata fields "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc", which states: _Required if OIDC Hybrid Flow (response_type “code idtoken”) is registered. Must be ignored for Authorization Code Flow.

This aspect of the standards is problematic for us – as our implementation will take the id_token encryption metadata and apply this regardless of whether Hybrid or ACF is used.

We suspect other Data Holders will have similar issues as this is how the product we use is designed and is aligned to the underlying standards - https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata, which don’t distinguish on the flow in which the token is issued:

_id_token_encrypted_response_alg OPTIONAL. JWE alg algorithm [JWA] REQUIRED for encrypting the ID Token issued to this Client. If this is requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. The default, if omitted, is that no encryption is performed. id_token_encrypted_response_enc OPTIONAL. JWE enc algorithm [JWA] REQUIRED for encrypting the ID Token issued to this Client. If id_token_encrypted_response_alg is specified, the default for this value is A128CBC-HS256. When id_token_encrypted_response_enc is included, id_token_encrypted_responsealg MUST also be provided.

Area Affected

https://consumerdatastandardsaustralia.github.io/standards/#client-registration - Registration Request using JWT

Change Proposed

Change the description of "id_token_encrypted_response_alg" and "id_token_encrypted_responseenc” to remove the statement: “Required if OIDC Hybrid Flow (response_type “code idtoken”) is registered. Must be ignored for Authorization Code Flow.”

DSB Proposed Solution

The current DSB proposal for this issue is in this comment

[CDR-API-Stream]

As discussed in last week’s maintenance iteration call, dynamic client registration doesn’t support clients registering multiple software profiles with the same data holder. As such, oAuth clients are registered with the composite set of metadata provided in the registration request. This has caused problems for some data holders that cannot conditionally apply negotiated settings for different authorisation flows.

With ID token encryption, this has meant that some data holders will continue to encrypt ID tokens at the Token endpoint for the Authorization Code Flow. This is currently in conflict with the standards that state that ID token encryption must not be performed for Authorization Code Flow (in other words, it was originally intended for OIDC Hybrid Flow only).

To facilitate the transitionary period where OIDC Hybrid Flow is still supported, the following change is proposed:

Security Profile -> Tokens -> ID Token -> Authorization Code Flow requirements:

For response_type “code”, in accordance with [FAPI-1.0-Advanced], ID Tokens MUST be signed.

Until July 10th 2023,

• ID Tokens SHOULD NOT be encrypted when returned to a Data Recipient Software Product from the Token End Point.

From July 10th 2023,

• ID Token MUST NOT be encrypted when returned to a Data Recipient Software Product from the Token End Point.

Further considerations:

• ADRs currently support ID token encryption given the requirement for OIDC Hybrid Flow so it is not anticipated that this change will cause significant issues for ADRs given they must currently decrypt ID tokens.
• There is no forced retirement of OIDC Hybrid Flow after July 10th 2023. Data Holders may retire this authorisation flow after this date. If a Data Holder continues to support dual authorisation flows after this date then the requirement to not perform ID token encryption for Authorization Code Flow applies and the Data Holder must ensure ID token encryption is no longer performed for Authorization Code Flow.
• In the maintenance iteration it was discussed that this change be treated as urgent because of the proximity of the obligation dates. The DSB requests that participants seeking to have this change be treated as urgent provide their support to do so by commenting below.

[anzbankau]

Thanks for the update - we appreciate the progress made on this topic.

We would like to clarify however - will ADRs who have registered for both Hybrid and ACF have to update their registration with Data Holders on July 10th 2023? Since otherwise we still anticipate there would be a issue as the metadata would still drive some implementations to apply ID token encryption.

[anzbankau]

We also note that within the DCR OpenAPI Specification these fields are listed as required: https://consumerdatastandardsaustralia.github.io/standards/#dcr-apis

Will this be updated to reflect the recent changes?

[CDR-API-Stream]

Thanks for the update - we appreciate the progress made on this topic.

We would like to clarify however - will ADRs who have registered for both Hybrid and ACF have to update their registration with Data Holders on July 10th 2023? Since otherwise we still anticipate there would be a issue as the metadata would still drive some implementations to apply ID token encryption.

The expectation is that ADRs will transition to using ACF during the phase in period. The phase in period gives the ADRs time to fallback to Hybrid flow if they encounter issues. After 10th July it is then at the discretion of the DH when they retire the Hybrid flow so any DHs dropping support for Hybrid flow would no longer support it. ADRs would be expected to update their client registration accordingly to use only the ACF flow.

The proposal above is that post-July 10th if a DH supports Hybrid flow and ACF, they no longer apply ID token encryption on the ACF flow.

[CDR-API-Stream]

We also note that within the DCR OpenAPI Specification these fields are listed as required: https://consumerdatastandardsaustralia.github.io/standards/#dcr-apis

Will this be updated to reflect the recent changes?

Yes. This should be set to conditional based on the DH supporting Hybrid flow. If they do not then it is optional for the ADR but also noting that if the DH no longer advertised ID token encryption support on the ACF flow then the value presented by the ADR will be ignored.

[anzbankau]

As per the maintenance call today, we are supportive of this change being treated as urgent.

[CDR-API-Stream]

The Data Standard's Chair has approved this issue be treated as urgent.

[CDR-API-Stream]

There hasn't been any further feedback to this CR. As proposed, Data Holders supporting both OIDC Hybrid Flow and ACF can conditionally apply ID token encryption to the OIDC Hybrid Flow but not ACF after July 10.

An alternative is to retain the "SHOULD NOT" statement whilst Data Holders support both OIDC Hybrid Flow and ACF. In this situation it is not incumbent on the Data Holder to change their implementation post-July 10 where both flows are supported. As Data Holders retire the OIDC Hybrid Flow, ID token encryption is dropped because they only support ACF. Under this option ADRs may continue to obtain encrypted ID tokens where the Data Holder advertises ID token encryption is supported and the Data Holder supports both OIDC Hybrid Flow and ACF. If the ADR is only registered for ACF then no encryption would be applied. It is only where the ADR has a client registration for both flows.

[anzbankau]

ANZ is supportive of the alternative outlined above - allowing ID token encryption to be applied where both flows are still supported and registered with the Data Holder. We view this approach as beneficial from a transition perspective for ADRs and DHs.

[NationalAustraliaBank]

NAB is concerned that the proposal to force ID token encryption based on whether Hybrid flow or Authorization Code Flow is used is not aligned with OIDC standard and will break OIDC compliant implementations. This proposal is also not aligned with the desire to move away from CDR specific rules to full support of the industry standards. Similar concern about this proposal has already been raised by ANZ and we are supportive of their comments.

Whether the ID token is encrypted or not should only be determined based on the “id_token_encrypted_response_alg” and “id_token_encrypted_response_enc” client metadata attributes, and there is no real harm in encrypting the ID token even when Authorization Code Flow is used, given that the ID token encryption is currently supported by both ADRs and DHs.

If the intent of this proposal is to support both Hybrid Flow and Authorization Code Flow in the interim period and to ensure that ID token is encrypted when Hybrid Flow is used, then there is a much easier and standard compliant approach that can be taken, as follows: allow ID token encryption for Authorization Code Flow during the transition period and once we are ready to retire Hybrid Flow we can make the “id_token_encrypted_response_alg” and “id_token_encrypted_response_enc” client metadata optional and drop the support for Hybrid Flow. This will allow ADRs to decide whether they want to continue to receive ID tokens encrypted or not. Those ADRs who want to drop the support for ID token encryption can update their client metadata registration to remove “id_token_encrypted_response_alg” and “id_token_encrypted_response_enc” client metadata values.

[CDR-API-Stream]

Hi @NationalAustraliaBank, that aligns with the alternative option proposed. The id_token_encrypted_response_alg and id_token_encrypted_response_enc values are required for OIDC Hybrid Flow. This therefore forces ID token encryption for ACF if the ADR has a client registered for both OIDC Hybrid Flow and ACF. When the Data Holder drops support for OIDC Hybrid Flow, or the ADR updates their client registration to only use ACF, then the ADR can omit the ID token encryption claims in the client registration request.

Based on the proposal above, the DCR swagger would be updated to denote that the fields are conditional based on the response_type presented in the client registration request.

Currently:

REQUIRED Required if OIDC Hybrid Flow (response_type “code id_token”) is registered. Must be ignored for Authorization Code Flow.

Proposed:

CONDITIONAL Required if OIDC Hybrid Flow (response_type “code id_token”) is registered.

The upstream OpenID.Registration specification describes the default where no encryption algorithm claims are provided is to not perform ID token encryption.

id_token_encrypted_response_alg OPTIONAL. JWE alg algorithm [JWA] REQUIRED for encrypting the ID Token issued to this Client. If this is requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. The default, if omitted, is that no encryption is performed.

id_token_encrypted_response_enc OPTIONAL. JWE enc algorithm [JWA] REQUIRED for encrypting the ID Token issued to this Client. If id_token_encrypted_response_alg is specified, the default for this value is A128CBC-HS256. When id_token_encrypted_response_enc is included, id_token_encrypted_response_alg MUST also be provided.

Regarding obligation dates, this simplifies the phasing without the need for the transitionary SHOULD NOT and MUST NOT statements. In effect, the proposal would be a simplification of the "Security Profile -> Tokens -> ID Token -> Authorization Code Flow requirements" section such that statements regarding encryption are removed allowing clients to update to ACF and omit the id_token_encrypted_response_alg and id_token_encrypted_response_enc claims to denote that no ID token encryption should be performed.

Current:

For response_type “code”, in accordance with [FAPI-1.0-Advanced], ID Tokens MUST be signed and MUST NOT be encrypted when returned to a Data Recipient Software Product from the Token End Point.

Proposed:

For response_type “code”, in accordance with [FAPI-1.0-Advanced], ID Tokens MUST be signed when returned to a Data Recipient Software Product from the Token End Point.

[CDR-API-Stream]

This change request was incorporated through decision proposal 298