-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2026 06 10_Atlantic
Nat Sakimura edited this page Jul 10, 2026
·
1 revision
Date: 2026-06-10 14:00 UTC Location: Zoom
| Name | Organisation |
|---|---|
| Dima Postnikov (Co-Chair ) | Scytáles |
| Peter Stanley | OBL (Open Banking Limited) |
| Kosuke Koiwai | KDDI |
| Joseph Heenan | OIDF & Authlete |
| Matthew Murphy | Mastercard |
| George Fletcher | Practical identity |
| Robert Gallagher | Mastercard |
The chair displayed the OpenID Foundation IPR policy ("Note Well") on screen while waiting for attendees to join, per standard practice. Attendees were asked to type their names in chat to record participation.
The standing agenda was adopted as posted in chat:
- Roll Call
- Adoption of Agenda
- Events
- External Orgs & Liaisons
- PRs
- Issues
- AOB
No additional topics were proposed for the call.
- Identiverse — taking place the following week. George Fletcher confirmed he would attend. Joseph Heenan will not attend, as he will instead be in Brazil for a government digital credentials workshop, which required him to withdraw his Identiverse presentation.
- DICE (described as the European edition of Identity Week / IW) — also taking place the following week. No attendees from the working group indicated they would be attending.
- The chair noted the event calendar is expected to be quiet for the remainder of the (Northern Hemisphere) summer.
No other ecosystem updates were reported, in part because Mike Leszcz and Nat Sakimura were both absent.
- Open Banking ecosystem — an unnamed open banking ecosystem has picked up Grant Management and is incorporating it into specifications being rolled out. Questions are being raised about Grant Management as a result, which may lead to clarifications being issued against the spec.
- India / Sahamati-type ecosystem — a call was held the prior week with the Ecosystem Community Group together with parties in India who are developing a FAPI 2 profile oriented toward identity use cases rather than open banking/open data use cases. This surfaced a broader observation that different ecosystems have meaningfully different configurations and concerns. A question was raised as to whether such a profile could be brought into this working group directly, or would need to be maintained separately (as most other ecosystem profiles are). The chair indicated he would like to discuss this with Nat Sakimura and that the topic will likely return on a future call.
Only one open PR was reported:
- PR #529 — relates to FAPI CIBA. The PR has been sitting Joe for review.
- Joseph Heenan reported he is not fully across the migration status, but understands that Domingos recently migrated the Connect repository, encountered an issue, and had to redo it. FAPI is expected to be migrated next, though the exact schedule is unclear — possibly pending sign-off from the chairs.
- It was noted that open PRs are generally expected to be closed prior to migration where possible; Joseph indicated the open CIBA PR may need to be manually reopened on GitHub after migration completes.
- The chair reminded the group that Bitbucket issue functionality is being decommissioned in mid-August, prompting the migration to GitHub. The team is trying to preserve as much history as possible while being pragmatic about what is feasible to carry over.
-
George Fletcher flagged two migration-tooling limitations:
- The original poster/author of a migrated issue is not preserved — all migrated content is attributed to the migration tool itself, with the original author's name appearing only as plain text in a comment header (not as a tagged GitHub user). Notifications will therefore not reach original posters.
- Issues currently assigned to specific individuals will need to be manually reassigned after migration, since assignment data is not carried over automatically.
- The chair noted the FAPI repository currently has 72 open issues, many dating to 2020–2022, with relatively few recent ones. A significant number may not warrant migration at all and may instead be candidates for closure or triage before the move.
The group worked through the open issues backlog. Several long-standing issues were reviewed without resolution; the chair noted the exercise felt "like an archaeology exhibition" given the age of many items.
| Issue | Topic | Discussion / Outcome |
|---|---|---|
| #706 | Signature-Req and Signature-Input-Req message-signing extension | Discussed but not resolved on this call. Chair suggested checking with Justin (Richer, presumed) and Taka as to whether it has already been addressed elsewhere. No firm conclusion reached; carried forward. |
| (unspecified — 2024 issue, no link posted) | Unspecified, dated 2024 | Chair to review personally to confirm continued relevance. |
| (unspecified — issue concerning Swedish BankID ecosystem) | Issue arising from the Swedish BankID ecosystem and a "Steba"-style flow (likely CIBA-related; transcription unclear) | Resolution suggested as "won't fix." Chair noted this should be confirmed with the people who were originally party to the discussion before closing. |
| (unspecified — raised originally by the chair) | Not detailed in transcript | Chair to review personally; noted that circumstances may have changed since it was originally raised. |
| #229 | FAPI CIBA and ID Tokens | Extended discussion — see Section 6.1 below. Latest documented conclusion from Dave Tonge is "won't fix," but this was challenged during the call. Action: working group members to add comments/opinions to the issue. |
| #506 | Explicit security target (raised 2022) | The original ask was to document security and privacy assumptions. Nat Sakimura previously suggested reviewing the introduction and checking the security analysis for text that could be referenced to support those assumptions. Direction from Dave Tonge in May (2026, presumed) was discussed on a recent call. Status: open for anyone to pick up; flagged as an interesting but important item to unpick. |
| #744 | Certification team query: refresh tokens in (Client Credentials Grant context) | Joseph Heenan confirmed this was implemented on the certification team side as of May. Resolved — to be closed. |
| #738 | Deprecation of FAPI 2 ID2 tests | Still awaiting confirmation from UAE as to whether they are still using the ID2 tests. Lukasz Jaromin previously responded that UAE likely has at least one remaining implementer in progress (as of early May). Treated as an ongoing tracking item rather than a decision point for this call. |
| #433 | Track FAPI-compliant RP libraries | Characterised as more of an ongoing/soft tracking task than a discrete issue — the group needs to work out a sustainable way to track available libraries (e.g., for FAPI 2) rather than resolve it as a one-off. |
| #709 | The "kid" (Key ID) parameter | Related to message signatures; flagged as needing input from Taka, who was not on the call. No resolution. Chair noted the volume of message-signing-related issues may warrant a dedicated call with the right subject-matter participants. |
| (unspecified — "framework structure") | Described as a "soft" issue | No substantive discussion; noted only in passing. |
| (unspecified — DCR-related) | Dynamic Client Registration | Chair suggested this should likely be closed, as it is not progressing. |
Remaining open issues not individually discussed will be triaged by the chair together with Nat Sakimura and Dave Tonge to determine which genuinely require working group input versus which can be closed or resolved administratively.
6.1 Issue #229 — FAPI CIBA and ID Tokens (extended discussion)
This was the most substantive technical discussion of the call.
- The latest recorded conclusion on the issue (attributed to Dave Tonge) is "won't fix." Joseph Heenan questioned this outcome on the call, noting the current requirement is logically awkward: CIBA's reliance on the OpenID
scopeproduces a situation where an ID token must be requested and returned even when the relying party has no need to know the user's identity and only wants resource access. He noted this is not well aligned with data minimisation principles, and that it locks every conformant FAPI-CIBA implementation into supporting ID tokens via the certification suite. - Peter Stanley (OBL) raised a practical counterpoint: outside of CIBA, the ID token (specifically the ACR claim) is currently the only mechanism by which a TPP can determine what level of authentication (e.g., strong customer authentication) was performed. UK regulators require TPPs to report on the authentication level used for certain transactions, and the ID token is currently the only source for that data. Peter's position: if the ID token is removed from CIBA, an alternative mechanism is needed to convey that authentication-level information — otherwise ecosystems like the UK that depend on it will be unable to move away from requiring an ID token.
- Joseph Heenan clarified that these are two separable questions: (1) whether CIBA's core reliance on the ID token can be removed, and (2) whether a relying party that specifically needs the ACR claim can still request an ID token voluntarily. Removing the mandatory dependency would not prevent ecosystems that need it from continuing to request one.
- Peter Stanley indicated he would be supportive, in principle, of ID tokens becoming optional in CIBA — allowing ecosystems such as the UK that need it to continue requesting it, while not constraining ecosystems that don't.
- The chair noted this creates a perceived inconsistency with the "won't fix" resolution and asked that anyone with an opinion — including those in favour of the ID token remaining as-is — add comments directly to the issue, since there are legitimate scenarios where the ID token may not be needed.
- Joseph Heenan flagged a complication: implementing this change would likely require an update to the underlying CIBA core specification, which lives with the OpenID Connect (Moderna/Modrna) working group rather than FAPI, since CIBA core relies on OIDC-defined elements such as
login_hint. He suggested the wording change required may be modest, but noted the group needs people to explicitly state they require CIBA without an ID token before prioritising the work, and to determine who would carry it out.
Action: Working group participants to record their position (for or against optional ID tokens in CIBA) directly on issue #229.
Raised by Peter Stanley (OBL), who had been away from recent calls and wanted to flag the topic for future agenda planning rather than resolve it today.
- Context: there is an known issue concerning
private_key_jwtand audience (aud) restrictions — referenced issues #714 and #848 — and a related IETF document, draft-ietf-oauth-rfc7523bis, which Joseph Heenan reported is now in the RFC Editor queue (i.e., has passed through OAuth working group review and IESG/Area Director approval, and is awaiting final publication — timeline estimated at anywhere from a few weeks to a few months). - Peter recalled that Joseph had previously indicated the working group (rather than the certification/testing team) should have final say on how this is handled in conformance testing, and asked Joseph to confirm.
- Joseph confirmed this is correct, and noted that no issue has yet been opened specifically to track the testing-approach decision (issue #848 is related but may not fully capture the conformance-testing angle). He committed to opening a new issue and recording at least one candidate option in it.
- Joseph outlined the core tension for certification: the test suite needs to know which
audvalue a given server actually supports in order to send a correct test request. Practical options discussed:- Continue supporting servers using the current (existing)
audvalue, at least for a transition period — likely necessary regardless of other decisions. - Stand up a second certification test suite/profile incorporating the new
audhandling from the updated IETF draft, allowing implementers to choose between the existing suite and the new one. - Joseph noted some ecosystems are not actually vulnerable to the underlying issue, raising a policy question as to whether migration work should be forced on ecosystems that don't need it, versus allowing the current behaviour to persist for an extended period (potentially until a future post-quantum cryptography migration forces broader changes anyway). Joseph was explicit that this is a decision for the working group, not something he should determine unilaterally in his certification-team capacity.
- Continue supporting servers using the current (existing)
- Peter Stanley provided UK-specific context: UK banks are subject to yearly FAPI conformance attestation. Any change that forces an uplift to bank-side components carries a meaningful lead time — banks need advance notice to plan, resource, and fund the necessary work ahead of their attestation deadlines. He emphasised that any "must do X by Y" requirement needs a substantial lead-up period and proper consultation beforehand, rather than arriving as a late or sudden requirement. He noted the UK ecosystem has not yet been engaged on this topic at all, and that he would like to bring a clear, well-formed message to them once options are developed, to gather their input on preferred approaches.
- The chair thanked Peter for raising the topic and agreed the group needs to follow up, likely via Joseph raising/expanding the issue and the working group discussing options on a dedicated future call. The chair also suggested it would be useful to check on the precise publication status and content of the RFC 7523bis update before deciding next steps, since that may inform timing.
| # | Action | Owner | Reference |
|---|---|---|---|
| 1 | Review/comment on issue re: message-signing extension; confirm with Justin and Taka whether already resolved | Working group / Taka, Justin | #706 |
| 2 | Review unspecified 2024 issue for continued relevance | Dima Postnikov | — |
| 3 | Confirm "won't fix" resolution with original discussion participants before closing (Swedish BankID-related issue) | Dima Postnikov | — |
| 4 | Review previously self-raised issue for continued relevance | Dima Postnikov | — |
| 5 | Add comments/opinions (for or against optional ID token) to FAPI CIBA / ID token issue | All working group participants | #229 |
| 6 | Continue reviewing security/privacy assumptions documentation against intro and security analysis text | Open / anyone to pick up | #506 |
| 7 | Close issue — refresh tokens / Client Credentials Grant query confirmed implemented | Joseph Heenan (confirm closure) | #744 |
| 8 | Continue tracking UAE confirmation on FAPI 2 ID2 test usage | Dima Postnikov / Lukasz Jaromin | #738 |
| 9 | Determine sustainable approach for tracking FAPI-compliant RP libraries | Working group | #433 |
| 10 | Follow up on "kid" parameter issue with Taka; consider dedicated message-signing call | Dima Postnikov / Taka | #709 |
| 11 | Close DCR-related issue (not progressing) | Dima Postnikov | — |
| 12 | Triage remaining open issues (72 total) ahead of Bitbucket → GitHub migration; determine which require WG input vs. closure | Dima Postnikov, Nat Sakimura, Dave Tonge | — |
| 13 | Confirm Bitbucket-to-GitHub migration schedule for FAPI repository; plan for manual reassignment of issues and reopening of in-flight PRs post-migration | Dima Postnikov, Joseph Heenan (liaising with migration team) | — |
| 14 | Open new issue tracking the conformance-testing approach decision for the private_key_jwt aud vulnerability; record candidate options |
Joseph Heenan | Related to #714, #848 |
| 15 | Check publication status/content of RFC 7523bis (draft-ietf-oauth-rfc7523bis) before finalising testing approach | Joseph Heenan | draft-ietf-oauth-rfc7523bis |
| 16 | Schedule dedicated working group discussion on options for handling the aud testing transition, with advance lead time for ecosystems (e.g., UK) |
Dima Postnikov, Joseph Heenan, Peter Stanley | — |
| 17 | Engage UK ecosystem with a clear message and gather input on preferred options for the aud migration once developed |
Peter Stanley | — |
| 18 | Follow up with India/Sahamati-type ecosystem profile question (bring into WG vs. maintain separately) — discuss with Nat Sakimura | Dima Postnikov | — |
FAPI Working Group Atlantic call — reconvening on the regular weekly schedule (next week).
Editorial flags requiring confirmation before publication:
- The full attendee list above is drawn from chat roll-call entries and speaking participants; no organisational affiliation was given in chat for Kosuke Koiwai or George Fletcher — these should be confirmed before publication.
- The "open banking ecosystem" name referenced in Section 4 was unclear in the source audio/transcript ("Feeling, open banking assistant") and could not be confidently identified.
- Several issues discussed in Section 6 were not accompanied by a posted link or clearly stated issue number in either the transcript or chat log (rows marked "unspecified") and should be cross-checked against the Bitbucket issue tracker by issue title/topic before this document is finalised.
- "Steba flow" (Section 6) and "5P repository" / "5P2" (Sections 5–6) appear to be transcription artifacts for "CIBA flow" and "FAPI repository" / "FAPI 2" respectively; rendered contextually in this document but worth a final pass against the source recording if precision is critical.