Repository navigation
FAPI_Meeting_Notes_2026 08 12_Atlantic
Date: 2026-08-12
Time: 14:00 UTC
Location: Zoom
Chair: Nat Sakimura (NAT.Consulting / Authlete)
Duration: 14:00–15:03 UTC
Attendance was taken by self-identification in the Zoom chat.
| Participant | Affiliation | Notes |
|---|---|---|
| Nat Sakimura | NAT.Consulting / Authlete | Chair; ran the meeting |
| Gail Hodges | OpenID Foundation (OIDF) | Deputising for Mike Leszcz; joined shortly after start |
| Joseph Heenan | OIDF / Authlete | |
| George Fletcher | Practical Identity | |
| Kosuke Koiwai | KDDI | |
| Christopher Robbertse | Open Banking Limited (OBL) | Dropped at approx. 15:00 UTC |
| Bjorn Hjelm | Yubico | Contributed via chat |
| Hideki Ikeda | Authlete | |
| Matthew Murphy | Mastercard | Joined under the auto-generated Zoom name e090350; identified himself in chat |
Regrets: Mike Leszcz (OIDF) — on leave; sent word that there were no substantial events updates.
The chair opened with the standard OpenID Foundation Note Well, covering the antitrust policy and the contribution agreement requirements, noting that all of these are published at openid.net/policies.
The proposed agenda was posted to chat:
- Roll Call (Nat)
- Adoption of Agenda (Nat)
- Events (Gail)
- External Orgs & Liaisons (Gail)
- PRs (Nat)
- Issues (Nat)
- AOB (Nat)
Gail Hodges asked to bring several strategic items to the meeting in place of the usual events and external-orgs reports. The chair agreed to take them together under item 7 (AOB). The agenda was adopted as amended.
Mike Leszcz was on leave and reported no substantial updates. The chair noted the timing coincides with the northern-hemisphere summer break and with a holiday week in Japan.
- OpenID Summit Tokyo (Special Version) — coming up in approximately two weeks.
- Global Digital Collaboration (GDC), 1–3 September 2026 — Gail Hodges reported that the event is filling up quickly. Tickets are free but require approval, and OIDF still has a small allocation of places remaining. Sign-up: https://globaldigitalcollaboration.org
No other events were raised.
No ecosystem updates were tabled under this item; the substantive liaison discussion was deferred to AOB item E (see §7.5). Bjorn Hjelm posted the ISO–OIDF liaison record for reference: https://www.iso.org/organization/5149604.html
No open pull requests. Item skipped.
The chair noted that triage of the issue backlog is still in progress and invited the group to nominate issues. With none volunteered, the chair worked from the newest issues downwards.
https://github.com/openid/fapi/issues/851
The issue concerns the case where an authorization server publishes keys whose kty or alg a client does not recognise — most obviously the post-quantum case — and the requirement that clients ignore those entries rather than fail. Discussion on the issue appeared to have converged, and the chair had asked on GitHub whether the certification team needed anything further from the working group.
Joseph Heenan set out his current thinking on the conformance-suite side:
- Rather than adding a separate test for unknown keys, the invalid or unrecognised keys will be placed into the JWKS that every test runs against.
- A separate test would actually reduce confidence that the right behaviour is occurring, because the JWKS URI may have been cached by the time the dedicated test runs.
- Always running with unrecognised keys present, and requiring the client to keep working, is both a stronger signal and a simpler change — so it should be possible to roll out fairly quickly.
The chair asked whether the unrecognised keys would be randomised, so that a candidate could not hard-code a one-off workaround to pass certification. Joseph replied that:
- Some randomness can certainly be included.
- However, fixed keys have the advantage that they can be named in a way that makes the intent obvious to implementers — for example one entry with an invalid
kty, and one with a knownktybut an invalidalg, or something that looks like a post-quantum key but is not yet a real one. - The main problem in practice is implementers not realising they are expected to be tolerant, rather than deliberate cheating: the effort required to game the test is roughly the same as implementing the behaviour correctly.
The chair drew a distinction that recurred throughout the meeting: being able to ignore an unknown key and being able to use a new algorithm are two separate capabilities. This issue is about the former only. Joseph confirmed this, adding that ignoring unknown keys is precisely what gives authorization servers the freedom to roll out post-quantum keys first, with clients migrating to using those keys over a longer timescale.
Open question raised by Joseph: whether the specification language should be strengthened from SHOULD to MUST. The group is on slightly awkward ground enforcing a SHOULD in certification, although — as the chair had noted on the issue — implementers need a good reason to deviate from a SHOULD, and it is hard to see what a good reason would be here. No decision was taken; discussion continues on the issue.
Outcome: Joseph to proceed with the "bad keys in every JWKS" approach. No further written output required from the working group at this stage, beyond resolving the SHOULD/MUST question.
https://github.com/openid/fapi/issues/736
Joseph Heenan reported that the issue has been discussed several times and that there is not a great deal to do at present:
- Conformance-suite changes were made for TLS 1.3, which turned out not to be supported in some places; it is now supported throughout, and a warning is raised where TLS 1.3 is not in use, to nudge implementers towards upgrading their stacks.
- Beyond that, the working group is dependent on the IETF TLS working group concluding its discussions and on the JOSE working group progressing its post-quantum algorithms.
The issue also carries the BCP 195 and IETF JOSE work items.
Outcome: The chair will record on the issue that the working group remains in observation mode on this item.
https://github.com/openid/fapi/issues/849
Raised by George Fletcher approximately a month ago and last discussed roughly two weeks prior to this call. The most recent comment on the issue suggested a blog post explaining how the FAPI 2.0 Client Credentials profile can be used in this context.
George clarified the original intent: it was largely a question from him as to whether anyone is known to be protecting MCP endpoints, servers or gateways with FAPI, as opposed to plain OAuth 2.0. He noted that Ralph Bragg (Raidiam) had been speaking recently about deployments that may include MCP servers, so there may already be some use of FAPI in that context — but he could not confirm it.
The chair noted his intention to re-read the MCP specification, given that the new version published on 2025-07-25 is much closer to a standard web model.
Joseph Heenan suggested drawing Aaron Parecki and Pieter Kasselman into the conversation, as they have been doing adjacent work. He understood from Pieter that some of the MCP work has been looking at payment profiles, that those were looking at mandating DPoP, and that there are now implementations around that. Both would also have useful ideas on how to influence the relevant audiences, having been fairly successful at doing so.
Gail Hodges supported that suggestion and added several threads:
- She seconded the point about Ralph Bragg: he would likely update the issue if it were drawn to his attention, and he has public links to production implementations relevant to this topic — possibly supporting one or two major clients — which he has shared in other forums.
- FDX has active conversations on this topic, including a published paper and a webinar. FDX had sought OIDF feedback on the use cases they were exploring, but OIDF capacity was tight and Gail was on holiday, so she was unable to speak on the webinar as planned. Łukasz Jaromin is following the conversation actively, as is Ray Voss (Chase), a co-chair of the FDX cybersecurity working group, who is looking to start contributing to the Foundation.
- Open Finance Brazil — Elcio Calefi has mentioned that they have been piloting and exploring agentic AI use cases; another important partner for this work.
The chair asked whether the FDX material was public and could be posted to the issue, noting that FDX material is not usually open. Gail confirmed the recap link opened for her and expected the webinar recording link to open as well. She further suggested that the working group could review the FDX findings and related reports and feed comments back — either as an FDX member (which OIDF is) or informally via FDX staff, with whom OIDF is in regular contact. Opportunities that emerge in the U.S. context are likely to be relevant to other open finance ecosystems, to the technical standards, and to other open data sectors.
On the mechanism for feeding back, Gail described her own role as an informal liaison facilitator, and identified three channels:
- Łukasz Jaromin (Raidiam) — active in both this working group and FDX, acting as a day-to-day informal liaison.
- Ray Voss — FDX working group co-chair, engaged with both communities.
- OIDF staff — Gail, with support from Joseph Heenan and Mike Leszcz.
Outcome: For technical feedback, the group agreed the most convenient route is to leverage Łukasz Jaromin to convey the working group's message. Gail agreed this was a good choice.
https://github.com/openid/fapi/issues/848
Titled, in substance, "how do we handle FAPI private_key_jwt changes in the certification tools". The chair concluded that a dedicated call is needed on this topic so that Peter Stanley can join, and undertook to schedule one. The issue will be taken up again on the call in two weeks' time; in the meantime, participants are asked to add any further suggestions directly to the issue.
Gail Hodges brought six items, lettered A–F in the chat. Items A–E were covered; item F was deferred.
Gail framed three (later four) questions to the working group, in the context of a coordinated OIDF-wide programme of work on PQC readiness with broad implications across FAPI, AB/Connect, OpenID for Verifiable Credentials and others. Feedback is being gathered ahead of the Strategic Task Force in mid-September, with any funding requirements going to the board meeting that follows.
- Housekeeping: does the working group have the issues or PRs open that are needed to address the changes or clarifications in the specs that will be valuable to implementers as they select crypto and deploy within FAPI-enabled ecosystems?
- Certification: are there requirements or asks of the certification team that would support those spec changes, so that OIDF has line of sight on them and can align issue numbers across both sides?
- Programme: note that OIDF intends to form a programme of work spanning working groups, staff and liaison deliverables, since the clarifications and certification support may take some time to complete, and appropriate staff support should be in place.
- Comms: are there any key messages relevant to this working group to share — potentially a series of blog posts, at least one of which might relate to FAPI?
The chair's framing of the problem separated three distinct concerns:
- Whether the FAPI specifications need to change. In his assessment the core specification does not, because crypto agility is built into FAPI — which is exactly what issue #851 is about.
- Whether the certification tests need to change to support post-quantum algorithms. This is a separate matter.
- Whether communications to the ecosystems are needed, to the effect that FAPI is quantum-ready. This is separate again.
Joseph Heenan's assessment on the technical detail:
- At the TLS level, progress depends on the IANA registry being updated to start recommending post-quantum algorithms; once that happens the conformance suite's lists of acceptable algorithms can be updated to include them.
-
Two specification changes are needed:
- Where FAPI 2.0 lists JOSE signing algorithms such as
ES256andPS256, one or two post-quantum algorithms will need to be added to that list. The conformance suite would then be updated to match. - The algorithm used for PKCE (
S256) is technically not considered post-quantum compliant. There is an IETF specification — Joseph was not certain whether it has been adopted — adding a new algorithm for PKCE. The working group would need to decide whether to adopt it and, if so, update the language that currently requiresS256as the code challenge method, so as to allow or require the algorithm that is considered post-quantum and meets the recent U.S. requirements. Conformance tests would follow the spec change.
- Where FAPI 2.0 lists JOSE signing algorithms such as
The chair asked whether FAPI 2.0 had already been changed to reference the IANA registry rather than carry hard-coded algorithms. Joseph believed the JOSE algorithm list is still hard-coded. The chair said he had just posted a new issue — possibly a duplicate — noting that the hard-coded algorithms need to be removed from FAPI 2.0, and that he believed this had been done for FAPI 1.0 but not FAPI 2.0.
Joseph corrected the record on two points:
- The hard-coded algorithms already removed were the TLS ones; the JOSE algorithms have not been tackled in either FAPI 1.0 or FAPI 2.0.
- Issue #844 (https://github.com/openid/fapi/issues/844) is a separate, also-needed item. It is only tangentially related to post-quantum: PKCE is probably still post-quantum safe, but CNSA 2.0 has disallowed the algorithm currently used in PKCE, which technically means PKCE cannot be used on those networks — and the reason for that prohibition is itself post-quantum related.
Joseph then created issue #852 (https://github.com/openid/fapi/issues/852) covering the JOSE algorithm lists in FAPI 1.0 and FAPI 2.0, and posted the link to chat. Gail confirmed she will track #844 and #852 in the list of post-quantum-related issues alongside #736 and #851.
Certification-side tracking. Gail asked whether there are public-facing issues in the certification team's GitLab that she could point Elcio Calefi towards. Joseph initially said no — nothing is tracked on the certification side because the working group has not made decisions yet — then corrected himself: there is, or should be, a certification-suite issue covering post-quantum readiness for ignoring unknown keys, and he will dig it out. Gail noted that #851 relates to the certification team ask on the working group side, so what remains is identifying the mirror item in GitLab.
Comms. Gail recalled that #851 carried a suggestion of public-facing comms, with Ralph Bragg having an action to help support that message, to give the community guidance on (for example) RPs that might fail if OPs make changes. Joseph noted that Raidiam published their report. Gail does not have the report and will obtain it from Ralph.
Open Finance Brazil. Gail reported a request from Elcio Calefi to understand OIDF's plans for this family of specifications and related items. As a board member he missed the task force where the discussion began; Gail has told him the timing is good, as the discussion continues at the September task force. His ask at this point is a staff-level conversation for clarity on direction — he shared the implications Open Finance Brazil sees, but has no specific asks of the working group at this time.
IETF point people. Gail asked who the working group's point person is for liaising with the relevant IETF working groups (JOSE, OAuth, or others), so staff can stay connected to their progress. The chair replied that the working group does not need a formal liaison and simply observes; many participants in the IETF JOSE work also participate in this group, so the group will naturally know when a draft becomes an RFC, and a monitoring job could be set up if desired. Asked whether the working group should tell the JOSE working group that timely completion would be valuable, the chair said no.
The chair added that once post-quantum JOSE algorithms exist, the group should get them onto its radar and consider adopting them — potentially in a FAPI 2.1 or similar revision. Joseph noted there are definitely drafts circulating but he was not aware of any having reached working group last call.
Gail flagged this as a notice item rather than a request. (She corrected herself in both the call and the chat: the direction is SAML → OpenID Connect, not the reverse.)
- The topic has been monitored for a long time, but it is probably time to explore a programme of work.
- The issue is becoming acute for existing SAML implementers, some of whom are likely to hit a wall — in part for post-quantum readiness reasons.
- Entire ecosystems, such as eduGAIN and GÉANT, comprising tens of thousands of entities, have the intent and direction to make the transition. Support is needed both for those who have confirmed and for implementers who have not yet started.
- The AB/Connect and IPSIE working groups are already exploring this and beginning to coordinate on recommendations or migration profiles, with possible staff support required for visibility.
Gail was not aware of specific requirements for OpenID Connect → FAPI migrations and invited the working group's view.
Outcome: The chair's view was that this comes for free with the AB/Connect working group's work, since FAPI simply references those specifications. No issue to be opened, and no implications for the certification team.
Gail asked the working group to surface any certification-team requirements — whether already shared or anticipated for 2027 — so the certification team has visibility ahead of the OIDF certification team staff meeting on 2026-09-04, where the programme of work will be coordinated. The working group is expected to meet once or twice before that date.
Outcome: The chair undertook to send the list of asks and to report back.
Gail reported that, in discussions with Canada, it emerged that neither this working group nor the Ecosystem Support Community Group has published any specific guidance recommending FAPI 2.0 relative to FAPI 1.0. OIDF has produced this kind of guidance in the past to support ecosystems such as Saudi Arabia. The community recommendation of FAPI 2.0 is implicit but has never been written down in a form the community can be pointed at.
This is a live problem for Canada, which is about to announce its standards body selection and has been drawing on Joseph's input and on what public material exists — particularly on why FAPI 2.0 is especially useful for ecosystems that are new and moving towards launch, or that have migration requirements. Gail asked for volunteers to support a recommendation and to produce a blog post quickly.
The chair recalled that, as of a discussion the previous Friday, Dima Postnikov had volunteered to produce a first draft — something short that could also be published on the working group page — but said he needed to double-check. Gail confirmed this matched her recollection: Dima had asked her not to go chasing a working group member, but she had not heard an explicit commitment from him as co-chair to take the lead on the draft.
On authorship and process, Gail asked whether it would be sufficient for Dima to write under his own name or on behalf of the co-chairs, or whether wider stakeholder input is needed. The chair's guidance: float one or two paragraphs to the working group, and if there is no objection, publish it on the working group page.
Outcome: Gail to take this away with Dima and seek the first draft.
The board passed the Foundation's first-ever liaison policy in April 2026. Implementation has been backlogged for Gail and Mike Leszcz, and will now begin. The first three priorities on Gail's list:
- FIDO — refreshing the MOU.
- ISO — clarifying the split between the relevant working groups and general housekeeping on the relationship. (See editorial flag below regarding the working group names.)
- FDX — no official liaison role or representative currently exists; establishing one is probably useful.
Gail invited the working group to identify any others, and noted that OIDF will return to the working group in the coming weeks, with the co-chairs consulted as part of the liaison committee.
The chair advised that, as far as ISO is concerned, the relevant bodies are ISO/IEC JTC 1/SC 17, ISO/IEC JTC 1/SC 27 and ISO/TC 68, and confirmed the FAPI Working Group has a relationship with them. Gail confirmed OIDF holds Category A liaison relationships in that space and will follow up with the chair offline to be clear on which relationships apply to the FAPI Working Group specifically, along with any other liaisons, MOUs or partner relationships.
Noted for awareness only and deferred to a future call, as the meeting was at time.
- A board subcommittee on Architecture in the Agentic Era has been formed, complementing the AI and Identity Management (AIIM) Community Group. The public discussions belong in the AIIM Community Group; the subcommittee's role is for the board to reflect on the programme of work that cuts across working groups and IETF, and to surface recommendations that working groups and community groups should take into account.
- If any of its insights bear on FAPI, they will be brought to this working group for consideration and comment.
- An interop event later this year, led by the AIIM Community Group, was mentioned in passing.
The chair closed the meeting at approximately 15:03 UTC, two minutes past the hour, with no further items raised from the floor.
| # | Action | Owner | Target / Status |
|---|---|---|---|
| 1 | Implement the conformance-suite change placing unrecognised keys (invalid kty; known kty with invalid alg; a plausible-looking non-real post-quantum key) into the JWKS used by all tests, rather than adding a separate test |
Joseph Heenan | In progress; expected to roll out quickly |
| 2 | Resolve whether the tolerance requirement in #851 should be raised from SHOULD to MUST | Working group, via issue #851 | Open |
| 3 | Record on issue #736 that the working group remains in observation mode pending IETF TLS and JOSE post-quantum outcomes | Nat Sakimura | Open |
| 4 | Draw issue #849 to Ralph Bragg's attention and invite him to comment with public links to production MCP/FAPI deployments | Gail Hodges / Nat Sakimura | Open |
| 5 | Invite Aaron Parecki and Pieter Kasselman into the MCP/FAPI conversation (DPoP, MCP payment profiles) | Joseph Heenan / Nat Sakimura | Open |
| 6 | Post the FDX webinar and recap links to issue #849 (confirmed publicly accessible) | Nat Sakimura | Open |
| 7 | Route working group technical feedback to FDX via Łukasz Jaromin as informal liaison | Nat Sakimura | Agreed |
| 8 | Schedule a dedicated call on issue #848 (private_key_jwt and certification tooling), ensuring Peter can attend; revisit on the call in two weeks |
Nat Sakimura | Open |
| 9 | Confirm whether the chair's newly filed issue on hard-coded FAPI 2.0 algorithms duplicates #852, and close or merge as appropriate | Nat Sakimura / Joseph Heenan | Open |
| 10 | Track #736, #844, #851 and #852 as the FAPI contribution to the OIDF-wide PQC readiness programme | Gail Hodges | Ongoing |
| 11 | Locate and share the certification-suite (GitLab) issue mirroring #851 on ignoring unknown keys | Joseph Heenan | Open |
| 12 | Obtain Raidiam's published report from Ralph Bragg | Gail Hodges | Open |
| 13 | Send the list of FAPI WG certification-team requirements for 2H 2026 into 2027, ahead of the 2026-09-04 staff meeting | Nat Sakimura | Before 2026-09-04 |
| 14 | Confirm with Dima Postnikov that he will draft the FAPI 2.0 recommendation blog post; circulate one or two paragraphs to the working group, and publish on the WG page absent objection | Gail Hodges / Nat Sakimura | ASAP — Canada announcement imminent |
| 15 | Follow up offline on the FAPI-specific ISO relationships (JTC 1/SC 17, JTC 1/SC 27, TC 68) and any other liaisons or MOUs | Gail Hodges / Nat Sakimura | Open |
| 16 | Carry the Architecture in the Agentic Era subcommittee item (AOB F) to a future call | Gail Hodges | Deferred |
| Reference | Link |
|---|---|
| Issue #736 — Post-quantum readiness / TLS 1.3 / BCP 195 / IETF JOSE | https://github.com/openid/fapi/issues/736 |
| Issue #844 — PKCE algorithm and CNSA 2.0 | https://github.com/openid/fapi/issues/844 |
Issue #848 — FAPI private_key_jwt changes in certification tools |
https://github.com/openid/fapi/issues/848 |
| Issue #849 — FAPI 2.0 and MCP | https://github.com/openid/fapi/issues/849 |
| Issue #851 — Tolerating unknown key types in the JWKS | https://github.com/openid/fapi/issues/851 |
| Issue #852 — Hard-coded JOSE algorithm lists in FAPI 1.0 and FAPI 2.0 (created during this call) | https://github.com/openid/fapi/issues/852 |
| Global Digital Collaboration, 2026-09-01 to 2026-09-03 — registration | https://globaldigitalcollaboration.org |
| ISO–OIDF liaison record (posted by Bjorn Hjelm) | https://www.iso.org/organization/5149604.html |
| FDX webinar on Agentic AI & Open Finance (link shared in chat) | HubSpot tracking link — see chat log, 00:24:34 |
| FDX recap of the meeting (link shared in chat) | HubSpot tracking link — see chat log, 00:24:49 |
Note on the FDX links: both were posted as HubSpot click-tracking URLs tied to Gail's mailing. Before publishing these notes to the wiki or the mailing list, the underlying canonical FDX URLs should be substituted.
- Ray Voss (Chase). Name heard only in audio; spelling unverified. Described as co-chair of an FDX working group (cybersecurity) and as looking to begin contributing to the Foundation.
- ISO working group names under AOB E. Gail referred to clarity "between the DCH and DCP working groups". DCP is presumably the OIDF Digital Credentials Protocols working group; "DCH" is not a name I can resolve. Please supply the correct pair.
- IETF PKCE post-quantum draft. Joseph referred to an IETF specification adding a new algorithm for PKCE but was unsure whether it has been adopted. A draft reference would be worth adding to #844.