-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2026 02 18_Atlantic
Date: 2026-02-18 14:00 UTC
Attendees: Nat Sakimura (chair), Mike Leszcz (OIDF), Hideki Ikeda, Joseph Heenan (OIDF & Authlete), Chris Wood (Ozone / OpenAPI Initiative), Christopher Robbertse, George Fletcher, Filip Skokan, Matthew Murphy (Mastercard), Robert Gallagher (Mastercard), Domingos Creado, Imran Ulghar (OBL), Mark Boyd (OpenAPI Initiative), Mark Haine
- Roll Call
- Adoption of Agenda
- Events (Mike L. / Nat)
- External Orgs & Liaisons (Mike L. / Nat)
- OpenAPI & FAPI (guest session)
- PRs
- Issues
- AOB
Mike Leszcz reported no material updates from the prior week. All 2026 internal meetings and industry events have been added to the OIDF Google Calendar and the website calendar. A full list of upcoming events is reproduced below for reference.
- 9–13 March — ISO/IEC JTC 1/SC 27 WG Meeting, Nürnberg, Germany
- 14–20 March — IETF 125, Shenzhen, China
- 16–17 March — ISO/IEC JTC 1/SC 27 Plenary, Nürnberg, Germany
- 16–19 March — FDX Global Summit 2026, Washington, DC
- 27 April — OIDF Workshop prior to IIW Spring 2026, Mountain View (hosted by Pam Dingle / Microsoft — logistics being confirmed; registration blog post forthcoming)
- 28–30 April — IIW Spring 2026, Mountain View
- 12–15 May — ID4Africa, Abidjan
- 19–22 May — EIC 2026, Berlin
- 27–29 May — OAuth Security Workshop (OSW), Leipzig, Germany
- 2 June — FIDO Authenticate APAC 2026, Singapore
- 15–18 June — Identiverse, Las Vegas
- 22–24 June — DICE 2026, Copenhagen
- 18–24 July — IETF 126, Vienna
- 1–3 September — Global Digital Collaboration Conference 2026, Geneva
- 14–17 September — ISO/IEC JTC1/SC 17 Plenary, Chengdu, China
- 19–21 October — FIDO Authenticate 2026, Carlsbad, CA
- 2 November — OIDF Workshop prior to IIW Fall 2026, Mountain View
- 3–5 November — IIW Fall 2026, Mountain View
- 14–20 November — IETF 127, San Francisco
- 7–9 December — Gartner IAM US, Las Vegas
Note: Nat flagged a newly announced OECD Working Party on Digital Security on 14 April. One of the agenda item is security on artificial intelligence, and quantum computing. Mike will add the date to the OIDF calendar.
Action: Anyone aware of additional 2026 events should send details to mike.leszcz@oidf.org.
SAMA is transitioning to a new FAPI 2.0 profile. Directed funding to support development of the new KSA FAPI 2.0 profile is in process via Ozone. Domingos Creado, who authored the original KSA profile, will lead development of the new profile.
Domingos and Mike L held a follow-up call in the week of 19 January to discuss the transition from FAPI 2.0 Implementer's Draft to FAPI 2.0 Final. Ralph Bragg (Raidiam) has since confirmed the impact is minimal: the UAE profile had already incorporated all elements from FAPI 2.0 Final that were not present in ID2, so the primary work is removing now-redundant content. Ozone and UAE are coordinating communications to TTPs. Transition is anticipated in Q2 2026.
CMF is targeting August 2026 for regulation to be in place, with initial FAPI 2.0 certifications expected during 2026 and the ecosystem going live in earnest in early 2027. Minsait is CMF's implementation partner and is in the process of joining OIDF to provide directed funding. CMF is also considering adopting Shared Signals. A next call will include a Shared Signals WG co-chair and Thomas from the certification team.
Gail Hodges and Domingos held a follow-up call the week of 2 February, covering Peru's interest in the Ecosystem Support CG, OIDF Working Groups, and certification requirements. Peru's adoption of FAPI 2.0 is well underway; an updated roadmap is expected at the end of February. OIDF has offered an ecosystem outreach workshop similar to those conducted in other markets.
2026 recertification is under way.
Authlete and Capgemini are hosting an event in Bogotá on 13 April 2026, with support from OIDF on content and introductions to South American open banking ecosystems. The goal is to engage senior South American government officials responsible for open banking and open data initiatives, with a strong focus on OpenID standards and adoption in other jurisdictions. Details remain fluid. Joseph Heenan and Domingos Creado are likely to participate along with at least one additional OIDF staff member.
Chris Robbertse (FAPI WG) arranged for guests from the OpenAPI Initiative (OAI) to present and explore potential collaboration. The following guests introduced themselves:
- Mark Boyd — Co-chair of the OAI Industry Standards Special Interest Group, currently focused on financial services.
- Chris Wood — Content Director at OAI; also works for Ozone and has a keen interest in open banking API standards. He is involved in the OAI Industry Standards SIG.
Mark Haine also noted his prior involvement with the OAI, including work on the Arazzo specification alongside Frank McCummins, including an experiment to express the PAR → Authorize → Token sequence in Arazzo.
Chris Wood conducted a screen-share presentation covering two related opportunities for FAPI-OpenAPI alignment, using the UAE Open Banking ecosystem API descriptions (published as OpenAPI 3.0 / Redoc) as a live example.
Chris demonstrated UAE's OpenAPI description of the Pushed Authorization Request (PAR) endpoint and token endpoint, covering:
- Representation of client assertion properties and request payload (acknowledging that in practice these are JWTs, and that OpenAPI 3.1+ / 2020-12 JSON Schema brings improved support for serialized vs. payload separation).
- Authorization details (RAR), showing ecosystem-specific consent payload variants (AIS, PIS, insurance data sharing) as open objects within the canonical framework.
- Token endpoint responses including the lifecycle representation of rich authorization requests.
The goal is to produce a FAPI-endorsed framework that ecosystems can take, and then apply local overlays (using the OpenAPI Overlay mechanism) to produce jurisdiction-specific descriptions — e.g., UAE-specific consent payloads on top of the common security framework. Chris noted that FDX is currently at risk of developing its own parallel representation, so an authoritative canonical source would benefit multiple ecosystems.
The current OpenAPI security scheme object is a thin representation (token endpoint URL + scopes), which does not meaningfully capture the security requirements of a real FAPI operation. Chris proposed:
- Strengthening the relationship between the OpenAPI security scheme and OpenID Connect / OAuth Server Metadata discovery documents.
- Publishing enough in the API description (profiles supported, permitted response types, scope taxonomy, environment URLs — production vs. sandbox) that a developer or AI agent has sufficient context without having to separately parse the discovery endpoint.
- Discovery would remain the master record; OpenAPI would carry a meaningful subset.
Chris shared a related GitHub issue at OAI/OpenAPI-Specification #4106 where he had posted exploratory notes.
Mark Haine raised the more radical long-term question: could OpenAPI representations become normative (from an OIDF specification perspective), rather than merely informative? He noted that a machine-readable, formal description could be more deterministic than English prose, though he acknowledged this is a significant challenge.
Nat Sakimura recalled that a similar idea was considered when FAPI work began around 2016, when the tooling (then Swagger) was not expressive enough. He indicated support for revisiting this if the machinery can now provide sufficiently deterministic representations.
Filip Skokan observed that OpenAPI is maturing steadily and may now be usable for describing OAuth flows, but raised practical concerns: FAPI 2.0 profiles rather than specifying new constructs, and FAPI does not mandate authorization details or a specific client authentication method (JWT vs. MTLS). Any canonical API description would therefore be a framework with open extension points, not a complete specification. He also noted the FAPI WG is unlikely to commit to maintaining something as normative as the spec itself.
Chris Wood agreed, framing the canonical OpenAPI description as a framework that ecosystems refine via overlays, rather than a standalone normative document. He noted the OpenAPI 3.1 / 2020-12 JSON Schema upgrade (Prefix Items) moves closer to enabling proper JWT representation, though further work remains.
Mark Boyd proposed that a subset of FAPI WG members and interested OAI members form a joint working group. Key points agreed:
- A dedicated Slack channel will be created in the FAPI Slack workspace.
- All interested parties from both FAPI and OAI will introduce themselves in the channel by end of February 2026.
- A kickoff meeting will be scheduled for early March 2026, timed to be accessible to US Pacific timezone participants (OAI has a member in Pacific time who holds a contract allowing dedicated contribution time).
- The FAPI Pacific call may be a suitable venue. Nat noted Anoop Saxena (Intuit, FAPI WG co-chair) could potentially participate. Nat himself may not attend due to timezone but this should not block progress.
- The joint working group will report progress back to both the FAPI WG and the OAI.
The proposal was adopted without objection. Nat thanked Chris Wood and Christopher Robbertse for arranging the session.
With approximately 10 minutes remaining, Nat briefly reviewed the PR queue. No substantive progress was possible in the time available. Dave Tonge (co-chair) is expected to return from leave next week, which should unblock progress on implementation advice items including:
- PR #540 — Implementation advice (awaiting Dave Tonge's return)
Issue #840 — TLS 1.3 / Cipher Deprecation
Issue #840 — Joseph Heenan reported that the IETF document previously understood to mandate TLS 1.3 does not in fact apply to FAPI. The current BCP position is a SHOULD (not MUST) support TLS 1.3. Joseph has opened a conformance suite ticket to add a warning (non-blocking for certification) when TLS 1.3 is not supported, to draw attention to the future requirement. No further action is required from the FAPI WG at this time.
Resolution: Issue #840 closed.
Issue #839 — FAPI 2.0 OSCAL Profile
Issue #839 — Nat noted there has been no update since discussion at the last call. Joseph reported that Ryan (NIST contact) has offered to introduce the WG to the OSCAL team if desired. Nat indicated he will paste relevant discussion notes from the last meeting into the ticket. No further action required from the WG at this time.
Issue #835 — Network Layer Protections / ChaCha20-Poly1305 Cipher Suite
Issue #835 — The certification team is working on adding ChaCha20-Poly1305 support to the conformance suite. Joseph reported the team is code-complete but an unexpected test result is currently being investigated by the developer.
Separately, the WG needs to explicitly add a reference to the IANA TLS cipher suite registry in the FAPI 2.0 specification (currently referenced implicitly via BCP-195 but not cited directly). This is needed to formalise reliance on the registry for allowed cipher suite selection.
Action: Robert Gallagher (Mastercard) to open a PR adding an explicit reference to the IANA TLS cipher suite registry in FAPI 2.0.
Mastercard Blog Post — Robert Gallagher confirmed via chat that a Mastercard blog post was submitted the previous week. Joseph noted it had been circulated to the working group chairs and a question had been raised about whether full WG review was needed. Nat confirmed he will circulate it to the working group.
No further business was raised.
| Owner | Action |
|---|---|
| Mike Leszcz | Add OECD 14 April security meeting date to the OIDF calendar |
| Nat Sakimura | Paste last call's discussion notes into Issue #839 (OSCAL) |
| Nat Sakimura | Circulate Mastercard blog post to the full FAPI working group for review |
| Robert Gallagher / Mastercard | Open a PR to add an explicit reference to the IANA TLS cipher suite registry in FAPI 2.0 |
| Chris Robbertse / Mark Boyd | Set up a dedicated FAPI/OAI joint working Slack channel; all interested members to introduce themselves by end of February |
| Mark Boyd / OAI | Co-ordinate logistics for joint FAPI-OAI kickoff meeting in early March 2026 |
| Joseph Heenan | Conformance suite ticket opened to add TLS 1.3 warning (non-blocking); no further action on Issue #840 |
Next Atlantic call: Wednesday, 25 February 2026 at 14:00 UTC