Repository navigation
FAPI_Meeting_Notes_2026‐09‐16_Atlantic
Date: 2026-09-16
Time: 14:00 UTC
Location: Zoom
Chair (acting for this call): Nat Sakimura (NAT.Consulting / Authlete)
Co-Chair: Dave Tonge (Moneyhub)
Duration: Approximately 41 minutes (adjourned early)
Attendance was taken via the chat.
| Name | Affiliation |
|---|---|
| Nat Sakimura | NAT.Consulting / Authlete |
| Dave Tonge | Moneyhub (WG Co-Chair) |
| Joseph Heenan | OpenID Foundation / Authlete |
| Peter Stanley | Open Banking Limited |
| Imran Ulghar | Open Banking Limited |
| Christopher Robbertse | Open Banking Limited (joined shortly after the start) |
| Ashmita Chakraborty | Individual contributor |
| Bjorn Hjelm | Yubico |
| Kosuke Koiwai | KDDI |
Regrets / absent: Mike Leszcz (OIDF) — supplied the events list to the Chair in advance.
The Chair displayed the OpenID Foundation note well, antitrust policy, IPR policy, contribution agreement and participation agreement, and reminded participants that these apply to the call. The text was not recited in full as participants are familiar with it.
The draft agenda was posted to the chat:
- Roll Call
- Adoption of Agenda
- Events
- External Orgs & Liaisons
- PRs
- Issues
- #864 — OWASP ASVS 5.0 section 10.4.8 requires strict refresh token expiry, which conflicts with FAPI 2.0 SP 5.3.2.1-9
- Other Issues
- AOB (Nat)
Peter Stanley asked to continue the discussion from the previous week on the aud value changes and the conformance suite. The Chair agreed and added issue #848 to the agenda as item 6.2. No other additions were requested, and the agenda was adopted as amended.
The following list was supplied by Mike Leszcz and posted to the chat:
| Date | Event | Location |
|---|---|---|
| 2026-09-14 – 2026-09-17 | ISO/IEC JTC 1/SC 17 Plenary | Chengdu, China |
| 2026-10-19 – 2026-10-21 | FIDO Authenticate 2026 | Carlsbad, CA |
| 2026-11-02 | OIDF Workshop prior to IIW Fall 2026 (hosted by CrowdStrike) | Sunnyvale, CA |
| 2026-11-03 – 2026-11-05 | IIW Fall 2026 | Mountain View, CA |
| 2026-11-14 – 2026-11-20 | IETF 127 | San Francisco, CA |
| 2026-11-17 – 2026-11-18 | Finance of Tomorrow | Rio de Janeiro, Brazil |
| 2026-12-07 – 2026-12-09 | Gartner IAM US | Las Vegas, NV |
| 2027-02-02 – 2027-02-04 | OIDF Global Conference (save the dates) | London, UK |
Notes from the discussion:
- The SC 17 plenary was in progress during the call.
- Several working groups are expected to run interop activities around the December events.
- A call for proposals is open for the 2027 OIDF Global Conference in London. Participants with material to contribute were asked to submit a session.
- Conference page: https://openid.net/conference/
- Call for proposals: https://openid.net/oidf2027conference_call-for-proposals/
- Any further events should be sent to Mike L. for inclusion.
Following up on a request made the previous week, Peter Stanley reported that he had raised OBL speaking at the London conference internally and that there was interest in exploring it. He asked who to direct people to.
The Chair advised that Elizabeth Garber is managing the conference programme, with Mike Leszcz as an alternative contact. Joseph Heenan posted Elizabeth's address to the chat (elizabeth.garber@oidf.org). Peter confirmed he would write to Elizabeth and copy Mike.
Peter also asked whether the previous week's minutes had been published; the Chair confirmed they had been posted roughly two hours before the call.
LATAM ecosystem partner meetings are being considered around the Finance of Tomorrow event in Rio de Janeiro on 2026-11-17 and 2026-11-18. Participants with an interest in the LATAM ecosystem may wish to attend.
The vote to approve the proposed OpenID Connect Ephemeral Subject Identifier 1.0 Final Specification opened on the day of the call and runs through Wednesday 2026-09-30.
The Chair noted that some UK participants are already using the mechanism, that it allows an untrackable identifier to be presented over OpenID Connect, and that the specification contains only three or four normative requirements, making it a quick read. Members were encouraged to review it and vote.
The OpenID Foundation is seeking a Technical Director. The job description and related material are published at https://openid.net/openid-foundation-seeks-technical-director/. Participants were asked to pass the opening on to suitable candidates.
No other liaison or external organisation items were raised.
Dave Tonge presented. He reported that two outstanding pull requests dealing with the Bitbucket-to-GitHub changeover had been reviewed and approved. The remaining open pull requests all relate to FAPI-CIBA and had been raised shortly before the call; Dave proposed walking through them on the call, leaving them open for working group comment, and merging them on the call of 2026-09-23.
https://github.com/openid/fapi/pull/865/changes
FAPI-CIBA needs to support both FAPI 1 and FAPI 2. The pull request makes explicit that, for FAPI 2, authentication requests are unsigned.
- The requirement that the authorization server support both signed and unsigned requests previously sat in the FAPI 1 part. The change moves a requirement into the main body that the authorization server shall support unsigned requests, with FAPI 1 additionally permitting signed requests. Dave expected this part to be uncontroversial.
- The client-side text currently says the client shall send unsigned authentication requests. Dave questioned whether a client is non-conformant if it sends signed requests where FAPI 2 message signing is in use, and suggested the client-side sentence could be dropped, since the essential point is that authorization servers accept unsigned requests.
- Joseph Heenan agreed with the direction but flagged a wording problem: Brazil, on adopting this, requires FAPI 2 message-signing-style signed requests, and its profile requires unsigned requests to be rejected. The current language would still oblige such deployments to support unsigned requests. He suggested language along the lines of "signed requests unless a profile overrides it", noting that something similar already exists in the FAPI 2.0 Security Profile.
- Dave agreed to look at the comparable FAPI 2 profile text and adjust the wording.
https://github.com/openid/fapi/pull/866
The existing security considerations text described binding messages as useful. Drawing on recent security analysis and the OAuth Working Group cross-device BCP, the pull request adds that binding messages still do not protect against an attacker-controlled consumption device, and reuses the existing reference to the cross-device BCP. Dave characterised the change as editorial, intended to draw out that a binding message alone is not complete protection.
Joseph Heenan, reading the change for the first time, observed that the ordering of the paragraphs implies that using a QR code addresses the attacker-controlled consumption device case, which he did not believe to be true. Dave accepted the point and will revise.
https://github.com/openid/fapi/pull/867
The pull request removes the repeated TLS considerations, algorithm considerations and encryption algorithm considerations from the security considerations section, replacing them with a requirement to follow the TLS and algorithm requirements of FAPI 1 when used with FAPI 1, and of FAPI 2 when used with FAPI 2. Dave deliberately referenced the documents rather than specific clauses, so that a new version of either document does not force an update here. He emphasised that the intent is not to reduce security but to avoid duplicated text going out of date.
- The Chair supported the direction, making the same point: referring rather than copying avoids having to propagate every change.
- Joseph Heenan also supported it but asked that "algorithm" be clarified as referring to cryptographic algorithms, since the meaning, though clear, is the kind of thing that invites argument.
- Dave proposed wording it as "TLS and JWS/JWE", those being the only areas where the specifications provide guidance. Joseph agreed that would work.
https://github.com/openid/fapi/pull/868/changes
An editorial pull request correcting residual Bitbucket links and ensuring the correct references point to the correct documents. Dave noted that one of the changes may duplicate a change in another pull request and that there may be crossover with Joseph's pull requests; he will review and tidy it before merging. Joseph indicated his own pull requests may now be ready to merge following Dave's review.
https://github.com/openid/fapi/pull/869
Prepared against the issue covering readiness for publication. The change adds the document history, working through what the changes were, plus two small corrections:
- The title is corrected to FAPI Security Profile rather than "FAPI API Security Profile".
- A reference to request context appeared to be out of date.
This pull request needs to merge after the others and is not yet ready.
https://github.com/openid/fapi/issues/864
The Chair raised a conflict he had encountered in OWASP Application Security Verification Standard (ASVS) 5.0:
- ASVS 5.0, V10.4 (OAuth Authorization Server), requirement 10.4.8: verify that refresh tokens have an absolute expiration, including where sliding refresh token expiration is applied. The Chair read this as requiring an expiry to be set and refresh tokens to be rotated — in effect, that refresh tokens must expire.
- FAPI 2.0 Security Profile §5.3.2.1-9: refresh token rotation shall not be used except in extraordinary circumstances.
Discussion points:
- The link in the issue returned a 404. Imran Ulghar confirmed that the broken link is on the OWASP side, specifically for that version, and posted the working GitHub location to the chat: https://github.com/OWASP/ASVS/tree/v5.0.0#latest-stable-version---500. The Chair confirmed the version list and PDF downloads are reachable from there.
- Joseph Heenan noted that the FAPI 2 text allowing a rotated token to remain usable for a period after rotation also appears to conflict with the ASVS requirements.
- Joseph said he did not know what the ASVS L1 and L2 application levels cover, and was not certain of the precise intent of clause 10.4.8. He observed that an absolute refresh token expiry seems misguided for confidential clients; the Chair agreed.
- Joseph recalled that there may have been a session on this topic at an OAuth Security Workshop, though neither he nor the Chair attended it.
- The Chair suggested the working group may want to approach OWASP with reasoning as to why the requirement is not advisable, and noted that questions on this point may arrive from national financial regulators.
Outcome: left with the working group to consider, to be revisited in the coming weeks before deciding on a course of action.
https://github.com/openid/fapi/issues/848
Continuation of the previous week's discussion. Reference: FAPI meeting notes 2026-09-09, section 5.1.
Peter Stanley reported that he raised the change with the CMA9 earlier that day to gather initial feedback. Further conversations will follow, but the immediate reaction was that more time is always welcome. He went to them with the original 12-month proposal and now considers 16 months to be realistic, which is close to Joseph Heenan's earlier 15-month suggestion. The CMA9 are on a mandatory annual certification renewal cycle, so a single year is too short for some of them; roughly a year and a half of warning before the condition becomes a failure is, in his view, the appropriate approach. Joseph had no objection, treating 15 versus 16 months as immaterial.
Joseph Heenan checked the status in the conformance tests during the call:
- A test exists that sends the
audvalue as the issuer value and raises a warning. - Reviewing UK bank results, one or two of the banks use mTLS rather than
private_key_jwtand are therefore unaffected. - The banks he checked that do support
private_key_jwtall appear to be passing that test, suggesting that vendor products in the UK market have been accepting the issuer as theaudvalue for some time — a positive indication that the change may require little work. - One institution (recorded on audio as AIB) appeared to show a warning, but it has warnings against a range of items, so the significance is unclear.
Peter Stanley confirmed the CMA9 have been actioned to talk to their vendors and establish whether they can support the change. He does not expect a response for two weeks, so there will be no update on the 2026-09-23 call; he will bring an update back after the follow-up conversation.
The Chair noted that the previous week's discussion had been captured in the published meeting notes (link above) and asked participants to flag anything incorrect. No further recent issues were raised; Dave Tonge confirmed he had nothing to add.
The Chair asked Christopher Robbertse for an update. Christopher has been trying to arrange a meeting with the two contacts involved and has now scheduled one for 2026-10-07; progress has been slow following the holiday period.
It was agreed to place this item on the agenda for the 2026-10-14 call, allowing time after the 7 October meeting, which falls in the evening for Christopher.
With no further business, the Chair closed the meeting early, thanking participants for attending and Dave Tonge in particular for raising the pull requests. The meeting was adjourned at approximately 14:41 UTC.
| # | Action | Owner | Due / Target |
|---|---|---|---|
| 1 | Revise PR #865 wording against the comparable FAPI 2.0 Security Profile text so a profile may override the unsigned-request requirement; decide whether to drop the client-side sentence | Dave Tonge | Before the 2026-09-23 call |
| 2 | Revise PR #866 so that the paragraph ordering does not imply a QR code mitigates an attacker-controlled consumption device | Dave Tonge | Before the 2026-09-23 call |
| 3 | Amend PR #867 to make clear that "algorithm" refers to cryptographic algorithms, e.g. "TLS and JWS/JWE" | Dave Tonge | Before the 2026-09-23 call |
| 4 | Review PR #868 for overlap with Joseph Heenan's pull requests and clean up duplicated changes | Dave Tonge | Before the 2026-09-23 call |
| 5 | Hold PR #869 (document history) for merge after the remaining FAPI-CIBA pull requests | Dave Tonge | After PRs #865–#868 |
| 6 | Review the FAPI-CIBA pull requests and comment | All WG participants | Before the 2026-09-23 call |
| 7 | Consider issue #864 and the FAPI position on refresh token expiry; decide whether to approach OWASP with reasoning | All WG participants | Coming weeks |
| 8 | Contact Elizabeth Garber (cc Mike Leszcz) regarding OBL participation in the 2027 OIDF Global Conference | Peter Stanley | — |
| 9 | Report back on CMA9 vendor feedback on the aud value change |
Peter Stanley | Approximately 2026-09-30 (not 2026-09-23) |
| 10 | Hold the OpenAPI meeting and report back | Christopher Robbertse | 2026-10-07; report on 2026-10-14 |
| 11 | Add the OpenAPI item to the 2026-10-14 agenda | Nat Sakimura | 2026-10-14 |
| 12 | Review and vote on OpenID Connect Ephemeral Subject Identifier 1.0 Final Specification | OIDF members | 2026-09-30 |