-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2025 07 30_Atlantic
Nat Sakimura edited this page Jul 10, 2026
·
1 revision
Date: July 30, 2025
Time: 14:00 GMT
Chair: Nat Sakimura
- Nat Sakimura (Chair)
- Dave Tonge
- Joe DeCock
- Filip Skokan
- Peter Stanley
- George Fletcher
- Joseph Heenan (OIDF & Authlete)
- Brian Campbell
- Dima Postnikov
- Imran Ulghar (OBL)
- Takahiko Kawasaki
- Kosuke Koiwai
- Hideki Ikeda
- Christopher Robbertse
- Robert Gallagher (Mastercard)
Meeting called to order with roll call completed. Agenda adopted as presented.
Upcoming Events (reported by Mike Leszcz via Nat):
-
September 8-10: Finance of Tomorrow - Rio de Janeiro
- Mark Haine and Domingos Creado representing OIDF
-
October 13-16: FIDO Authenticate - Carlsbad, CA
- Mike Jones likely to represent OIDF
-
October 27: OIDF events including after lunch workshop prior to IIW
- Host still TBC
- October 28-30: IIW Fall 2025 - Mountain View
- November 1-7: IETF 124 Montreal
- Following week: Web Conference in Lisbon
The OIDF calendar on website is current.
- Kickoff meeting held July 28th
- Next meeting: August 15th (Pacific call) - 10am Sydney / August 14th 5pm PT/8pm ET
- Two calls per month: one EU-friendly, one US-friendly (Australia in the middle)
- Focus on supporting existing and new ecosystems beyond specific specifications
- Covers conformance testing and rollout requirements
- Currently in admin phase with participation agreements being signed
- All ecosystem partners welcome to participate
- RFC 7523bis updates discussed above
- Attestation-based client authentication progressing
- No other immediately relevant updates for FAPI working group
- Sync required with IPSE working group on authentication-only requirements
- Nat to engage with Aaron on IPSE alignment
- Consider whether separate authentication profile warranted
Joe announced Duende's launch event for IdentityServer SDK version 7.3:
- Certified as FAPI 2.0 compliant
- Event scheduled for August 21st at 10am Eastern
- Focus on building secure, specification-based identity solutions
- Registration: https://duendesoftware.com/webinars/duende-identityserver-7-3-fapi-2-0
- Public consultation on customer authentication for stock trading systems open until August 18th
- Financial Services Agency requiring phishing-resistant authentication methods
- Expected to end screen scraping and require APIs instead
- One push towards achievement of original FAPI work group objectives
- Vote on JARM Errata: Open until August 4th
- Shared Signals Specifications Vote: Currently active
- Most PRs discussed in previous call
- Issue #290 has sufficient approvals but cannot be merged due to conflicts
- Dave to address merge conflicts across affected PRs
- Discussion of PR waiting on RFC 7523bis status
- Filip confirmed dependency on RFC 7523bis reaching working group last call
- Joe to revisit PR, address comments, and prepare for next meeting discussion
- Authors requesting FAPI working group feedback on draft
- Significant changes published around July 23rd
- Several open issues addressing overly restrictive language concerns
- Repository: https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis
- Specific focus needed from Joe and Dave (FAPI 1 implementers)
Audience and Type Requirements:
- Original proposal required string-only audience and mandatory type claim
- Feedback from ecosystems indicated this would be breaking change
- New proposal (PR #15): Relaxed requirements allowing array or string audience
- AS must enforce exactly one audience value matching issuer identifier
- Removes mandatory type requirement to avoid breaking existing clients
Peter Stanley's Concerns:
- UK Open Banking just completed migration to final FAPI 1
- Need consolidated view of all proposed FAPI 1 changes
- Require strong justification for any breaking changes
- Request for clear communication timeline and delivery mechanism
Dave Tonge's Observations:
- Major change affects audience handling in private key JWT assertions
- Current ecosystems may need type claim additions
- Significant change requiring early communication to ecosystems
Working Group Consensus:
- Bring comprehensive FAPI 1 review back to working group table
- Consolidate all pending changes for holistic assessment
- Consider whether changes warrant FAPI 1.1 vs errata approach
- Schedule dedicated discussion time with full team availability
- Draft progressing toward finalization at IETF
- Potential inclusion in FAPI as acceptable client authentication method
- Complements rather than replaces existing methods (dynamic client registration, OpenID Federation)
- Multiple overlapping solutions: client attestation, OpenID Federation, dynamic client registration
- Authorization server complexity from supporting multiple combinations
- Risk of market fragmentation if providers choose different subsets
- Question of whether foundation should provide guidance
- Solutions not mutually exclusive - can be used in combination
- Client attestation addresses mobile app challenges with dynamic client registration
- Need to balance innovation with implementation complexity
- Consideration of formal methods validation for new combinations
Issue #737: FAPI Without Long-Lived API Access (Dave Tonge)
Context:
- Some identity ecosystems only need ID token exchange
- Want to use FAPI for security benefits without API access requirements
- Question of relaxing sender-constraining requirements for unused access tokens
Mark's Comment:
- Current sender-constraining requirements "pointless" when no resource server used
- Suggests relaxation for cases where resource servers not accessed
Working Group Analysis:
Dima's Perspective (Connect ID ecosystem):
- Currently implement sender-constraining for conformance testing only
- Not used in production as no resource servers accessed
- Request for conformance testing guidance/customization options
- Distinction between spec changes vs testing flexibility
Filip's Security Concerns:
- Relaxing requirements would require new attacker model analysis
- Risk of clients avoiding MTLS/DPoP by claiming no resource access
- Even authentication-only flows may access userinfo endpoint (resource server)
- Formal methods validation needed for any relaxations
George's IPSE Context:
- Similar issues in IPSE SL1 profile (authentication only)
- Question of whether separate authentication profile needed
- Challenge of keeping multiple profiles synchronized
- IPSE participants resist DPoP/MTLS complexity for SSO use cases
Implementation Reality:
- Connect ID forces participants to support sender-constraining for testing
- Anticipates future resource endpoint requirements
- Prefer evolutionary approach within existing spec
Issue #706: Signature Requirements
- Takahiko added elaborate comments with diagrams
- Deferred to next meeting for detailed review
- Nat's preference for FAPI 2.1 rather than errata for new features
- Recognition that new functionality represents feature addition, not bug fix
- Dave Tonge: Address merge conflicts in pending PRs
-
Joe DeCock:
- Review and update PR #529
- Prepare for next meeting discussion
- Review RFC 7523bis draft and provide feedback
- All esp. Dave Tonge: Review RFC 7523bis repository for open PRs and assess impacts
- Dave Tonge: Add RFC 7523bis PR link to Issue #714 for community feedback
- Working Group: Schedule dedicated FAPI 1 consolidation discussion
- All: Review Issue #706 (Takahiko's diagrams) for next meeting
- Nat Sakimura: Engage with Aaron on IPSE working group alignment
- Continue RFC 7523bis feedback discussion
- FAPI 1 comprehensive review
- Issue #706 detailed analysis
- Follow up on ecosystem authentication requirements
Meeting adjourned with thanks to all participants for productive and informative discussion.