Repository navigation
FAPI_Meeting_Notes_2026 07 29_Atlantic
Nat Sakimura edited this page Aug 6, 2026
·
8 revisions
Date: 2026-07-29
Time: 14:00 UTC
Location: Zoom
Chair: Dima Postnikov
Co-Chair: Dave Tonge (Moneyhub), Nat Sakimura (NAT.Consulting / Authlete) — both not present on this call
| Name | Affiliation | Notes |
|---|---|---|
| Dima Postnikov | — | Chair |
| Peter Stanley | Open Banking Limited (OBL) | Present for the first 30 minutes only |
| Kosuke Koiwai | KDDI | |
| Joseph Heenan | OIDF / Authlete | |
| Phillip Koumides | Australian Treasury | Led MTLS endpoint aliases discussion (CDR) |
| Filip Skokan | Okta | |
| Alfred Ho | Australian Treasury | |
| Robert Gallagher | Mastercard | |
| Ashmita Chakraborty | Individual contributor | Left the call early (~00:36) |
| Hideki Ikeda | Authlete | |
| Brian Campbell | Ping Identity | |
| Imran Ulghar | Open Banking Limited (OBL) | |
| George Fletcher | Practical Identity |
Apologies: Mike Leszcz (OIDF), Nat Sakimura (NAT.Consulting), Dave Tonge (MoneyHub)
The standard agenda was posted in chat and via the distribution list. Two additional items were added at the top of the call:
1. Certification update (Joseph Heenan)
2. A question from Australian Treasury on the use of MTLS endpoint aliases (Phillip Koumides)
- Global Digital Collaboration — an event taking place in early September in Geneva; may or may not be of interest to the group.
- OpenID Foundation Conference — planned for London, tentatively 2–4 February, with further announcement details still to be published. The event will focus on ecosystems, including open banking ecosystems.
- No FAPI Working Group-specific items were reported as having come up at IETF this period.
- Filip Skokan reported he had spoken briefly with Justin regarding the JARM registrations that are still outstanding in IANA; he was asked to send a reminder of the unprocessed registration request.
- Joseph Heenan flagged a relevant spec development: Justin recently presented a reactivated draft at OAuth on an OAuth profile of HTTP message signing. There is likely overlap with the FAPI message-signing draft, and this activity may finally generate renewed interest in that FAPI draft. Noted as one to watch rather than an immediate action.
- FAPI2 machine-to-machine certification: launched roughly a month or more ago, covering client-credentials-based FAPI 2 flows (i.e., not the authorization code flow). A couple of certifications have already been completed and published on the OIDF website.
- OpenID for Verifiable Credential Issuance (OID4VCI) certification: in the process of launching for the "high" assurance profile, which mandates use of the FAPI2 security profile. This is understood to be the first time another OpenID Foundation working group has adopted a FAPI specification — meaning any implementer certifying for VCI will also be FAPI-compliant.
-
Post-quantum readiness / unknown key type handling: Joseph raised a real-world interoperability problem: when an authorization server publishes a new (e.g., post-quantum) key type in its JWKS that an OAuth client does not recognize, a significant proportion of existing clients abort processing entirely rather than continuing with a key type they do support. RFC 7517 states unknown key types "should" be ignored, but this is not being followed consistently in practice.
- Joseph identified the issue independently roughly a month or two ago; Ralph (external) separately identified the same issue recently and posted about it on LinkedIn.
- Joseph opened a Connect Working Group issue proposing a new certification test that includes unknown key types in the JWKS to confirm clients still succeed (link shared in chat:
openid/connect#2147). - Filip Skokan suggested an equivalent server-side/DCR test may also make sense where dynamic client registration is enabled; Joseph agreed this is worth adding to the Connect issue, noting FAPI currently lacks a DCR test outside of the Brazil profile, which is constrained by available directory keys.
- Discussion on whether this should be a warning or a hard failure: Joseph noted that because affected clients abort entirely, a "warning" outcome isn't practically achievable from the test's perspective — it would need to be implemented as a failure.
- The group discussed whether this is better addressed upstream in RFC 7517 rather than overridden within FAPI. Peter Stanley (OBL) suggested the root cause (a "should" that isn't being honoured) is arguably a lower-stack problem, though he wouldn't oppose a FAPI-level override. Filip Skokan noted the underlying issue largely stems from no new JWK key type having been added in roughly 8–10 years (since the Edwards-curve/OKP key type), and that non-compliant clients are simply not following the existing "should." His view: this is not a spec problem, and implementers should follow the RFC unless they have good reason not to.
- Imran Ulghar (OBL) asked whether compensating controls are being considered, noting that from a real-world use-case perspective the current client behaviour is not acceptable.
- Peter Stanley (OBL) clarified that this issue does not directly affect the UK Open Banking ecosystem via conformance testing, since the UK does not use the client conformance tests. However, real risk remains: OBL hosts the JWKS for the majority of UK ecosystem participants and does not currently issue post-quantum-compatible certificates, and at least one bank self-hosts its own JWKS, introducing risk. OBL is planning a session with the CMA9 banks to walk through this, with Ralph preparing slides and Peter facilitating together with Imran.
-
Outcome: the group agreed a FAPI repository issue should be opened for the working group to weigh in on whether/how to elevate this to a failing test. Joseph confirmed during the call that he had opened the issue and shared the link in chat (
openid/fapi#851). Members were asked to contribute their views on the ticket.
Phillip Koumides (Australian Treasury) raised a question as the Consumer Data Right (CDR) standards team works to align its standards with FAPI 2. Context:
- CDR has completed a first round of industry consultation, during which feedback highlighted confusion around one of CDR's existing provisions relating to
mtls_endpoint_aliases. - Phillip's proposed resolution is to repeat the FAPI 2.0 Security Profile wording verbatim (previously only paraphrased as bullet points rather than the numbered clauses used in FAPI 2.0), and to add an explanatory note clarifying that Data Holders only need to adopt
mtls_endpoint_aliasesif they need to expose both MTLS and non-MTLS variants of the same authorization server endpoints — a scenario mostly relevant to non-CDR use cases where an AS may want to reuse the same issuer URL/AS instance to also serve non-MTLS endpoints. In practice, observation of ecosystem metadata suggests some Data Holders are duplicating the same MTLS endpoint in both the root-level field andmtls_endpoint_aliases, which is not the field's intended use. - The proposed wording draft was shared by Dima Postnikov in chat, referencing FAPI 2.0 Security Profile §5.2.2.1.
Discussion:
- Filip Skokan felt the note makes sense but is largely inconsequential in practice: for an AS implementer, echoing the same endpoint in both places changes nothing and doesn't break anything; the more relevant audience is clients, which need to be able to handle
mtls_endpoint_aliasesbeing present at all, since ASs are permitted to use it. - Joseph Heenan confirmed this is consistent with the conformance test suite: endpoints must always be listed at the root level (so an AS can't rely solely on the MTLS-alias field), duplicating the same endpoint in both places is not disallowed (just redundant), listing the authorization endpoint under MTLS aliases is flagged (likely as a warning, since the authorization endpoint is never accessed over MTLS), and any optional endpoint that appears under MTLS aliases must also appear at the root/base level.
- Phillip confirmed this resolved his open question and thanked the group.
Outcome: No changes to the FAPI specification are needed; Phillip's proposed CDR standard wording and explanatory note were confirmed to be consistent with FAPI 2.0 and the conformance test suite.
Dave Tonge was not present; Dima Postnikov covered this item. One open PR was reviewed on the call: an update to the FAPI Working Group README file, with minor adjustments contributed by Nat (github.com/openid/fapi/pull/850). Dima had reviewed it and considered the changes reasonable and uncomplicated. All members were asked to review and provide approval on GitHub.
Dima Postnikov noted the working group's repository has now fully migrated to GitHub. A large backlog of issues carried over from the Bitbucket migration remains to be triaged and cleaned up before being brought to the working group for discussion; no volunteers came forward to work through the backlog on this call.
Two items were discussed:
-
Recent issue from Joseph Heenan (the unknown JWK key type / post-quantum handling issue covered under Item 4 above —
openid/fapi#851) — members were asked to provide feedback on the ticket. -
George Fletcher's issue — "Is FAPI 2.0 being used in Agentic AI flows (MCP?)" (
openid/fapi#849): George clarified this is a tracking/discussion issue rather than a defect report — essentially asking whether there is value in leveraging FAPI to protect MCP (Model Context Protocol) API endpoints or other agentic flows where tighter API security and sender-constraining (to verify the calling client) may be desirable. George raised it after the working group's earlier consensus was to "file an issue" once the topic first came up.- Joseph Heenan observed that, from what he's seen, the MCP community appears to be reinventing FAPI incrementally, despite guidance from some quarters that they should simply adopt FAPI outright. He noted MCP has recently decided not to mandate DPoP (sender-constrained tokens) for payment use cases, and is looking at moving beyond client secrets for authentication. He compared this to a broader, recurring pattern (not unique to AI/agentic use cases): the OpenID Foundation's own IPSE working group had similarly reinvented parts of FAPI2 (without PAR) rather than adopting it directly.
- Dima Postnikov offered a personal view that this pattern is common across several OpenID Foundation specs: handing the full FAPI2 (or FAPI1) specification to an unfamiliar audience is often perceived as too much, and it can be hard for newcomers to work out which parts are actually relevant to their use case — similar to handing someone the full OpenID Federation spec. He suggested the newly-launched conformance testing profile helps in this scenario, and floated the idea of a blog post to help make the relevant subset of FAPI more accessible; volunteers were invited to think about this.
- No update on OpenAPI-related discussion was available, as no one on the call had direct involvement; an update is expected to be available at a future Pacific call.
No further items were raised. The chair thanked attendees and closed the call.
| # | Action | Owner | Status / Notes |
|---|---|---|---|
| 1 | Contribute views on FAPI issue re: unknown JWK key type handling / post-quantum readiness | All WG members | Issue: openid/fapi#851
|
| 2 | Add server-side/DCR test consideration to the Connect issue on unknown key types | Joseph Heenan | Issue: openid/connect#2147
|
| 3 | Send reminder on outstanding JARM registrations to IANA | Filip Skokan (via Justin) | |
| 4 | Prepare and deliver post-quantum JWKS risk briefing to CMA9 banks | Peter Stanley / Imran Ulghar (OBL), slides from Ralph | UK Open Banking ecosystem |
| 5 | Finalize CDR standard wording on mtls_endpoint_aliases per FAPI 2.0 §5.2.2.1 |
Phillip Koumides (Australian Treasury) | WG confirmed wording is consistent with spec |
| 6 | Review and approve README PR | All WG members | Single open PR on GitHub |
| 7 | Triage/clean up backlog of GitHub issues migrated from Bitbucket | WG chairs / volunteers | Ongoing |
| 8 | Consider drafting a blog post on FAPI applicability to MCP/agentic use cases | Volunteer needed | Raised by Dima Postnikov |
| Reference | Link / Note |
|---|---|
| Connect WG issue — unknown JWK key type handling | github.com/openid/connect/issues/2147 |
| FAPI issue — post-quantum / unknown key type test | github.com/openid/fapi/issues/851 |
| FAPI issue — "Is FAPI 2.0 being used in Agentic AI flows (MCP?)" | github.com/openid/fapi/issues/849 |
| FAPI PR — README update | github.com/openid/fapi/pull/850 |
CDR mtls_endpoint_aliases draft wording |
Shared in chat by Dima Postnikov (references FAPI 2.0 Security Profile §5.2.2.1) |
| Global Digital Collaboration | Geneva, early September 2026 |
| OpenID Foundation Conference | London, tentatively 2–4 February; details pending |