Skip to content

FAPI_Meeting_Notes_2026 03 04_Atlantic

Jump to bottom
Nat Sakimura edited this page Jul 10, 2026 · 1 revision

WARNING: WORK IN PROGRESS

FAPI Working Group — Atlantic Call

Date: Wednesday, 4 March 2026

Chair: Nat Sakimura / Dave Tonge

1. Attendees

  • Nat Sakimura
  • Dave Tonge
  • George Fletcher (driving; muted throughout)
  • Robert Gallagher (Mastercard)
  • Kosuke Koiwai
  • Bjorn Hjelm
  • Hideki Ikeda
  • Filip Skokan (joined late)
  • Brian Campbell
  • Chris Robbertse (Open Banking Limited)

2. Notes

Nat noted he was attending concurrently with an ISO meeting (JTC1 SC44) in parallel and Japan FinTech Week, making the schedule extremely demanding. Robert Gallagher mentioned he had also been on a digital currencies ISO call the previous evening and noted that a new AG5 DeFi advisory group is expected to form shortly under TC68. The group briefly discussed the proliferation of relevant ISO sub-committees (TC68, TC307, SC27, SC17, SC44) and the need to bring them into alignment.

3. Agenda

  1. Roll Call
  2. Adoption of Agenda
  3. Events
  4. External Orgs & Liaisons
  5. PRs
  6. Issues
  7. AOB

4. Events

Reported by Nat on behalf of Mike L. (apologies received)

  • 14 April — OECD Working Party on Digital Security, Paris
  • 22–23 April — IAM Tech Day, São Paulo

No additional events raised by attendees.

5. External Orgs & Liaisons

No material ecosystem engagement or liaison updates to report.

6. Member Reminders

Posted by Nat in chat:

Members were asked to note the upcoming voting deadlines.

7. Pull Requests

Led by Dave Tonge. All PRs are against the FAPI Bitbucket repository.

PR #562 — TLS cipher suite references (FAPI 1 / ISO submission)

Link: https://bitbucket.org/openid/fapi/pull-requests/562

Nat explained that the change moves away from hard-coding key sizes and cipher suites in the spec body and instead references BCP 195 and the IANA TLS Parameters Registry. The relevant RFCs establishing the IANA registry are RFC 8447 and RFC 9847. Two locations are updated: one for server requirements and one for client requirements. Once merged, the updated text can be sent to ISO (JTC1 SC44 / ISO/IEC 29794-2 review).

Dave confirmed the change looks good. Members were asked to review and approve so it can be merged.

PR #563 — Explicitly allow ChaCha algorithms (FAPI 2)

Link: https://bitbucket.org/openid/fapi/pull-requests/563

This PR explicitly permits the ChaCha cipher suite algorithms in FAPI 2. Nat confirmed the spec still references BCP 195 and the IANA TLS Parameters Registry; the RFC reference approach (RFC 8447 / 9847) is the correct way to cite IANA registries in the xml2rfc toolchain. Filip Skokan had already reviewed and flagged spelling errors, which Nat corrected. Dave and Nat agreed the approach is more maintainable than inline IANA registry names given toolset constraints.

Members were asked to review and approve.

PR #564 — Editorial: add reference to RFC 6749 §5.2.3 (FAPI 1)

Link: https://bitbucket.org/openid/fapi/pull-requests/564

In response to a JTC1 comment asking where a specific normative requirement originates, a reference to RFC 6749 §5.2.3 was added inline to make it easier for the reader to locate the source. Dave confirmed the change is sensible.

PR #565 — Add response-side message source authentication (FAPI 1 / Issue #731)

Link: https://bitbucket.org/openid/fapi/pull-requests/565

Resolves issue #731, which noted that the spec only addressed message source authentication for the request object, overlooking the response. Dave acknowledged this was an oversight that had been discussed previously. Nat implemented the fix. Dave confirmed it looks good.

PR #566 — Clarify BCP 195 quotation in NOTE (FAPI 1)

Link: https://bitbucket.org/openid/fapi/pull-requests/566

Another item arising from the JTC1 ISO review. A NOTE in the spec contained normative-looking language that was actually a quotation from BCP 195. To make the origin clear, quotation marks have been added. Dave agreed the change is appropriate.

8. Issues

FAPI 1 Baseline Issues

Issue #731 — Message source authentication (request object) → resolved by PR #565 above.

Issue #778 — Reference to BCP 195 and IANA TLS Parameters Registry → resolved by PR #562 above.

Issue #841 — Clarify NOTE quotation origin → resolved by PR #566 above.

Issue #730 — Section 5.2.3 public client interpretation

Link: https://github.com/openid/fapi/issues/730

Joseph (not present) raised the question of how to interpret the conditional preamble "if OpenID is not in the scope value, then public client …" that appears just before item 9 of §5.2.3. The concern is that items 10 and 11 following item 9 may appear to be subject to the same condition, when in fact they should apply unconditionally.

Discussion:

  • Dave confirmed the original intent was that the condition applies only to item 9 (requiring the state parameter for CSRF protection when the nonce-based protection of OpenID Connect is absent).
  • George Fletcher explained the rationale: when the openid scope is present, the nonce provides CSRF protection, so state is not separately required; without openid, state must be used.
  • Items 10 and 11 are unrelated to the openid scope and should always apply.
  • Dave acknowledged the layout is confusing and suggested that the conditional text "if OpenID is not in the scope value, then public client" could simply be moved into item 9 itself (no new normative words, purely editorial reordering). This would make it unambiguous that the condition is scoped to item 9.
  • Nat agreed to attempt the editorial restructuring.

Resolution: No normative change required. Nat will raise a PR with an editorial reordering to make the scope of the condition unambiguous. A clarifying comment will be added to the issue.

Action: Nat — create editorial PR to restructure §5.2.3 item 9 condition.

FAPI 1 Advanced Issues

Issue #806 — ISO/IEC 29794-2 review comment: add reference to RFC 9207

Link: https://github.com/openid/fapi/issues/806

An ISO reviewer suggested adding a reference to RFC 9207 (OAuth 2.0 Authorization Server Issuer Identification) as a mitigation against IDP mix-up attacks. Nat noted that RFC 9207 is already used in FAPI 2 but is not used in FAPI 1, so adding a reference would be inappropriate. He proposed rejecting the comment without making a change.

No objections were raised.

Resolution: ISO comment rejected; no change to FAPI 1 Advanced.

Action: Nat — post rejection response to issue #806.

Issue #714 — Private key JWT aud restrictions

Link: https://github.com/openid/fapi/issues/714

Nat confirmed the group is still waiting for the upstream RFC 7523bis document to be updated before FAPI can incorporate the change. Filip Skokan reported that RFC 7523bis has passed IETF working group last call, feedback from the working group chairs has been addressed, and the document is expected to advance. Brian Campbell confirmed this status.

Resolution: Pending RFC 7523bis publication. Group may begin drafting the corresponding FAPI change in anticipation.

Action: All — monitor RFC 7523bis progress; begin implementation planning.

9. AOB

OpenAPI liaison channel (raised by Chris Robbertse, OBL)

Chris asked whether Nat had made progress on setting up a liaison channel with the OpenAPI initiative. Nat acknowledged it had slipped and committed to reaching out immediately after the call.

Action: Nat — contact OpenAPI initiative to establish liaison channel.

Next week's call

Nat advised he will be attending an ISO SC27 meeting and may not be able to chair. He will check whether Dave can host the call and communicate accordingly.

Action: Nat — confirm hosting arrangements for next week's call with Dave.

10. Action Items Summary

# Action Owner Due
1 Review and approve PRs #562–566 All ASAP
2 Editorial PR to restructure §5.2.3 item 9 condition (Issue #730) Nat Next call
3 Post rejection response to ISO comment on Issue #806 Nat ASAP
4 Monitor RFC 7523bis progress; begin FAPI implementation planning (Issue #714) All Ongoing
5 Contact OpenAPI initiative to establish liaison channel Nat Immediately
6 Confirm hosting arrangements for next week's call Nat / Dave This week

Meeting adjourned early at approximately 00:33 UTC at Nat's request due to schedule exhaustion.

Clone this wiki locally