Skip to content

FAPI_Meeting_Notes_2024 09 04_Atlantic

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

FAPI WG Agenda & Meeting Notes (2024-09-04)

Agenda

  • Nat Sakimura (Co-Chair)
  • Mike Leszcz
  • Hideki Ikeda
  • Dave Tonge (Co-Chair)
  • Bjorn Hjelm
  • Kosuke Koiwai
  • Peter Wallach
  • Hideki Ikeda
  • Robert Gallagher
  • Brian Campbell
  • Chris Wood
  • Dima Postnikov
  • Peter Wallach
  • Takahiko Kawasaki
  • Joseph Heenan
  • Christian Eloysio
  • Tuesday September 10 in DC
  • Gail and Mark will be presenting on the 11th and 12th
  • NIST 863-4 workshop
  • Venable Jeremy Grant Organization
  • Industry Workshop to Discuss the New Draft of NIST SP 800-63-4
  • Friday, September 13, 2024

8:30 - 9:30 a.m. ET Breakfast and Registration 9:30 - 2:00 p.m. ET Program

  • Carlsbad, California
  • Oct 14-16
  • Mike Jones will be there.
  • Oct 29-31
  • Computer History Museum, Mountain View, CA
  • Nov 2 - 8 in Dublin
  • Prior to SIDI hub events in Tokyo
  • Still in planning
  • Will share details next meeting
  • 2025 events added to OIDF Google Calendar and website calendar
  • Send any missing events information to Mike Leszcz
  • Had Followed up meeting regarding questions about membership makeup and other information.
  • Mark Haines will solicit feedback about OIDF draft standard setting organization application
  • Shared FAPI2 milestones and CFPB updates with them
  • Mike will follow up this Friday
  • Call with Canada Open Banking team scheduled for 3rd week of September
  • Will have outreach workshop on October 2nd or 3rd
  • Waiting for date confirmation
  • Will be hybrid workshop in Santiago to be led by John Bradley pending availability
  • Webinar in the morning for ecosystem participants
  • Q/A session for government officials in the afternoon
  • Will share details later
  • Elcio Calefi introduced OIDF to Accenture team supporting the banks association in Chile - Scheduling a meeting to address their concerns
  • Joseph and Mike met with new SAMA director on Monday Aug. 26
  • Shared with them the FAPI 2.0 status and milestones
  • Continuing to work on their FAPI2 transition plan scheduled for second half of 2025
  • Looking to partner w/OIDF on CFPB application
  • Meeting scheduled for Friday to prepare for in-person meeting in DC on September 13

Implementation acts public review will be closing this weekend - Sep 7

  • Separated out from another PR to address key compromise from Cyber Safety Review Board report
  • Approved and will merge
  • Add note that BCP195 updates periodically and that implementers are expected to be compliant with the new changes within 12 months or sooner depending on nature of change
  • Dave to remove “should be” and change to “12 months if not sooner”
  • Will merge

4.3.   PR #`#516 <https://github.com/openid/fapi/issues/516>`__ - next attempt at stateful credentials

  • Recommended implementers consider tradeoffs for stateful and stateless credentials
  • Fixed Reference to wrong RFC
  • Will merge

5.1.1.   #425 - FAPI 2.0 Purpose and FAPI WG Scope

  • Website text copied from charter which is outdated
  • Dave proposed some changes to the charter
  • Nat will confirm with OIDF consul regarding wording

5.1.2.   #621 - Implementations of FAPI2 Message Signing - Particularly HTTP Message Signatures

  • Need implementations before spec can proceed to final
  • There are many implementations except for HTTP Signing.
  • Test suite tests parts except for HTTP Signing.
  • The callers agreed to split the draft into two and move forward with the part without HTTP signatures.
  • All issues resolved
  • No disapproval for moving spec to 60 days public review
  • Will publish new revision of current spec
  • Waiting for implementations of HTTP Message Signaures to move forward
  • Authlete is ready to provide an implementation
  • Many ecosystems are also waiting for Message Signing
  • Catch 22 situation
  • There was a suggestion remove HTTP Message Signatures and put it in 1.1
  • For HTTP Message Signatgures, clients need to obtain a public key from resource server to verify signatures from resource endpoints.
  • Resource servers need to provide mechanism to obtain public keys
  • Suggested to use OAuth 2.0 Protected Resource Metadata which is not final yet
  • RS would likely need to implement OAuth 2.0 Protected Resource Metadata
  • Many ecosystems are only concerned with signing authorization requests and responses
  • HTTP Message Signatures is not a concern for now but is implemented in UK and Europe
  • Berlin Group still using the cavage draft
  • UK is using detached JWTS
  • Message Signing Spec still not address how to obtain the public keys to verify signatures, so interoperability and conformance might be a problem
  • At the moment, if conformance tests are developed, users would be expected to provide the public key as part of the configuration
  • There is a concern about OAuth 2.0 Protected Resource Metadata and usage in Federation cases and ecosystems that distribute keys from central repository
  • Proposal to separate Message Signing into 2 parts
    • Signed authorization requests and responses
    • HTTP Message Signatures
  • Dave will create an issue and PR to separate the Message Signing spec to proceed to working group last call
  • Will also need to add missing people to acknowledgements
  • Errata will go forward
  • Should start work on this guidance
  • There are issues remaining to work on
  • Related to #677 - FAPI + FedCM
  • There is a discussion about Google’s FedCM API which offers some improvements to user experiences.
  • List the user’s recently used banks instead of listing the whole list
  • But browsers are reluctant to offer such features unless there is clear demand
  • Need implementations and support for the FedCM group to demonstrate to browser that there is interest
  • Need to spread word among Fintechs and banks to show support
  • Another catch 22 situation like Sign-in with Google
  • N/A
  • No additional items raised

The meeting was adjourned after addressing all agenda items.

Clone this wiki locally