-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2026 05 13_Atlantic
Date: Wednesday, 13 May 2026 Chair: Dave Tonge (Moneyhub), standing in for Nat Sakimura (travelling)
| Name | Organisation |
|---|---|
| Dave Tonge (Chair) | Moneyhub |
| Joseph Heenan | OIDF / Authlete |
| Chris Wood | (Open Banking / UAE standards) |
| Christopher Robbertse | Open Banking Limited (OBL) |
| Matthew Murphy | Mastercard |
| Robert Gallagher | Mastercard |
| Hideki Ikeda | Authlete |
| Kosuke Koiwai | KDDI |
| Dima Postnikov |
Apologies: Nat Sakimura (travelling; attempted to join), Mike Leszcz (sent notes)
The OpenID Foundation Note Well was displayed and acknowledged at the start of the call.
Dave introduced the standard agenda structure. Joseph Heenan requested a brief slot on certification. The agreed agenda was:
- Events and external organisations (Mike Leszcz notes, read by Dave)
- Ecosystem engagement
- Certification update (Joseph)
- FAPI CIBA — open issues review
- Grant Management — publication status (Issue #847)
- OpenAPI / FAPI alignment proposal (Chris Wood)
- Any other business
Dave read out the events list prepared by Mike Leszcz. Attendees were invited to submit additional events to mike.leszcz@oidf.org.
- 12–15 May 2026 — ID4Africa, Abidjan — Gail, Elizabeth, and Dima representing OIDF
- 19–22 May 2026 — EIC 2026, Berlin — multiple OIDF presentations; member meet-up 18 May (details sent to members)
- 27–29 May 2026 — OAuth Security Workshop (OSW), Leipzig, Germany
- 2 June 2026 — FIDO Authenticate APAC, Singapore
- 9–10 June 2026 — Identity Week Europe, Amsterdam
- 15–18 June 2026 — Identiverse, Las Vegas
- 22–24 June 2026 — Dice 2026, Copenhagen
- 18–24 July 2026 — IETF 126, Vienna
- 26 August 2026 — OIDF-J OpenID Summit 2026 Special Edition, Tokyo
- 1–3 September 2026 — Global Digital Collaboration Conference, 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), 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
EIC scheduling note: Joseph and Nat will both be at EIC next week, which overlaps with the regular FAPI call. As only those two from the core group are affected, the call will proceed as normal and not be rearranged.
Dave read Mike Leszcz's ecosystem engagement summary.
Canada: OIDF held a call with the Canadian team last week. Updates were provided on OID specs progression and conformance scaling, and the Ecosystem Support Community Group was reintroduced as a vehicle for cross-ecosystem learning and contribution.
South America: Mike Leszcz and Domingos are supporting upcoming ecosystem engagement workshops in Peru and Colombia later in May. Sessions will cover an overview of the Foundation, a deep dive into FAPI and other OID open data specs, and the value of conformance and certification.
OIDF is also supporting an event in Colombia co-sponsored by Authlete and Capgemini that will convene regulator leaders from emerging South American ecosystems. OIDF is planning potential visits to existing partners and emerging ecosystems in the region.
Dima Postnikov shared a link in chat noting that Singapore's Singpass has published migration guidance for partners to move to the FAPI 2.0 production environment by 31 December 2026: https://partnersupport.singpass.gov.sg/hc/en-sg/articles/55071984024345--For-Partners-Migrate-to-Singpass-FAPI-2-0-Production-Environment-by-2026-12-31
Chris Wood (with Christopher Robbertse) reported that an introductory alignment meeting between the OpenAPI and FAPI communities has been organised for today at 17:00 BST. Anyone with an interest should contact Christopher Robbertse to receive the invite.
Chris has published design notes in a GitHub discussion on the OpenAPI Specification repository, which is already generating substantial conversation:
https://github.com/OAI/OpenAPI-Specification/discussions/5304
Attendees were encouraged to read the discussion and contact Chris on Slack with questions. Chris later walked through the proposal in detail; see §7 below.
Joseph confirmed that the certification tables for Client Credentials (machine-to-machine) certification are now in place. Working group approval to launch was obtained a few weeks ago. The remaining step is an email to the working group — being coordinated with Mike Leszcz — to announce that certification submissions are now open and to invite the first certifications.
The plan is to obtain a small number of initial certifications promptly, then have the OpenID Foundation issue a blog post and social media announcements publicising both the availability of the test suite and the initial set of certified implementations. This announcement was expected to go out either the same day or the following day.
Joseph described a request from an unnamed partner representing a new ecosystem (architecture similar to Saudi Arabia or UAE) where a single centralised authorisation server serves all banks, with each bank providing only a resource server. The partner has requested a certification focused specifically on the resource server.
This would involve two categories of change:
- Reducing scope: Omitting tests that target the authorisation server (since the AS is already FAPI-certified centrally), focusing instead on the integration between the new resource server and the existing AS.
-
Extending coverage: Adding tests currently absent from the generic API tests, for example:
- Verifying that a revoked access token is rejected at the resource server.
- Verifying that an access token issued for one scope cannot access APIs protected by a different scope.
Some tests may need to run in a sandbox environment, because production banks may support only a single scope (e.g. credit cards), making cross-scope negative tests impractical in production. Sandbox testing could use a test AS that issues tokens for scopes not present in production.
Joseph noted the need to clearly label any resulting certification as demonstrating FAPI-compliant resource server behaviour only, not AS compliance or full-stack compliance, to avoid confusion in the market.
Working group feedback: No objections were raised. Dave confirmed the concept has working group support. Joseph will provide updates as the work progresses.
Background (Issue #845)
https://github.com/openid/fapi/issues/845
The last published working draft of FAPI CIBA dates from 2019. Since then the spec has been adopted by Brazil (FAPI 1) and ConnectID (FAPI 2), and the certification team is developing tests for both ecosystems. Dave summarised the material changes since the 2019 draft:
- Replaced the lodging intent pattern with Rich Authorization Requests (RAR).
- Updated the back-channel authentication request: for FAPI 2 ecosystems, unsigned requests are now sufficient (message signing is reserved for non-repudiation use cases, not core security protocol).
- Added metadata around discovery and registration.
- Separated clauses explicitly into those applying to FAPI 1, FAPI 2, or both — a significant editorial effort.
- Updated narrative to recommend redirect-based flows for same-device scenarios, while decoupled (CIBA) flows target cross-device / user-not-present scenarios and are noted as comparatively less secure.
- Updated references to the IETF OAuth Working Group cross-device flow BCP.
- Updated TLS cipher suite references.
The goal is to publish a new draft as soon as possible, ahead of deciding whether to proceed to Final.
Dave requested volunteers to assist with editorial changes and asked that anyone who disagrees with the proposed issue dispositions below shout up on the relevant Bitbucket tickets.
Issue #580 — Signed and Unsigned Back-Channel Authentication Requests
https://github.com/openid/fapi/issues/580
Currently the spec requires support for both signed and unsigned requests. The agreed change for FAPI 2 is to require only unsigned requests. Editorial change to be made; no substantive objection.
Issue #556 — Add Reference to IETF Cross-Device Flow BCP
https://github.com/openid/fapi/issues/556
The PR was merged but the issue was not closed; an open note requires a few additional security consideration notes referencing the cross-device security document. Dave confirmed this is resolved and the issue can be closed.
Issue #506 — Explicit Security Target
https://github.com/openid/fapi/issues/506
There was earlier discussion (beginning of 2025) about defining an explicit security target now that the CIBA security analysis is complete. Dave's proposal: carry out an editorial review of the introduction, cross-reference the security analysis document, and lift any relevant text from it. The standard web attacker model used in the analysis needs to be examined in the context of cross-device flows. Action: Dave (or volunteer) to review introduction and security analysis and add reference.
Issue #718 — Add Reference to Security Analysis
https://github.com/openid/fapi/issues/718
Related to #506. Simply requires inserting a reference link to the completed security analysis. Action: Dave (or volunteer) to add link.
Issue #717 — Update RAR Reference in CIBA
https://github.com/openid/fapi/issues/717
Editorial: update the RAR reference and the Subject Identifiers reference to current versions before publication. Action: Dave (or volunteer).
Issue #229 — FAPI CIBA and ID Tokens
https://github.com/openid/fapi/issues/229
Originally raised in 2019, revisited in 2022 and 2024. Discussion concerned whether to make ID tokens optional. Dave's position: since FAPI CIBA is an OpenID spec and OpenID relies heavily on ID tokens, and since the FAPI 1 / FAPI 2 split now addresses the "no ID token" preference (use FAPI 2), this issue should be closed with no change. Joseph confirmed no recent ecosystem demand for this. Proposed disposition: close (won't fix), no objection heard.
Issue #676 — Simplifying Usage of FAPI CIBA
https://github.com/openid/fapi/issues/676
Dave recalled the discussion concluded that no change to the main FAPI spec would be made. Dima Postnikov (who raised the issue) was not present. Proposed disposition: close (won't fix), no objection heard.
Issue #674 — CIBA Response Parameters in PSD2 TPP Use Case
https://github.com/openid/fapi/issues/674
Related to the Swedish BankID ecosystem's use of CIBA for a same-device flow and a request to pass an additional security parameter. Dave noted that after considerable 2024 discussion there was no working group consensus to make the change, and there has been no ongoing demand. Proposed disposition: close (won't fix), no objection heard.
Issue #675 — FAPI CIBA Inheriting Security Profile Clauses
https://github.com/openid/fapi/issues/675
Raised during FAPI CIBA implementation work. Concerns how the spec inherits clauses from the chosen security profile (FAPI 1 vs FAPI 2). Dave assigned this to himself to review the editorial alignment. Action: Dave to review and resolve.
Issue #597 — CIBA: Make Clear Limitation of Binding
https://github.com/openid/fapi/issues/597
Working group previously agreed to address this by adding the cross-device flow reference. Dave's view is that the reference already being added under #556 is likely sufficient, but the assignee should confirm the limitation is covered either explicitly or by reference. Action: Dave (or volunteer) to verify coverage and close.
7. Grant Management Specification — Publication Status (Issue #847)
https://github.com/openid/fapi/issues/847
Joseph raised (and Issue #847 documents) that the Grant Management spec has not been formally updated for some time. Investigation during the meeting established:
- The spec was previously named "FAPI Grant Management"; Joseph has now added a redirect from the old URL to the current "OAuth 2.0 Grant Management" (Auth2V2) document.
- The HTML on OpenID.net was last published 17 May 2023 as Implementer's Draft 1.
- The Markdown was last updated in August 2023; examination of the file history showed the only change since the HTML was published was a draft number update — no substantive content changes.
- A Latin American ecosystem (name not stated) has committed directed funding to add grant management conformance tests to the FAPI test suite.
Agreed next steps:
- Joseph to add a comment to Issue #847 explaining the current state.
- Dave (or a volunteer) to review open issues against the Grant Management spec.
- Working group to discuss at a future call whether to take the spec through a second Implementer's Draft process.
8. FAPI 2 ID2 Test Deprecation (Issue #738)
https://github.com/openid/fapi/issues/738
Dave noted that the working group is still waiting for ecosystem feedback before proceeding with deprecation of the FAPI 2 ID2 conformance tests. No discussion needed at this time.
Chris Wood shared his screen and walked through the design proposal documented in the GitHub discussion at https://github.com/OAI/OpenAPI-Specification/discussions/5304.
The OpenAPI Specification's existing security scheme objects (including the MTLS security scheme and OAuth flow objects) are widely used in open banking and open finance standards globally (UK, UAE, FDX, and others), but they are intentionally lightweight — the MTLS scheme, for example, simply indicates the need for a client certificate with no further semantic content. This limits how well an OpenAPI document can describe the full requirements of a FAPI 2 security profile.
One option is to encode FAPI 2 requirements directly into the OpenAPI spec. Chris argued this would make OpenAPI brittle: every time a FAPI profile evolves, OpenAPI must also be updated, which is resource-intensive given the limited author bandwidth on the OpenAPI spec itself.
The proposal introduces a security profile scheme type in OpenAPI, complemented by a security profile requirement construct. Key design principles:
- Loose coupling: The OpenAPI document provides just enough information to identify and reference the security profile, but does not attempt to inline all of the profile's normative requirements. Full details remain in the profile document itself (e.g. the FAPI 2 Security Profile specification).
- Profile metadata: The security scheme identifies the profile name (e.g. "FAPI2 Security Profile"), a schema defining supported parameters and security requirements, and server endpoints (e.g. discovery endpoints).
- Security profile requirement: Analogous to existing security requirements but extended ("on steroids") to carry grant type, required scopes, token endpoint authentication method (e.g. private_key_jwt), and a reference to the operations needed to obtain credentials (e.g. pushed authorisation request → authorisation code → token exchange).
- Linked operation descriptions: The requirement can reference either a standard OpenAPI description of the security operations, or an Arazzo workflow document describing the full sequence. This explicitly links a protected resource to the operations a client must execute to gain access.
- Generality: The mechanism is not FAPI-specific; it could accommodate OpenID Connect profiles, OAuth server metadata profiles, GNAP, or any other security requirement set.
Chris highlighted a specific gap identified with Henry Andrews (OpenAPI TSC): the Rich Authorization Request (RAR) object currently has no well-designed, explicitly-referenced representation in OpenAPI documents. Even if nothing else is achieved, creating a clear, standardised reference from a resource to its associated security operations would benefit a wide range of ecosystem implementers and tooling authors.
The current YAML examples Chris shared are acknowledged design sketches rather than finished proposals.
Call to action:
- Read the GitHub discussion: https://github.com/OAI/OpenAPI-Specification/discussions/5304
- Attend the FAPI/OpenAPI alignment meeting at 17:00 BST today (contact Christopher Robbertse for an invite).
- Comment in the GitHub discussion with feedback from the perspectives of standards authors, implementers, and tooling makers.
- Working group reaction: No objections; Dave commented the automatic client generation use case is particularly interesting.
| # | Action | Owner | Notes |
|---|---|---|---|
| 1 | Send email to working group announcing Client Credentials certification launch; coordinate with Mike Leszcz | Joseph Heenan | Expected same day or following day |
| 2 | Provide updates to working group as Resource-Server-Focused certification variant progresses | Joseph Heenan | Early days |
| 3 | Review CIBA introduction and security analysis; add explicit security target text (Issue #506) | Dave Tonge (or volunteer) | Can lift text from completed security analysis |
| 4 | Add reference link to security analysis in CIBA spec (Issue #718) | Dave Tonge (or volunteer) | |
| 5 | Update RAR and Subject Identifiers references in CIBA before next draft (Issue #717) | Dave Tonge (or volunteer) | |
| 6 | Review CIBA clause inheritance for FAPI 1 / FAPI 2 editorial alignment (Issue #675) | Dave Tonge | Assigned on call |
| 7 | Verify limitation-of-binding coverage; close Issue #597 once confirmed | Dave Tonge (or volunteer) | Check cross-device reference is sufficient |
| 8 | Add comment to Issue #847 explaining current Grant Management publication state | Joseph Heenan | |
| 9 | Review open issues against Grant Management spec; schedule future discussion on ID2 process | Dave Tonge | |
| 10 | Close Issues #229, #674, #676 as "won't fix" (no objections on call; leave open briefly for written objections) | Dave Tonge |