Decision Proposal 15 - JWKS Management

[CDR-Register-Stream]

This thread has been created to capture, document and obtain feedback on JWKS management within the CDR Register and CDR Participants

The decision proposal is attached below. Decision Proposal 15 - JWKS Management.pdf

All feedback is welcome.

[JamesMBligh]

Great doc.

I see problems for option 2 in that for a participant to have all of the info required for participation they have to go to multiple sources and there is no “force refresh” mechanism for JWKS in this model. Also, the proposal appears very holder specific. Would a recipient also create a JWKS end point and all holders will have to call the recipient end points to authenticate a recipient?

There is a potential variant on option 2, however, where the Register provides an option to poupulate JWKS metadata from an end point on request to avoid the fat finger scenario.

[perlboy]

I feel the fundamental reason that multiple issues are now coming about regarding admission control is the decision to centralise key management at the register, which is directly attached to the decision to not mandate Dynamic Discovery & Dynamic Client/Server Registration highlighted in May in ConsumerDataStandardsAustralia/standards#66 . I'll add here that DP66 final decision stated "The mechanism for client registration has been excluded from this decision as this choice is derived from the design of the CDR Registry, which has not yet been published. The areas that may be impacted by the design of the CDR Registry have been identified via nonnormative callouts." I'm not aware of a formal decision proposal that confirmed Static Registration was proceeding?

For the purposes of providing endorsement of participants centralised key management is completely unnecessary. In addition, centralised key management is fraught with significant risks with respect to key integrity during distribution and introduces a significant increase in the attack surface of all participants.

Put another way, there are clearly defined protocols (notably OpenID Connect Federation) that are already being adopted which specifically solve the "out of band verification" requirement that the ACCC has with respect to accreditation. OIDC Federation DOES NOT distribute JWKS intended for point-to-point comms (ie. DH <-> DR), instead relying on OIDC Discovery & Registration protocols combined with cryptographic assertions (ie. endorsement) on a per participant basis. This allows the ACCC to perform admission control (with an explicit expiration/refresh of quite possibly <10 minutes) while adopting best practice with respect to decreasing the participant-to-participant attack surface to only active relationships.

Since JWKS is the discussion point I refer to the original JSON Web Key (JWK) spec where in Section 9.1 the following is stated:

One should place no more trust in the data cryptographically secured by a key than in the method by which it was obtained and in the trustworthiness of the entity asserting an association with the key. Any data associated with a key that is obtained in an untrusted manner should be treated with skepticism.

While I am not implying that the ACCC is an untrustworthy entity it must be noted that it is bad practice to suggest that the internet accessible and cloud hosted Register proposes to distribute, to all participants, in ENTIRETY, public keys which MUST be trusted by ALL Participants with ZERO data integrity (the "method") or cryptographic trust chains in place.

Such blind trust in key distribution is not only bad practice but places a HEAVY burden on the underlying MTLS layer to ensure the security of the ecosystem. Even if these are sufficient (which in my opinion, they are not), the underlying MTLS layer does not provide data integrity provisions to the keys themselves. In essence the ACCC is a trusted entity but none of this applies in the online space until the ACCC looks to cryptographically assert such trust (which is precisely what OIDC Federation was designed for).

Specifically with regards to this DP, I support Option 2 primarily because I support the adoption of the entire OIDC suite as it is both battle tested and internationally adopted. With that said, I believe a third option should be considered regarding the adoption of OIDC Federation and therefore the cascading requirement to mandate OIDC Dynamic Discovery and Registration.

As it stands there are now over 15 certified implementations of Dynamic OP (ie. Servers supporting discovery+registration) along with multiple implementations in various languages of Dynamic RP (ie. Clients supporting discovery+registration). What is being proposed currently will result in untested implementations by all participants which could (or quite possibly, will) have unintended consequences that could fundamentally impact the trust of the entire ecosystem.

[chengchengmu]

Option 2 has the advantages of decentralized JWKS management:

• each participants manage its own JWKS and decide when to rotate.
• no bottleneck, load is spread In case of key rotation the propagation time is minimal because totally controlled by the participant. Whereas in option 1, rotation of keys will be impacted by a longer propagation time. In option 1, on top of maintaining the JWKS information in an extra location (CDR + participant), it introduces a single point of failure.

To ensure a better availability of the openbanking system, option 2 is much preferred.

[JamesMBligh]

Option 2 has the advantages of decentralized JWKS management:

• each participants manage its own JWKS and decide when to rotate.
• no bottleneck, load is spread In case of key rotation the propagation time is minimal because totally controlled by the participant. Whereas in option 1, rotation of keys will be impacted by a longer propagation time. In option 1, on top of maintaining the JWKS information in an extra location (CDR + participant), it introduces a single point of failure.

To ensure a better availability of the openbanking system, option 2 is much preferred.

In a normal situation I would agree but, in this context, the arguments about single point of failure and centralization don’t hold as the recipient still has to go to the Register for meta data anyway. Option 1 therefore adds complexity to an existing design rather than removing complexity.

I also disagree that propagation time would be reduced. The forced refresh mechanism means that propagation can effectively be real time if needed. Without that mechanism propagation (especially revocation of breach keys) would be dependent on how often the many recipients choose to call the JWKS end point for each holder.

[WestpacOpenBanking]

Westpac supports Option 2 because it is a standards based approach. We believe where possible, the option of existing open standards will allow participants and the register itself to be implemented in less time with lower design, build, testing, management and support costs over time by leveraging commercially available software which is known to be secure through certification, testing and production experience. As would normally be the case in other applications implementing OIDC discovery, Data Recipients would discover the location of the JWKS endpoint through the OpenId Provider Configuration Endpoint as is included in the current information security profile.

Option 1 has the following risks and issues:

• Transmission of keys via manual or dev ops processes will introduce security risks if not performed adequately or the process(es) are not designed adequately.
• Centralised key management likely increases the number of consumers affected in the event of a compromise and creates a single point of failure for the ecosystem.
• Propagation of keys and key rotation is necessarily tied to the 6 hour cache update schedule even though the design considerations may differ depending on the security infrastructure of the participant.
• Compromised key removal is dependent on the availability of the register.
• There is no signing mechanism to ensure key integrity – this makes the process liable to interception.
• Data Holders are not able to ensure that keys are securely maintained.
• Option 1 is more complex than option 2 for most, if not all, participants when taking into consideration the compensating controls required to address the above issues.

[JamesMBligh]

Another option is to adopt option 2 but extend the force refresh API to allow for active notification that any cached JWKS data should be flushed and obtained again.

This would allow for JWKS to be entirely standards based and alleviate the need for the Register to host any of this data. It would also, however, allow the ACCC to handle a critical event like a key breach notification across the CDR ecosystem.

[commbankoss]

Commonwealth Bank have observed that the ACCC desire to use JWKs as a control mechanism. If this is the intention then the ACCC will need to host JWKs endpoints for the use of regime participants. The ACCC will need to provide the UI and APIs for participants to manage keys.

[NationalAustraliaBank]

NAB strongly insists on Option 2 described in the decision proposal.

This option aligns to widely adopted and open standards approach for participants to publish provider configuration and enables participants to control & secure their JWKS.

Both Option 1 & 2 would utilising caching as one mechanism to mitigate against JWKS endpoint availability, however, with Option 2 the impact when the JWKS cache expires is now limited to interactions with that unavailable participant, rather than all participants in the ecosystem (Option 1).

[CDR-Register-Stream]

All, this issue has now been resolved and the proposed option 2 will be adopted. Thanks to all the contributors helping to bring this decision to a close.

Decision - Decision Proposal 15 - JWKS Management.pdf