how do we handle FAPI1 private_key_jwt aud changes in certification tools

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2026-06-10

As discussed in https://bitbucket.org/openid/fapi/issues/726/private-key-jwt-aud-restrictions the IETF updates will result in a change to the requirements on aud values.

The working group needs to decide what approach it takes, as this could require the ecosystems that use our FAPI1 tests to do a migration, even if they're not vulnerable.

---

Bitbucket status: new

Bitbucket origin: issue 860

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2026-06-10

One possible way forward is that we run two sets of certification tests for now, one set that tests uses the current private_key_jwt aud values, and another set that test using the new values. This obviously isn't ideal from an interoperability standpoint.

We would probably need to set some kind of deprecation timeline for the older version. I'd suggest that the old behaviour should probably go away no later than the point that a post-quantum transition happens, but I'm not sure if there's an argument for it to happen sooner.

Feedback from the working group would be welcome as this is ultimately a decision for the FAPI working group to make.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2026-06-17

On 2026-06-10 call, Peter Stanley (OBL) wanted to flag the topic for future agenda planning rather than resolve it immediately.

• Context: there is an known issue concerning private_key_jwt and audience (aud) restrictions — referenced issues #726 and #860 — and a related IETF document, draft-ietf-oauth-rfc7523bis, which Joseph Heenan reported is now in the RFC Editor queue (i.e., has passed through OAuth working group review and IESG/Area Director approval, and is awaiting final publication — timeline estimated at anywhere from a few weeks to a few months).
• Peter recalled that Joseph had previously indicated the working group (rather than the certification/testing team) should have final say on how this is handled in conformance testing, and asked Joseph to confirm.
• Joseph confirmed this is correct, and noted that no issue has yet been opened specifically to track the testing-approach decision (how do we handle FAPI1 private_key_jwt aud changes in certification tools #848 is related but may not fully capture the conformance-testing angle). He committed to opening a new issue and recording at least one candidate option in it.
• Joseph outlined the core tension for certification: the test suite needs to know which aud value a given server actually supports in order to send a correct test request. Practical options discussed:
  • Continue supporting servers using the current (existing) aud value, at least for a transition period — likely necessary regardless of other decisions.
  • Stand up a second certification test suite/profile incorporating the new aud handling from the updated IETF draft, allowing implementers to choose between the existing suite and the new one.
  • Joseph noted some ecosystems are not actually vulnerable to the underlying issue, raising a policy question as to whether migration work should be forced on ecosystems that don't need it, versus allowing the current behaviour to persist for an extended period (potentially until a future post-quantum cryptography migration forces broader changes anyway). Joseph was explicit that this is a decision for the working group, not something he should determine unilaterally in his certification-team capacity.
• Peter Stanley provided UK-specific context: UK banks are subject to yearly FAPI conformance attestation. Any change that forces an uplift to bank-side components carries a meaningful lead time — banks need advance notice to plan, resource, and fund the necessary work ahead of their attestation deadlines. He emphasised that any "must do X by Y" requirement needs a substantial lead-up period and proper consultation beforehand, rather than arriving as a late or sudden requirement. He noted the UK ecosystem has not yet been engaged on this topic at all, and that he would like to bring a clear, well-formed message to them once options are developed, to gather their input on preferred approaches.
• The chair (Dima) thanked Peter for raising the topic and agreed the group needs to follow up, likely via Joseph raising/expanding the issue and the working group discussing options on a dedicated future call. The chair also suggested it would be useful to check on the precise publication status and content of the RFC 7523bis update before deciding next steps, since that may inform timing.