Repository navigation
FAPI_Meeting_Notes_2026 08 26_Atlantic
Date: 2026-08-26
Time: 14:00 UTC
Location: Zoom
Chair: Nat Sakimura (NAT.Consulting)
Co-Chair: Dima Postnikov
Mike Leszcz read the OIDF note well, covering the Code of Conduct policy, the antitrust policy, and the requirement for a signed contribution agreement to contribute to any OpenID Foundation working group. All referenced policies are published at https://openid.net/policies.
| Name | Affiliation |
|---|---|
| Nat Sakimura (Chair) | NAT.Consulting |
| Dima Postnikov (Co-Chair) | Individual |
| Mike Leszcz | OpenID Foundation |
| Joseph Heenan | OpenID Foundation / Authlete |
| Filip Skokan | Okta |
| George Fletcher | Practical Identity |
| Kosuke Koiwai | KDDI |
| Bjorn Hjelm | Yubico |
| Christopher Robbertse | Open Banking Limited |
| Peter Stanley | Open Banking Limited |
| Matthew Murphy | Mastercard |
| Phillip Koumides | Australian Treasury (Data Standards Body, CDR) |
| Alfred Ho | Australian Treasury (Data Standards Body, CDR) |
| Ashmita Chakraborty | Individual contributor |
Two colleagues from the Australian Data Standards Body were welcomed to the call:
- Alfred Ho noted that this was not his first attendance — he had joined a couple of times previously but had not always been able to enter his name in the chat.
- Phillip Koumides introduced himself as a colleague of Alfred's in the Data Standards Body at the Australian Treasury, working on the Consumer Data Right (CDR), which he described as the Australian equivalent of UK Open Banking.
Mike Leszcz confirmed for the record that both Phillip and Alfred are listed on the Treasury contribution agreement on file with the Foundation.
The default agenda was adopted:
- Roll Call (Nat)
- Adoption of Agenda (Nat)
- Events (Mike L.)
- External Orgs & Liaisons (Mike L.)
- PRs (Nat)
- Issues (Nat)
- AOB (Nat)
One addition was made. Phillip Koumides asked for time to raise (a) the DSB's call for expressions of interest in reviewing the Australian CDR standards for FAPI 2.0 adoption, and (b) a technical question on the security profile. These were added as item 4.1 — AU DSB topics, to be taken immediately after item 4.
Mike Leszcz posted the events list to the chat and highlighted one newly added entry: Finance of Tomorrow, 2026-11-17 to 2026-11-18, Rio de Janeiro. He confirmed it would be propagated to the other OIDF calendars shortly after the call.
| Dates | Event | Location |
|---|---|---|
| 2026-08-26 | OIDF-J OpenID Summit 2026 Special Edition | Tokyo |
| 2026-09-01 to 2026-09-03 | Global Digital Collaboration Conference 2026 | Geneva |
| 2026-08-31 | DCP and DCHP WG meetings (ahead of GDC) | Geneva |
| 2026-09-14 to 2026-09-17 | ISO/IEC JTC 1/SC 17 Plenary | Chengdu, China |
| 2026-10-19 to 2026-10-21 | FIDO Authenticate 2026 | Carlsbad, CA |
| 2026-11-02 | OIDF Workshop prior to IIW Fall 2026 | Mountain View |
| 2026-11-03 to 2026-11-05 | IIW Fall 2026 | Mountain View |
| 2026-11-14 to 2026-11-20 | IETF 127 | San Francisco |
| 2026-11-17 to 2026-11-18 | Finance of Tomorrow | Rio de Janeiro |
| 2026-12-07 to 2026-12-09 | Gartner IAM US | Las Vegas |
| 2027-02-02 to 2027-02-04 | 2027 OIDF Global Conference (save the dates) | London |
2027 events for inclusion on the calendar should be sent to mike.leszcz@oidf.org.
Kosuke Koiwai flagged in chat that the week of 2027-02-02 is also when the FIDO plenary takes place in Paris, creating a conflict with the OIDF Global Conference in London. Mike Leszcz acknowledged the conflict, confirmed he had passed it to the marketing team, and said announcements on how it will be addressed would follow.
Nat Sakimura reported on the Japanese event held earlier the same day:
- Approximately 237 attendees on the main day; the preceding smaller day drew about 80.
- Registration turnout was unusually high — 100% of registrants attended the first day and roughly 95% on the second.
- Sessions covered OpenID Federation and AuthZen among other topics.
Kosuke Koiwai added that a substantial share of the programme was devoted to AI agents, and that the AI agent discussions kept returning to FAPI and Federation as the underlying building blocks — which set the overall tone of the event. Nat credited Kosuke and the team for a very professionally run event.
Nat also noted that OpenID Foundation Japan has published a guideline on identity assurance for private sector. He characterised it as follows:
- It is a profile of the Japanese government standard on identity proofing and authentication.
- It is broadly aligned with NIST SP 800-63-4, but the identity-proofing portions are adapted to Japanese conditions because a widely held digital identity document already exists. Its primary form is a smart card, with the reader application on the phone; Nat cited an 84% population-level uptake of My Number Card.
- The government guidelines apply to government use cases; the OIDF Japan publication profiles them for private sector use.
Mike Leszcz reported that OIDF is considering a series of meetings with existing and prospective Latin America ecosystem partners adjacent to the Finance of Tomorrow event in Rio. Gail Hodges, Mike Leszcz and Joseph Heenan would be travelling, with Domingos Creado already in Brazil. The rationale is that the event offers the best available opportunity for face-to-face time with current and incoming partners. Confirmation either way will be reported on a future working group call.
Two votes are open and member participation was requested. Abstentions count towards quorum.
| Vote | Closes |
|---|---|
| Proposed Implementer's Drafts of two OpenID Federation extensions | Friday 2026-09-04, 12:00 PT |
| Proposed Implementer's Draft of OpenID Connect Key Binding (noticed 2026-08-10) | Monday 2026-09-07, 12:00 PT |
Mark Haine has stepped down as OIDF Technical Director to focus on another project, and the Foundation is now recruiting a replacement. [Editorial flag 4] Attendees were asked to circulate the job description to anyone who might be interested.
Phillip Koumides and Dima Postnikov set out the background: the Australian CDR (Open Banking in Australia) is migrating to FAPI 2.0. The DSB has prepared a FAPI 2.0 profile and is seeking help from working group participants to review parts of it.
Phillip noted that an earlier attempt to send this to the FAPI mailing list had bounced; Dima explained the message was most likely rejected because the sending address is not on the moderated list. Phillip posted the call for expressions of interest to the Zoom chat and will coordinate with Dima on getting it onto the mailing list as well.
The text as posted:
The Data Standards Body (DSB) is continuing work on proposed changes to the Australian Consumer Data Right (CDR) Standards to support the adoption of FAPI 2.0 (CD210 – FAPI 2.0 Alignment). To support the ongoing development of these standards, the DSB is seeking expressions of interest from participants who would like to contribute to the review. A representative from Treasury will also be attending the FAPI Working Group Atlantic call on 26 August to support engagement on these proposed changes. To register your interest, please contact
contact@dsb.gov.au.
Phillip Koumides raised the FAPI 2.0 Security Profile clause requiring that the authorization server:
shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [OIDD] and [RFC8414];
The CDR is currently built on OpenID Connect profiles and mandates the OIDD (/.well-known/openid-configuration) endpoint only. Phillip's question: if RFC 8414 metadata discovery is not also mandated, is the ecosystem still FAPI 2.0 compliant, or are both required?
Joseph Heenan gave the historical intent: the clause was written so that an OpenID Connect deployment would publish at the OpenID Connect well-known location, while a plain OAuth deployment using FAPI 2.0 would use the OAuth-mandated mechanism. In practice most deployments publish in both places. He was not confident about the strict reading of the text, but was clear that a non-OpenID-Connect deployment publishing only at the RFC 8414 location would unarguably be correct.
Nat Sakimura observed that the clause as written reads as "OIDD and RFC 8414", not "and/or".
Filip Skokan raised the interoperability consequence rather than the compliance question. Both documents point at the same registry and should always return the same content. Clients that fetch both concurrently and use whichever responds first will otherwise hit race conditions: two instances of the same client on different machines can end up with different discovery results.
His concrete example: an IdP whose RFC 8414 metadata omits what it regards as OpenID Connect-specific metadata — the userinfo_endpoint is present in the OpenID Connect document but absent from the RFC 8414 document. A client that races the two and later tries to call UserInfo will fail or succeed depending on which document won. This does not reliably reproduce in development or staging; it surfaces sporadically and looks like a flake. Filip believed there is an errata for OpenID Connect Discovery touching on this. (Editorial note: The most current the errata set 2 does not look like it does. )
Nat and Filip agreed this is not primarily a security issue — as Filip noted, the discovery document is still trusted and issuer confirmation is still required — but a troubleshooting problem. Filip described changing his own client implementations as a result: he no longer races the two endpoints, instead fetching the OpenID Connect document first and falling back to RFC 8414, or requiring the deployer to state which discovery policy to follow. The discovery algorithm also differs between the two specifications, which compounds the problem.
Filip confirmed he was not asserting that both endpoints must be present — only that where both are present, they must return consistent results. Dima Postnikov added the context that the CDR is a closed ecosystem in which every participant uses OpenID Connect.
Joseph described current OIDF conformance test behaviour: with OpenID Connect enabled, the tests retrieve only /.well-known/openid-configuration. Given the consequences of divergence, he suggested the tests could additionally warn when both endpoints exist with differing content — but would want a working group statement endorsing that first. Filip noted he is aware of deployments close to home that do not keep the two consistent.
Dima argued for cleaning up the specified behaviour rather than leaving it implicit: implementers do not always build clients strictly to the spec they have read, and someone downloading off-the-shelf client software may inherit exactly the race condition described. Unless it is spelled out and conformance tested, it will keep recurring. Nat agreed but noted that an errata or minor revision could not be turned around quickly, making the conformance-test warning the practical short-term step. A future revision (e.g. FAPI 2.1) was mentioned as the longer-term vehicle.
Outcomes:
- Joseph Heenan opened issue #862 on the "and" wording around discovery in the FAPI 2.0 Security Profile. He noted that, having looked at the text again, he is no longer confident the conformance suite interprets it correctly, so the wording needs to be pinned down before anything else follows.
- Joseph Heenan opened issue #863 covering the suggested additional conformance test for discovery consistency.
- Dima's recommendation for the CDR specifically: given a closed OpenID Connect-only ecosystem, mandate that clients use the OIDD endpoint outright. Servers may still publish both.
- Phillip indicated the DSB is comfortable proceeding with OpenID Connect Discovery for now, and will consider mandating an OAuth discovery endpoint if it proves to be required — noting it means additional implementation work for authorization server operators even though the metadata itself would be identical.
Nat Sakimura took this item, as Dima Postnikov was driving. Of the four open PRs, Nat had already merged two. The remaining two, both opened by Joseph Heenan, are cleanup arising from the Bitbucket-to-GitHub migration and were put to the group for approval:
| PR | Subject |
|---|---|
| #860 | Cleanup of leftover Bitbucket redirects |
| #855 | Cleanup of Bitbucket pipelines configuration |
Issue #857, opened by Joseph Heenan, concerns claim-name consistency in Grant Management. The normative text defines a last_updated field, while the example uses last_updated_at. Joseph noted that the other timestamp claims all carry the _at suffix, so last_updated_at may well have been the intent — but one or the other has to be corrected and he did not want to pick unilaterally. Filip Skokan suggested in chat adding the _at.
Dima Postnikov agreed to look at it. Nat assigned the issue to him and noted the broader motivation: the working group intends to finish Grant Management because ecosystems are now starting to use it. Dima added that implementer feedback of exactly this kind is what he wants to see.
Christopher Robbertse reported no change since the previous discussion. His group expects to meet again in September, after which he should have more to show. The item will be revisited then. -- Related: issue #648
Nat Sakimura noted he has circulated an intent to progress the FAPI 1.0 private_key_jwt-related work on 2026-09-09, referencing issue #848. He asked that Peter Stanley be connected on it.
Peter Stanley confirmed he was on the call — he had seen Nat's email that morning — and that he expects to attend the 2026-09-09 session and be up to speed for it. He noted he has been unable to attend as often as he would like due to a work project.
Issue #849 was revisited, having last been discussed two weeks earlier; Nat noted the AI space moves fast enough to warrant frequent refreshes.
George Fletcher had no updates of his own but reported that Ralph Bragg had described work in a separate meeting that appeared to overlap with this issue, and suggested pointing him at the issue for input. Dima Postnikov volunteered to follow up with Ralph.
Dima framed the underlying question: there is broad agreement that a FAPI flavour of OAuth is a good fit for system-to-system communication in the agentic space, so the real question is whether the working group needs to do something proactively about it, or whether this is closer to an observational item — tracking whether anyone is actually using it. He suggested it may belong as a standing item rather than an issue. Nat assigned issue #849 to Dima for the time being, agreeing it is a general question that other work can stem from.
Joseph Heenan asked whether next week's call had been cancelled for the Global Digital Collaboration Conference. Nat confirmed he will be at GDC in Geneva, and also occupied that week with ISO/IEC JTC 1/SC 44 (privacy by design for consumer goods and services) plenary as the head of delegate of the Japanese delegation, so he cannot host. Dima Postnikov will also be at GDC, and Dave Tonge is on holiday.
Decision: the 2026-09-02 Atlantic call is cancelled. The working group reconvenes on 2026-09-09.
| # | Action | Owner | Due / Status |
|---|---|---|---|
| 1 | Add Finance of Tomorrow (Rio, 2026-11-17/18) to the OIDF calendars | Mike Leszcz | Shortly after this call |
| 2 | Address the February 2027 conflict between the OIDF Global Conference (London) and the FIDO plenary (Paris); announce resolution | Mike Leszcz / OIDF marketing | Open |
| 3 | Report back on LATAM partner meetings adjacent to Finance of Tomorrow once plans are confirmed | Mike Leszcz | Next WG call |
| 4 | Vote on the two open Implementer's Draft polls | OIDF members | 2026-09-04 and 2026-09-07 |
| 5 | Circulate the DSB expression-of-interest notice to the FAPI mailing list | Phillip Koumides / Dima Postnikov | Open |
| 6 | Review and agree the intended meaning of the discovery metadata wording (issue #862) | Joseph Heenan / WG | Open |
| 7 | Decide whether to add a conformance-test warning for inconsistent discovery documents (issue #863) | Joseph Heenan / WG | Needs WG endorsement |
| 8 | Review and approve PRs #860 and #855 | WG members | Open |
| 9 | Determine last_updated vs last_updated_at in Grant Management (issue #857) |
Dima Postnikov | Assigned |
| 10 | Report OpenAPI-ready progress after the September meeting | Christopher Robbertse | Next update, September |
| 11 | Attend and prepare for the FAPI 1.0 private_key_jwt session |
Peter Stanley | 2026-09-09 |
| 12 | Reach out to Ralph Bragg regarding overlapping agentic AI work and point him at issue #849 | Dima Postnikov | Assigned |
| Item | Link |
|---|---|
| PR #860 — Bitbucket redirect cleanup | https://github.com/openid/fapi/pull/860 |
| PR #855 — Bitbucket pipelines cleanup | https://github.com/openid/fapi/pull/855 |
| Issue #648 — Define requirements for OpenAPI FAPI securityScheme type | hhttps://github.com/openid/fapi/issues/648 |
Issue #857 — last_updated vs last_updated_at
|
https://github.com/openid/fapi/issues/857 |
| Issue #862 — discovery metadata "and" wording | https://github.com/openid/fapi/issues/862 |
| Issue #863 — additional conformance test for discovery | https://github.com/openid/fapi/issues/863 |
Issue #848 — FAPI 1.0 private_key_jwt
|
https://github.com/openid/fapi/issues/848 |
| Issue #849 — FAPI 2.0 in agentic AI flows | https://github.com/openid/fapi/issues/849 |
| Notice of vote — two OpenID Federation extensions | https://openid.net/notice-of-vote-to-approve-proposed-implementers-drafts-of-two-openid-federation-extensions/ |
| Notice of vote — OpenID Connect Key Binding | https://openid.net/notice-of-vote-for-proposed-implementers-draft-of-openid-connect-key-binding/ |
| OIDF seeks Technical Director | https://openid.net/openid-foundation-seeks-technical-director/ |
| 2027 OIDF Global Conference | https://openid.net/conference/ |
| DSB expression of interest | contact@dsb.gov.au |