Decision Proposal 282 - Urgent FAPI 1.0 Phase 3 migration changes

[CDR-API-Stream]

Decision Record

The Data Standards Chair approved this decision on 16th December 2022. The decision record is attached: Decision 282 - JARM and Authorization Code Flow For FAPI 1.0 Phase 3 Obligations - final.pdf

---

09/12/2022: This issue is a placeholder for the decision in relation to two urgent change requests that were consulted on in Maintenance Iteration 13.

The details of the change proposals can be found here:

• #479: Clarification on Minimum Algorithm Required for JARM
• #547: Update SSA and Client Registration standards for JARM and Authorization Code Flow

[tinagroark]

Clarification for decision write-up please - Issue 547 point 13 seems to indicate id_token encryption is not allowed for ACF.

My understanding is that DCR client metadata does not allow the ADR to differentiate id_token encryption for each flow, therefore the standard must support id_token encryption for ACF where the ADR is registered for both Hybrid Flow and ACF.

Can you clarify please if id_token encryption is OPTIONAL or NOT ALLOWED for ADRs who register solely for ACF?

[anzbankau]

We request the below minor changes in order to allow for the current Data Holder implementation timeframes:

JARM Response Signing The decision states the minimum set of signing algorithms is both PS256 and ES256.

This should be a ‘And/Or’ for Data Holders.

ID Token Encryption Update "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc" from conditional to required.

This is in order to align to existing implementations and avoid rework for data holders and data recipients who have implemented the existing model. If there is a need to change these to conditional then we request a future dated obligation (beyond the April 2023 timeline).

[CDR-API-Stream]

The Data Standards Chair has now approved this decision. The decision record can be found in the original post.

[CDR-API-Stream]

Hi @tinagroark

Clarification for decision write-up please - Issue 547 point 13 seems to indicate id_token encryption is not allowed for ACF.

My understanding is that DCR client metadata does not allow the ADR to differentiate id_token encryption for each flow, therefore the standard must support id_token encryption for ACF where the ADR is registered for both Hybrid Flow and ACF.

Can you clarify please if id_token encryption is OPTIONAL or NOT ALLOWED for ADRs who register solely for ACF?

ID Token encryption only applies to the OIDC Hybrid Flow. If the ADR is registered for both Hybrid Flow and Authorization Code Flow, the ID Token encryption algorithms shall apply to Hybrid Flow but be ignored for ACF.

[CDR-API-Stream]

Hi @anzbankau,

JARM Response Signing The decision states the minimum set of signing algorithms is both PS256 and ES256.

This should be a ‘And/Or’ for Data Holders.

The final decision has been changed to require Data holders to support only one of the chosen algorithms ('OR').

ID Token Encryption Update "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc" from conditional to required.

This is in order to align to existing implementations and avoid rework for data holders and data recipients who have implemented the existing model. If there is a need to change these to conditional then we request a future dated obligation (beyond the April 2023 timeline).

The final decision has included a qualifying statement to require these values for Hybrid Flow. They should be ignored by the Data Holder for Authorization Code Flow.

[anzbankau]

Thanks for the updates. However, to note – our intention on the "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc" being required also implied that these would be used for both Hybrid Flow and ACF.

So, our ask is that these fields remain required, and that token encryption is still allowable for both Hybrid flow and ACF.

Our implementation (and possibly others) will take the values from these fields and apply it regardless of whether Hybrid flow or ACF is used.

[AG-IAM]

ID Token encryption only applies to the OIDC Hybrid Flow. If the ADR is registered for both Hybrid Flow and Authorization Code Flow, the ID Token encryption algorithms shall apply to Hybrid Flow but be ignored for ACF.

If the ADR is registered for both Hybrid Flow and ACF, the ID token encryption attributes become mandatory in the DCR JWT sent to DH for registration. This will encrypt the id_token in both the flow as the id_token encryption values will be added under the registered client in DH. Is there a necessity for ADR to register with both Hybrid and ACF. Can the ADR be restricted to register with only one type for flow?

[anzbankau]

Agree that alternatively to our suggestion above, if the ADR was restricted to be registered for only one type of flow the issue would be resolved for us.

[ikawalec]

Hi,

I have few questions regarding the following part:

To leverage the Authorization Code Flow, FAPI requires the use of JARM in conjunction with
response_type “code” (refer to sections 5.2.2.2 and 5.2.3.2). The Data Standards, in accordance with
the FAPI 1.0 profile, require that response_type “code” be used in conjunction with response_mode
“jwt” to activate the JARM requirements

1. Is jwt only allowed value for response_mode when response_type "code" is used? The spec: https://openid.net/specs/oauth-v2-jarm-03.html#name-response-encoding defines also form_post.jwt, query.jwt and fragment.jwt. Additionally, what are allowed response_modes for the hybrid flow?

2. Shouldn't response_mode be added as a parameter to the DCR request similarly to JARM signing alg and encryption settings OR is the assumption that only one "jwt" response_mode can be used and this field is intentionally omitted?

3. If client is registered using both "code" and "code id_token" response types, does JARM applies only to the "code" and it's a must that it should not be used for hybrid?

[WestpacOpenBanking]

Westpac's Implementation approach

The purpose of this post is to allow the community to review Westpac’s implementation view for FAPI 1.0 Ph. 3 and provide their alignment to the solution. We are not recommending any changes or feedback to the standards by this post.

In line with the recently revised v1.21 CDS for FAPI 1.0, Westpac will be upgrading its DH implementation to enable support for both Authorisation Code flow (ACF) from 14-Apr-23 & continue supporting OIDC Hybrid flow (OHF) till 10-Jul-23.

Westpac DH implementation adheres to DP 282 ( Decision 282 - JARM and Authorization Code Flow For FAPI 1.0 Phase 3 Obligations - final.pdf ), FAPI 1 JARM standards ( openid / fapi / oauth-v2-jarm.md — Bitbucket ) & changes proposed as per CDR maintenance issue #576 ( Change id token encryption documentation to allow for use in Hybrid flow and ACF · Issue #576 · ConsumerDataStandardsAustralia/standards-maintenance · GitHub ) to facilitate the transitionary period where OIDC Hybrid Flow is still supported.

To leverage the Authorization Code Flow, FAPI requires the use of JARM in conjunction with response_type “code” (refer to sections 5.2.2.2 and 5.2.3.2). The Data Standards, in accordance with the FAPI 1.0 profile, require that response_type “code” be used in conjunction with response_mode “jwt” to activate the JARM requirements.

In this document, references to JARM should be taken in the context that the client is registered (or seeking to register) for the Authorization Code Flow with response_type “code” and response_mode “jwt”.

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.

Authorisation Code flow ( ACF )

• From 14-Apr-23 onwards, Westpac expects ADR clients when requesting ACF will need to send “response_type”:“code” & an additional JWT claim “response_mode” with the values equal to “jwt” or “query.jwt” or “fragment.jwt” as part of the PAR request object JWT. Westpac DH Authorisation server will return the auth code in JARM format for such valid ACF requests.

• Westpac DH Authorisation server will reject ACF requests if the “response_mode” is not supplied or has any other values other than the acceptable values ( “jwt” or “query.jwt” or “fragment.jwt” ) as required for supporting ACF with JARM.

• Westpac DH Authorisation server will not ignore "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc" claims for ACF. Westpac DH Authorisation server will provide signed & encrypted Id Tokens as part of JARM response ONLY IF the ADR client has registered with DCR metadata that contains valid values for "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc" fields as part of dynamic client registration request else it will not encrypt Id Tokens. This aligns with the change proposed as part of CDR maintenance issue #576.

• The above implementation ensures ACF is used in conjunction with PAR, PKCE & JARM.

OIDC Hybrid flow ( OHF )

• ADR clients who want to use OHF & need auth code in http redirect response same as per FAPI 1 phase 2 mandate of 16-Sep-22 can continue sending PAR request object JWT in existing format with “response_type”:“code id_token”. JWT claim “response_mode” is not mandatory to be supplied by ADR clients for OHF but if supplied can have values equal to “query” or “fragment”. Westpac DH implementation will return auth code in the http redirect response ( but not in JARM format ) for such valid OHF requests in line with 16-Sep-22 guidelines.

• ADR clients who want to use OHF & need auth code in JARM format can send PAR request object with “response_type”:“code id_token” & additional JWT claim “response_mode” with values “jwt” or “query.jwt” or “fragment.jwt”. JWT claim “response_mode” is not mandatory to be supplied by ADR clients for OHF but if auth code in JARM format is expected for OHF then ADR clients must supply the valid values viz. “jwt” or “query.jwt” or “fragment.jwt”. In this case Westpac DH implementation will return auth code in the JARM response format for such valid OHF requests.