-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2025 07 09_Atlantic
Nat Sakimura edited this page Jul 10, 2026
·
1 revision
Date: July 9, 2025
Time: 14:00 UTC
Meeting Type: FAPI Working Group Regular Call
- Nat Sakimura (Chair)
- Dave Tonge (Chair)
- Dima Postnikov (Newly appointed Co-chair)
- Christopher Robbertse - Open Banking Limited
- Kosuke Koiwai
- Peter Wallach
- Bjorn Hjelm
- Brian Campbell
- Joseph Heenan - OIDF & Authlete
- Gail Hodges (via chat)
The meeting began with a roll call. Attendees identified themselves in the chat window. The OpenID Foundation Antitrust Policy was referenced and is available at www.openid.net/antitrust.
The pre-announced agenda was adopted without modifications:
- Roll Call (Dave/Nat)
- Adoption of Agenda (Dave/Nat)
- Events (Mike Leszcz)
- External Orgs & Liaisons (Mike Leszcz)
- PRs (Dave)
- Issues (Dave)
- AOB (Nat)
Mike Leszcz was unable to attend, but provided event updates via email:
- July 19-25, 2025: IETF 123 — Madrid
- October 13-16, 2025: FIDO Authenticate — Carlsbad, CA
- October 27, 2025: OIDF events including workshop prior to IIW (date updated)
- October 28-30, 2025: IIW Fall 2025 — Mountain View
- November 1-7, 2025: IETF 124 — Montreal
The OIDF calendar on the website and Google calendar are current and available at: https://openid.net/calendar/
Nat mentioned he would send additional banking and finance-related events to the mailing list later.
- Domingos is taking the lead on the KSA FAPI2 Profile
- Development plan will be shared with SAMA soon
- Mike Leszcz is finalizing directed funding to support this development
- Gail Hodges, Joseph Heenan, Mark Haine, and Mike Leszcz participated in a whiteboard session with the Open Banking Canada (OB CA) team on Tuesday, July 9th
- The OIDF team addressed specific FAPI2 questions from the Canadian team
- Shared experiences with other ecosystems
-
Next steps:
- Canada to continue working through their regulatory process
- OIDF to share work on global reference architecture via the OIDF Ecosystem Support Community Group
- Canadian team may consider getting involved
- Introduction of Shared Signals to the Canadian team
- FAPI 2.0 Final Conformance Test Certifications: OIDF is finalizing a blog post to announce the availability of FAPI 2.0 final conformance test certifications
- Mike L. was confident the blog post would be published the same day
- Once published, the OIDF can begin accepting and publishing results of self-certifications
- Certification Test Updates: Joseph Heenan confirmed that all known necessary changes to certification tests were rolled out on Monday. Release notes are pending but the updates are live.
Dima Postnikov was officially announced as the new co-chair of the FAPI Working Group. Nat reported that no negative votes were received on Dima's nomination. The appointment will help with call coverage, including Pacific timezone calls.
Dave Tonge reported that there are currently no PRs ready for review. Several PRs are still pending from the deployment implementation device work.
Issue #736: FAPI Post-Quantum Cryptography
Presenter: Joseph Heenan
Link: https://github.com/openid/fapi/issues/736
- The working group hasn't yet signaled what to expect for post-quantum cryptography
- For TLS: Can work on assumption that IETF will update the BCP that FAPI already references to include quantum-safe TLS requirements
- For JWS/JWE: Need IETF to develop post-quantum methods first
-
Versioning concerns: If FAPI stops allowing ES256/ES256K, it may constitute a breaking change
- Could potentially be FAPI 2.1 vs jumping to 3.0
- Group prefers not to skip directly to 3.0 for minor changes
- Consider adding placeholder text in implementation advice document
- Track progress from IETF on both OAuth and TLS specifications
- Determine appropriate versioning strategy (2.1 vs 3.0)
- Issue remains open for tracking
Issue #734: Recommendations Around Handling of Private Keys
Presenter: Joseph Heenan
Link: https://github.com/openid/fapi/issues/734
- Current security considerations section has minimal guidance on private key storage
- Proposal to expand security considerations to reference NIST and other guidance
- Scope concerns: Brian Campbell expressed caution about adding non-normative operational guidance that pushes the boundaries of what an errata should address
- Historical context: Dave Tonge noted that some security considerations were added in response to real-world incidents (like the Microsoft/SolarWinds report)
- Alternative approach: Could be better suited for implementation advice document rather than the main specification
- Current text (Section referenced: https://openid.net/specs/fapi-security-profile-2_0-final.html#name-key-compromise)
- Focuses on what happens when keys are compromised
- Could be expanded to include preventive measures (HSMs, etc.)
- Issue updated to target the Implementation and Deployment Advice document
- Component changed to "implementation and deployment advice"
- May revisit for inclusion in future specification versions (2.1 or errata)
Issue #737: FAPI Without API Access
Presenter: Dima Postnikov
Link: https://github.com/openid/fapi/issues/737
This was a complex issue with two distinct aspects:
- Some identity-only ecosystems want to use FAPI but don't need API access
- Challenge: OAuth specification mandates returning access tokens from token endpoint
- Assessment: Brian Campbell noted this would require overriding core OAuth requirements, which is beyond the scope of this working group
-
Alternative approaches discussed:
- Returning minimal/empty access tokens
- Using OpenID Connect with form post response mode
- Creating custom response type handling
- Some closed ecosystems decide not to support refresh token rotation
- Current FAPI specification mandates client support for refresh tokens for interoperability
- Use case: Identity-only ecosystems or those with system-level requirements against refresh token rotation
- Interoperability vs. Ecosystem Requirements: Balance between ensuring interoperability across implementations vs. allowing ecosystem-specific decisions
- Interoperability rationale: Current client requirements exist to ensure any FAPI-certified client works with any FAPI-certified authorization server
- Library usage: When using existing libraries, refresh token support is typically included by default
- Custom implementations: Creates burden for custom implementations in ecosystems that explicitly don't use refresh tokens
- Access tokens: No clean solution identified due to OAuth specification requirements
- Refresh tokens: Working group could provide official guidance that: - Client refresh token support requirement is for interoperability purposes only - In ecosystems where authorization servers explicitly don't support refresh token rotation, clients don't need this capability - Must ensure short-lived access tokens are still used (avoid long-lived access tokens as alternative)
- Dave Tonge to document the working group's position on refresh token requirements
- Clarify that the requirement is for interoperability, not security
- Reference existing authorization server guidance that prohibits refresh token rotation
- Issue remains open for further ecosystem feedback
- Current certification tests require refresh token rotation support
- Tests verify clients can handle access token expiration and use refresh tokens
- Tests include refresh token rotation scenarios
- Any ecosystem-specific exceptions would need working group approval for conformance test modifications
No additional business was raised.
- Nat Sakimura: Send banking and finance-related events to the mailing list
- Dave Tonge: Document working group position on refresh token requirements in Issue #737
- Dave Tonge: Prepare implementation advice document content for private key storage guidance
- Working Group: Continue tracking IETF progress on post-quantum cryptography specifications
- ** Mike Leszcz:** Follow up on FAPI Mail list once FAPI 2.0 certification blog post is published
Regular weekly call scheduled for the following week.