search

ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41 stars 9 forks source link

PKCE + PAR support for 16th September 2022 #533

Closed CDR-API-Stream closed 1 year ago

CDR-API-Stream commented 1 year ago

Description

The standards phase in the adoption of FAPI 1.0 final across three phases. FAPI 1.0 introduces PKCE requirements for clients calling the Pushed Authorization Request (PAR) endpoint. From September 16th, 2022, DHs are required to enforce validation for PKCE. As such, ADR clients are to be supporting PKCE no later than September 16th 2022.

There has been 9 months for ADRs to phase in their PKCE support and ideally they are supporting PKCE well ahead of September 16th, 2022.

That said, for July 4th, 2022 obligations, DHs were permitted to uplift their systems to support FAPI 1.0 with PAR RFC9126 and therefore, PKCE. Because ADRs only have an optional requirement to support PKCE on July 4th, there is a transition period whereby DHs going live early with their FAPI 1.0 phase in may encounter ADRs that are not supporting PKCE.

In addition, in the Authentication Flows section of the standards there is an incorrect requirement statement duplication of a July 4th 2022 for Data Holders:

Data Holders MAY support [PKCE] ([RFC7636]).

The intention is that PKCE support aligns to the FAPI 1.0 profile which requires the use of PKCE in conjunction with PAR RFC9126.

This change request proposes three options for ensuring Data Holders go live

Area Affected

Authorisation flow

Change Proposed

Option 1: Data Holders cutover PKCE support on September 16th 2022

This is the current status quo. It is important that ADRs are aware they have a technical requirement to implement PKCE no later than September 16th, 2022. If they do not, authorisation requests will fail. This has been a clearly articulated requirement for ADRs during FAPI 1.0 migration.

Data Holders would enforce validation at Phase 2 and ADRs would need to ensure they are implementing PKCE prior to September 16th 2022.

Data Holders must currently ignore PKCE claims if they do not support PKCE, thus it is safe for ADRs to do so.

Option 2: Extend phase in of PKCE

PKCE claims continue to be ignored by Data Holders for an extended period of time. FAPI 1.0 Advanced + PAR RFC9126 are required on September 16th 2022 but PKCE is not. This would delay Data Holder implementation of PKCE for the OIDC Hybrid Flow. A future phase in date for PKCE validation for OIDC Hybrid Flow would be agreed upon. This may align to Phase 3 FAPI 1.0 migration obligations.

This is likely to add additional implementation scope for Data Holders and delay industry alignment to FAPI 1.0.

This option would impact Data Holders that are ready for implementation of FAPI 1.0 Phase 2 obligations:

Data Holders that do not support [PKCE] MUST ignore PKCE claims and MUST NOT reject clients sending PKCE claims.

Option 3: Delayed PKCE Validation Obligation

Data Holders provide PKCE responses if requested by Data Recipients for the Hybrid Flow but do not reject authorisation requests when PKCE claims are not presented.

A future phase in date for PKCE validation for OIDC Hybrid Flow would be agreed upon. This may align to Phase 3 FAPI 1.0 migration obligations.

DSB Proposed Solution

The current DSB proposal for this issue is Option 1 as listed above. The only feedback received from Data Recipients was in favour of Option 1 and the consensus of Data Holders was in support of Option 1.

anzbankau commented 1 year ago

ANZ supports Option 3 – this was the position we understood from the current version of the standards and have already implemented accordingly.   We could move to Option 1 with an appropriate future dated obligation. We note that from the current standards we did not understand this aspect to be required – “PKCE would be enforced for OIDC Hybrid Flow”.   We do not support Option 2 - Option 2 is problematic because we cannot configure our solution to ignore PKCE claims for response type = code id_token, but honour them for response_type = code. If PKCE claims are supplied on a request, then we must honour them regardless of response_type. This means we will return errors if the claims in the request object do not meet PKCE requirements (e.g. missing one of the two required claims, method supplied not ‘S256’, challenge not encoded correctly, etc.) and if an incorrect code_verifier is supplied on the token request.

ShaneDoolanAdatree commented 1 year ago

Adatree supports Option 1 but, at this late stage we won't oppose any option that makes September 16th easier to achieve for Data Holders for the sake of ecosystem stability.

NationalAustraliaBank commented 1 year ago

NAB also supports option 1

commbankoss commented 1 year ago

As a Data Holder, CBA is on track to deliver solution Option 1 by 16th September 2022 and would be able to support Option 3 by this date if required.

WestpacOpenBanking commented 1 year ago

Westpac supports Option 1. We do not support Option 2 or 3 because both introduce late changes and put our implementation to the remaining FAPI Phase 2 requirements at risk that is due on 16-Sept-22.

perlboy commented 1 year ago

As indicated in various feedback we are aware that there are multiple Data Recipients which have not enabled PKCE at this stage. While we are in support of FAPI 1.0 alignment there is an ecosystem stability component here which makes me think that Option 3 is appropriate, if only for a month or two, until Data Recipients uplift.

PKCE introduces integrity protection to Data Recipients of the code component returned. If a Data Recipient hasn't enabled it that is a risk they have accepted. I don't see how delaying the enforcement has a material impact on the security of the ecosystem in the short term (ie. it's been "good enough" for the past few years so what's a few extra weeks).

CDR-API-Stream commented 1 year ago

Based on the feedback received, the DSB proposed solution is Option 1 as listed in the original issue proposals. This issue has been updated to proposal made.