FAPI is widely deployed, and as implementations mature, ongoing maintenance becomes as important as the initial implementation. One specific challenge is managing TLS cipher suites.

FAPI deliberately builds on widely deployed internet standards. That design choice has served the ecosystem well, but it also means that FAPI inherits the lifecycle dynamics of those underlying standards. Cipher suites are not static: researchers and standards bodies add, reclassify, and deprecate them over time.

This post explains how the FAPI Working Group is responding to this challenge by aligning with IANA registries. It covers upcoming changes to the FAPI specifications and conformance testing, and explains why the ecosystem should migrate to TLS 1.3.

How cipher suites evolve

The internet community maintains TLS cipher suites through a combination of mechanisms:

• IANA registries, which list cipher suites and their current status.
• Internet Engineering Task Force (IETF) RFCs (for example, RFC 8446), which define protocol behavior.
• Best Current Practices (BCPs) (for example, RFC 9325), which capture guidance at a point in time.

In IANA specifically, each cipher suite entry is associated with:

• A defining RFC.
• Its protocol version applicability (TLS 1.2, TLS 1.3).
• Its current status (recommended, deprecated, reserved).

This is by design. Standards bodies introduce new cipher suites when they are considered safe and useful, but they may deprecate existing ones when better alternatives are available or weaknesses are identified. Because of this model, any static allow-list inevitably becomes stale.

FAPI 2.0 and BCP 195

FAPI 2.0 Security Profile defers TLS security requirements to BCP 195, currently published as RFC 9325. This approach was appropriate at the time of writing. However, RFC 9325 itself explicitly limits its scope:

• For TLS 1.2, RFC 9325 Section 4.2 lists a narrow set of AES-GCM ciphers and discourages others:
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• For TLS 1.3, RFC 9325 Section 4.3 defers all cipher guidance to RFC 8446. RFC 8446 Section 9.1 defines the cipher list, which is:
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256

Importantly, RFC 8446 treats these algorithms as modern, secure constructions, independent of the TLS version.

ChaCha20-Poly1305 and the limits of static BCP enforcement

A recent case highlighted the challenges of static cipher enforcement.

A FAPI 2.0-ready implementation failed conformance testing because its servers advertised the TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 cipher for TLS 1.2. This happened because FAPI 2.0 conformance tests enforce a strict interpretation of BCP 195 (RFC 9325) for TLS 1.2 and allow only the narrow set of AES-GCM cipher suites listed above.

But ChaCha20-Poly1305 is a strong, modern cipher, and it is a mandatory-to-implement cipher suite in TLS 1.3, as defined in RFC 8446 Section 9.1. It is also designed for performance, particularly on platforms without AES hardware acceleration.

This showed that strictly interpreting the TLS 1.2 list in RFC 9325 contradicts the broader IETF intent. In practice, this creates a gap between conformance requirements and real-world cryptographic best practice.

Aligning FAPI with IANA registries

In response, the FAPI Working Group is formalizing a clearer and more sustainable approach to TLS cipher management.

FAPI will align its cipher expectations with the IANA TLS Cipher Suite registry, rather than freezing behavior to specific BCP revisions.

• Cipher suites added to the registry and marked as recommended will be acceptable for FAPI.
• This applies across TLS versions, consistent with their defining RFCs.
• Conformance testing will reflect this dynamic model.

We will update the FAPI 1.0 and FAPI 2.0 errata to reflect this.

New ciphers will be phased in automatically

When IANA registers new recommended cipher suites:

• FAPI conformance tests will accept them.
• No specification update will be required for basic eligibility.
• Ecosystems can adopt them without risking certification failure.

This ensures FAPI does not become an obstacle to cryptographic progress.

Deprecated ciphers will be phased out predictably

When cipher suites are deprecated or removed from recommended status, the transition will follow a predictable phased approach:

• Initial phase: conformance tests will emit warnings.
• Transition period: ecosystems have time to migrate.
• Final phase: deprecated ciphers will no longer pass conformance.

While exact timelines will be published, the intent is to provide clear, non-disruptive migration windows aligned with the existing 12-month expectations in FAPI and BCP guidance.

TLS 1.3 will become the default

Although the lifecycle guidance above applies to both TLS 1.2 and TLS 1.3, the strategic direction is clear: ecosystems should prioritize the adoption of TLS 1.3.

The IETF has signaled a definitive shift in protocol expectations, with TLS 1.3 becoming mandatory, and TLS 1.2 moving to optional support.

This position is reflected in the forthcoming update to RFC 9325, which formalizes the change. Here is an extract of draft-ietf-uta-require-tls13-12 (which is past AUTH48 stage, meaning it is imminent to become an RFC) section 5:

…this document now makes two changes to the recommendations in [RFC9325], Section 3.1.1:

• That section says that TLS 1.3 SHOULD be supported; this document mandates that TLS 1.3 MUST be supported for new TLS-using protocols.

• That section says that TLS 1.2 MUST be supported; this document says that TLS 1.2 MAY be supported as described above.

For FAPI ecosystems, this reinforces the direction of travel. TLS 1.3 should be enabled and preferred wherever possible, with TLS 1.2 retained only where operationally necessary.

Upcoming changes and timelines

We will share further details, including draft errata text and test suite changes, shortly. Planned updates are as follows:

• FAPI 1.0 Errata: replacing cipher suite and key length provisions with the following text:
  • shall require and use the key length permitted by [BCP 195];
  • shall not use algorithms deprecated in [IANA TLSP];
    
    
• FAPI 2.0 Errata: forthcoming:
• Servers shall only use cipher suites allowed and not deprecated in the "TLS Cipher Suites" registry in the "Transport Layer Security (TLS) Parameters" registry group.
• Clients should permit only the cipher suites recommended in the "TLS Cipher Suites" registry within the "Transport Layer Security (TLS) Parameters" registry group.

• FAPI 2.0 Conformance Test Updates: planned for the near term.
• FAPI 1.0 Conformance Test Updates: to follow.

These updates will incorporate the registry-aligned approach described above.

What FAPI ecosystem participants should do next

We encourage all FAPI ecosystem participants to take the following steps:

1. Review their current TLS configurations:

• Identify which cipher suites are advertised today.
• Map them against the IANA Registry and TLS 1.3 defaults.

2. Assess TLS 1.3 readiness:

• Ensure they enable TLS 1.3 and prefer it.
• Validate operational compatibility across clients and servers.

3. Plan for cipher lifecycle management:

• Expect future cipher additions and removals.
• Avoid hard-coding static allow-lists where possible.

Collaboration across ecosystems

FAPI is the leading global standard for securing open banking and open finance ecosystems, adopted by many nations to enable secure, interoperable data sharing. Maintaining interoperability and security at that scale requires coordination, transparency, and predictability.

The FAPI Working Group intends to ensure that strong, modern deployments are not penalized, while still maintaining a high security bar. By aligning FAPI more closely with IANA registries and accelerating the move to TLS 1.3, this approach best supports the long-term health of the ecosystem.

References

• RFC 9325: Recommendations for Secure Use of Transport Layer Security and Datagram Transport Layer Security (Section 4.2, Section 4.3)
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (Section 9.1)
• IANA Registry: Transport Layer Security (TLS) Parameters
• Draft-ietf-uta-require-tls13-12: New Protocols Using TLS Must Require TLS 1.3 
• FAPI 2.0 Security Profile: FAPI 2.0 Security Profile

About the OpenID Foundation

The OpenID Foundation (OIDF) is a global open standards body committed to helping people assert their identity wherever they choose. Founded in 2007, we are a community of technical experts leading the creation of open identity standards that are secure, interoperable, and privacy-preserving. The Foundation’s OpenID Connect standard is now used by billions of people across millions of applications. In the last five years, OAuth2 - the FAPI standard for interoperable, high security - has become the standard of choice for Open Banking and Open Data implementations, allowing people to access and share data across entities. Today, the OpenID Foundation’s standards are the connective tissue to enable people to assert their identity and access their data at scale, the scale of the internet, enabling “networks of networks” to interoperate globally. Individuals, companies, governments and non-profits are encouraged to join or participate. Find out more at openid.net.

To learn more about conformance testing and self-certification, please visit the OpenID Foundation’s FAQ section.