Skip to content

FAPI_Meeting_Notes_2026 03 18_Atlantic

Jump to bottom
Nat Sakimura edited this page Jul 10, 2026 · 1 revision

FAPI Working Group — Atlantic Call

Date: Wednesday, 18 March 2026 Time: 14:00 UTC Chair: Nat Sakimura Note-taker: (from recording transcript)

Attendees

Name Organisation
Nat Sakimura (Chair)
Mike Leszcz OpenID Foundation (OIDF)
Matthew Murphy Mastercard
Joseph Heenan OIDF / Authlete
Alan Smillie OIDF Certification Team
Robert Gallagher Mastercard
Bjorn Hjelm Yubico
Hideki Ikeda Authlete
Kosuke Koiwai KDDI
Christopher Robbertse Open Banking Limited (OBL)
Peter Stanley Open Banking Limited (OBL)

Note: attendance list compiled from chat log roll call. Several regular participants were absent due to IETF 125 in Shenzhen.

Note Well

Participants were reminded of the OpenID Foundation Note Well and IPR obligations. Mike Leszcz noted that Alan Smillie's participation as OIDF staff in the certification team is on the Foundation's list of items for official legal review (to be addressed by Tom). For the purposes of today's call, his presentation was treated as analogous to Joseph Heenan raising conformance test issues within the working group — i.e., seeking feedback before proceeding — consistent with established practice.

Agenda

Adopted with one addition: a certification suite demo item was elevated to the top of the agenda, ahead of the regular PR and issue reviews.

  1. Roll Call
  2. Adoption of Agenda
  3. Demo — FAPI Client Credentials Grant Certification Test Plan (Alan Smillie)
  4. Events
  5. External Orgs & Liaisons / Ecosystem Updates
  6. PRs
  7. Issues
  8. AOB

1. Demo: FAPI 2 Client Credentials Grant Certification Test Plan

Presented by: Alan Smillie (OIDF Certification Team) Reference: Example Client Credentials Grant Test Plan Run

Recording / Sharing Policy

Nat confirmed that the video of this meeting will not be shared. Only a splice covering the demo portion may be made available to wider working group members who were absent (many attending IETF 125 in Shenzhen). Participants who do not wish to appear in the shared clip were advised not to speak during the demo.

Demo Summary

Alan shared the staging certification environment. Key points from the demonstration:

  • The new test plan is derived from the existing FAPI test plan, but scoped exclusively to tests relevant to the Client Credentials Grant.
  • The only configurable variants exposed to users are client authentication type and sender constraint (e.g., private key JWT with DPoP). All other configuration options are locked.
  • The test plan does not require the server to advertise authorization endpoints or PAR endpoints — the server need only declare support for a client credentials grant.
  • The happy-flow test calls the token endpoint, verifies the response, and then calls the resource endpoint (in this case, an accounts endpoint). The test concludes once a successful response is received.
  • The test suite is a multi-client test and verifies that access tokens are properly sender-constrained via DPoP.
  • In essence: a subset of the existing FAPI tests, refactored to operate against an access token obtained via client credentials rather than the authorization code flow.

Pre-Launch Status

Joseph reported the certification program requires test results from three independent entities before launch. Current status:

  • Two entities have submitted results — Authlete, and one other entity (not named on the recording at that entity's discretion).
  • One additional entity has offered to run the tests but has not yet done so.

Robert Gallagher (Mastercard) noted in chat that Mastercard has run the tests and found all results satisfactory.

Working Group Disposition

The working group expressed no objections to the test plan. Nat stated it looked acceptable, but noted the low attendance (11 participants) due to IETF week and committed to:

  • Sending an email to the working group mailing list soliciting any further objections.
  • Updating Issue #842 with the official outcome once the list has been consulted.

Alan was asked to publish the test run result and share the link so that absent members can review the log at their convenience.

2. Events

Presented by Mike Leszcz (OIDF). Full events calendar dropped into chat.

Date Event Location
14–20 March 2026 IETF 125 Shenzhen, China
16–17 March 2026 ISO/IEC JTC 1/SC 27 Plenary Nürnberg, Germany
16–19 March 2026 FDX Global Summit 2026 Washington, DC
14 April 2026 OECD Working Party on Digital Security Paris
22–23 April 2026 IAM Tech Day São Paulo
27 April 2026 OIDF Workshop (prior to IIW Spring 2026) Mountain View (Cisco — hybrid)
28–30 April 2026 IIW Spring 2026 Mountain View
12–15 May 2026 ID4Africa Abidjan
19–22 May 2026 EIC 2026 Berlin
27–29 May 2026 OAuth Security Workshop (OSW) Leipzig, Germany
2 June 2026 FIDO Authenticate APAC 2026 Singapore
15–18 June 2026 Identiverse Las Vegas
22–24 June 2026 DICE 2026 Copenhagen
18–24 July 2026 IETF 126 Vienna
1–3 September 2026 Global Digital Collaboration Conference 2026 Geneva
14–17 September 2026 ISO/IEC JTC1/SC 17 Plenary Chengdu, China
19–21 October 2026 FIDO Authenticate 2026 Carlsbad, CA
2 November 2026 OIDF Workshop (prior to IIW Fall 2026) Mountain View
3–5 November 2026 IIW Fall 2026 Mountain View
14–20 November 2026 IETF 127 San Francisco
7–9 December 2026 Gartner IAM US Las Vegas

Key highlight — OIDF Workshop, 27 April 2026:

Registration is open. Cisco is confirmed as host. Registration is required even for virtual participation.

Registration link: https://openid.net/registration-open-for-openid-foundation-hybrid-workshop-on-mon-27th-april-2026/

To request additions to the 2026 events calendar, contact: mike.leszcz@oidf.org

3. External Organisations & Ecosystem Updates

Chile — CMF / FAPI 2 Deployment

Mike provided an update on the Chilean financial ecosystem:

  • The CMF (Comisión para el Mercado Financiero) is developing a FAPI 2 profile for the Chilean open finance ecosystem.
  • A proposal to include the Shared Signals Framework in Phase 1 has been deferred — SSF will be picked up in Phase 2, expected in 2027.
  • The FAPI 2 launch in Chile remains on track for the second half of 2026.
  • Mike Leszcz and Domingos have a follow-up call with the CMF and their implementation partner the following week to confirm the profile and milestone schedule.

Member Vote Reminder

Mike reminded working group members that a vote is currently open on the Proposed OpenID Connect Relying Party Metadata Choices 1.0 Final Specification. The public review period started 9 January 2026; voting opened 11 March 2026. Abstain votes count toward quorum. Members were encouraged to vote at their earliest convenience.

4. Pull Requests

Nat noted there are no substantial updates to PRs to report this week. He acknowledged he had not yet merged pending items as committed the previous week, and will address one FAPI-related fix that Joseph had identified. No further PR discussion was required.

5. Issues

Open issues tracker: https://github.com/openid/fapi/issues?q=is%3Aissue%20state%3Aopen

Four new issues were raised since the last meeting. One older issue was also revisited.

Issue #842 — Approval to Launch Client Credentials Grant Certification

Link: https://github.com/openid/fapi/issues/842

This issue tracks the working group's formal approval for launching the FAPI 2 Client Credentials Grant certification programme. Discussion was conducted under the demo item above. The working group expressed no objections. Nat will:

  • Email the mailing list for any remaining objections.
  • Update the ticket with the official outcome.

Issue #843 — OAuth Security BCP Addition

Link: https://github.com/openid/fapi/issues/843

Joseph reported on a new IETF document observed at the OAuth Working Group session at IETF 125 in Shenzhen (attended virtually):

  • The document is not a full update to the existing OAuth Security BCP (RFC 9700 / BCP 240), but a supplementary document addressing two additional attack types.
  • The document is expected to become part of BCP 240 alongside the existing BCP — it will not replace it.
  • The document is near working-group last call; there is a strong intent to keep the scope narrow and get it published quickly.
  • Of the two attacks:
    • One (private key JWT-related) has already been addressed by FAPI 2.
    • One is more complex and only partially understood; it may be subject to some revision before finalisation.
  • FAPI 2 may need to be updated to explicitly acknowledge that these attacks have been considered, even if no substantive changes are needed.

Action required: Nat asked for a volunteer to evaluate the two attacks against FAPI 2 and determine what, if anything, needs to be done. No volunteer came forward on the call; Nat will send a request to the mailing list. Nat indicated he would attempt his own evaluation, but noted he is often a bottleneck.

Issue #844 — FAPI Not Currently Compliant with CNSA 2.0

Link: https://github.com/openid/fapi/issues/844

This issue was filed by Joseph following observations at IETF 125. Key points:

Background: The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) mandates the discontinuation of SHA-256 and requires quantum-safe cryptographic algorithms. Because FAPI 2 currently mandates PKCE with S256 as the code challenge method, environments required to comply with CNSA 2.0 cannot deploy FAPI-based APIs.

Specific concerns identified:

  • FAPI 2 hard-codes S256 as the PKCE code challenge method.
  • DPoP access token hashes and mTLS certificate fingerprints also use SHA-256.
  • A new RFC (by Philip and Brian) proposes allowing SHA-384 and SHA-512 as PKCE code challenge methods, which could provide a path forward.
  • JOSE working group is also discussing post-quantum algorithms (Joseph was unable to attend due to timezone conflicts).

Discussion:

Nat (attending ISO/IEC SC 27 meetings this week in Nürnberg) shared perspectives from cryptographers: from a purely technical standpoint, quantum computers capable of breaking current algorithms ("Q-day") are estimated to be decades away — possibly 20–30 years. However, migration timescales are long, so planning should begin.

Joseph noted the practical complexity: migrating to post-quantum safety would require upgrades across vendor products, TLS terminators, and much of the infrastructure stack. There is also a significant performance overhead.

Peter Stanley (OBL) noted that the UK Open Banking ecosystem only recently (within the past two years) migrated to FAPI 1 Advanced, and there is limited appetite to move to FAPI 2 in the near term. The CNSA 2.0 requirement is US-centric and does not currently bind UK deployments, so OBL is comfortable in the short term.

Nat speculated that by the time post-quantum migration becomes truly necessary, the relevant specification may not be FAPI 2 at all, but a future FAPI 2.5 or FAPI 3.

Consensus: No imminent danger from a technical standpoint. Addressing SHA-256 in isolation is insufficient — the full suite of quantum-safe requirements (TLS cipher suites, key exchange algorithms, etc.) would need to be considered holistically. The group agreed to monitor IETF progress (particularly the PKCE extension RFC) before taking concrete action.

Issue #845 — Publishing an Updated Draft of FAPI-CIBA

Link: https://github.com/openid/fapi/issues/845

Reference (published spec): https://openid.net/specs/openid-financial-api-ciba-ID1.html

Joseph raised this issue, noting that ecosystems are adopting FAPI-CIBA and the published specification on openid.net dates from 2019:

  • Brazil is again talking about rolling out FAPI-CIBA (this is approximately the third time; Joseph noted previous announcements had not materialised, but the certification team has nonetheless updated the Brazil FAPI-CIBA profile test to match the latest Brazilian profile).
  • ConnectID has requested certification tests covering eKYC + FAPI-CIBA (technically FAPI 2 CIBA).
  • Work has been done to align FAPI-CIBA with FAPI 2 since the 2019 publication, but none of these updates have been published to openid.net/specs.

Peter Stanley (OBL) confirmed that the UK Open Banking specification (due for refresh in approximately two weeks) currently references the 2019 CIBA spec and requires implementers to conform to it for CIBA deployments. At least one of the CMA9 banks has implemented something resembling CIBA, though adoption is not widespread.

Peter requested:

  • A comparison of the 2019 published spec against current working drafts, so he can assess the impact any new publication would have on the UK ecosystem.
  • That information be sent to the mailing list.

Joseph noted it may be possible to trace changes via the Bitbucket file history. Nat confirmed that Bitbucket does support this. He will post the relevant diff/link to the issue and to the mailing list.

Agreement: A dedicated call on FAPI-CIBA will be arranged (with Dave's participation) to review outstanding issues and plan next steps. Nat will send the Bitbucket history link to the issue tracker and mailing list to facilitate that discussion.

Issue #744 — Certification Team Query: Refresh Tokens in Client Credentials Grant

Link: https://github.com/openid/fapi/issues/744

This older issue was revisited in the context of the client credentials grant certification programme.

Background: The certification tests for the client credentials grant currently ignore any refresh token returned by the server. The question is whether the test should do something about it — warn, test it, or require it not be returned.

Discussion:

Joseph reviewed RFC 6749 and found the following: the specification only references access tokens in the client credentials grant response, and states that a refresh token should not be included (RFC 6749 §4.4.3). Joseph committed to adding the exact RFC text and a link to the issue.

Nat noted RFC 6749 is generally permissive on refresh token issuance (e.g., permitting refresh tokens to public clients), so the should not language is notable.

The group discussed options:

  • Do nothing: the test silently ignores any returned refresh token.
  • Warn: if a refresh token is returned, emit a warning (consistent with should not in RFC 6749).
  • Test it: if a refresh token is returned, also test that it is properly sender-constrained and functional.

Joseph noted that for the authorization code flow, tests do exist for refresh token handling (and are optional in FAPI 2); adapting these for the client credentials grant would be a small piece of work.

Nat's view: in FAPI there are no public clients, and if a refresh token is returned it should at minimum be sender-constrained. However, his gut feeling — given the RFC language — is that issuing a warning when a refresh token is returned may be the appropriate and proportionate response.

Conclusion: Nat will leave the issue open for one more week and consult the mailing list. The intent is to close it at the following meeting.

6. AOB

Nat noted the next calls for the working group:

  • FAPI WG Pacific Call: Thursday (19 March 2026 for most participants) / Friday (20 March 2026 Japan time). Nat will not be able to chair; Dave (Tonge, per usual practice) will also not be available. The call will proceed with however many participants join.
  • Next Atlantic Call: Wednesday, 25 March 2026, same time.

Action Items

# Action Owner Due
1 Email working group mailing list on client credentials cert programme (Issue #842) to solicit any objections Nat Sakimura By next Atlantic call (25 Mar)
2 Update Issue #842 with official working group outcome after mailing list period Nat Sakimura 25 Mar 2026
3 Publish client credentials test plan run result; share link in WG channels Alan Smillie This week
4 Merge pending FAPI PR (fix identified by Joseph) Nat Sakimura ASAP
5 Solicit volunteers (via mailing list) to evaluate new OAuth Security BCP supplement attacks against FAPI 2 (Issue #843) Nat Sakimura 25 Mar 2026
6 Add RFC 6749 §4.4.3 text and link to Issue #744 Joseph Heenan Done (during call)
7 Consult mailing list on Issue #744 (refresh tokens in client credentials grant); aim to close at next Atlantic call Nat Sakimura 25 Mar 2026
8 Post Bitbucket file-history link for FAPI-CIBA to Issue #845 and to the mailing list Nat Sakimura This week
9 Arrange a dedicated FAPI-CIBA call with Dave's participation to review outstanding issues Nat Sakimura TBD
10 Cast vote on Proposed OpenID Connect Relying Party Metadata Choices 1.0 Final Specification (if eligible member) All WG members ASAP

Reference Links

Clone this wiki locally