-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2025 07 10_Pacific
Nat Sakimura edited this page Jul 10, 2026
·
1 revision
- Anoop
- Nat
- Dima
- Mark
- Roll Call
- Adoption of Agenda
- Events
- External Orgs & Liaisons
- PRs
- Issues
- AOB
Upcoming Events:
- IETF 120 Montreal is coming up (July 23).
-
- Nat will attend remotely only
-
- Two OAuth sessions and one OpenID Connect session scheduled
- 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
https://docs.google.com/spreadsheets/d/1WlxZF_azuxc8TBsmWTB7V6ErC4f3j9VIWLVUiwPavcw/edit?gid=0#gid=0
The OIDF calendar on the website and Google calendar are current and available at: https://openid.net/calendar/
- Expecting to hear results soon
- Domingos is taking the lead on the KSA FAPI2 Profile
- Development plan will be shared with SAMA soon
- Mike Jones is finalizing directed funding to support this development
- Gail Hodges, Joseph Heenan, Mark Haine, and Mike Jones 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 Jones 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.
**Issue #736: FAPI Post-Quantum Cryptography **
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
-->> Dima suggested, May be a Blog post on OpenId. -->> Mark Suggested, Impact on use cases (inventory) from certification group.
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)
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
- 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)
- 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
- 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
NO PRs
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.