Skip to content

FAPI_Meeting_Notes_2025 04 09_Atlantic

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

OpenID Foundation FAPI Working Group Meeting Notes

Meeting Information

  • Date: April 9, 2025
  • Time: Standard weekly meeting time
  • Chairs: Nat Sakimura, Dave Tonge

Attendees

  • Peter Stanley
  • Hideki Ikeda
  • Peter Wallach (Mastercard)
  • Kosuke Koiwai
  • Nat Sakimura
  • Jake Fenley
  • Robert Gallagher (Mastercard)
  • Dave Tonge
  • Imran Ulghar (OBL)
  • Bjorn Hjelm
  • Filip Skokan
  • Brian Campbell
  • Dima Postnikov

Agenda

  1. Roll Call (Dave/Nat)
  2. Adoption of Agenda (Dave/Nat)
  3. Events (Mike L.)
  4. External Orgs & Liaisons (Mike L.)
  5. PRs (Dave)
  6. Issues (Dave)
  7. AOB (Nat)

1. Roll Call

  • Roll call was conducted through the chat window.

2. Adoption of Agenda

  • Standard agenda was adopted without changes.

3. Events

  • OpenID Foundation workshop was held this week in Sunnyvale
    • Bjorn reported it was well-attended
    • Joseph had three presentations: ECP, Conformance, and FAPI
  • Identity Assurance Workshop (IAW) is still ongoing

4. External Organizations & Liaisons

  • The OpenID Foundation board agreed to upgrade liaison relationships with ISO/IEC JTC1 SC17 and SC27 from Category C to Category A
    • The foundation already has Category A liaison status with TC68 (Financial Services)
    • This will provide more opportunities for comments and participation, including the ability to become project leaders
    • No foreseen problems with the upgrade

5. PRs (Pull Requests)

  • No PRs to review at this meeting
  • Dave waiting for feedback on FAPI JARM and FAPI Message Signing specs
    • Nat mentioned Mark has been sick for two weeks, which may be causing the delay
  • Dave started work on updated content for implementation advice documents
    • Expects to have PRs ready for next week

6. Issues

Issue #290: X-FAPI-Interaction-ID across client to AS

  • Previously discussed in both Atlantic and Pacific calls
  • Dima recorded notes with three separate decisions
  • Pacific call is in agreement with the assessment
  • Anyone with additional input should add to the issue

Issue #726: Create an ecosystem comparison table

  • Dima started a Google doc (not yet shared with everyone)
  • The purpose is to compare FAPI ecosystems around the world
    • Partly to prepare for a presentation slot at EIC about FAPI ecosystems
    • Will help gather data on similarities, differences, and potential shortcomings
  • Peter Stanley volunteered to contribute information about the UK ecosystem

Issue #537: Document trade-offs between DPoP and MTLS

  • Discussion on pros and cons:

    • DPoP advantages:
      • Works at application layer, no need to worry about transport layer
    • MTLS advantages:
      • Amortizes the cost of large asymmetric cryptographic operations during TLS handshake
      • Reuses that cost over the session vs. DPoP's cryptographic operation on every request

  • Brian Campbell noted:

    • Replayability concerns with DPoP are relatively minor and occur in obscure scenarios
    • MTLS is conceptually simpler but has complex implementation challenges:
      • Different ports or host names
      • Server name extensions
      • Load balancer configurations

  • Filip Skokan added:

    • Both have specific implementation challenges
    • MTLS challenges:
      • Certificate aliases
      • Self-signed certificates require JWKS from client
      • X.509 in JWK has interoperability issues
      • Distinguished name matching for PKI rotations
    • DPoP challenges:
      • URL normalization issues
      • Some APIs (like older PHP ones) where action is specified in query string, which "htu" strips out

  • Consensus:

    • Choice depends on context:
      • Banks with existing PKI infrastructure might prefer MTLS
      • Greenfield projects that need broader interoperability might prefer DPoP
      • Projects needing to support public/browser-based clients must use DPoP as MTLS isn't possible
    • Even banks with MTLS infrastructure often implement application-level security as well
    • Dave will draft wording to document these considerations

Issue #223: Need of a customer unique immutable identifier

  • Old issue from 2019 regarding UK Open Banking implementation

  • Problem: UK Open Banking was using consent IDs in the subject field of ID tokens

    • Consent IDs change every 90 days, breaking persistent user identification
    • Makes re-authorization flows problematic

  • Australia's approach (per Dima):

    • Uses pairwise unique identifiers (PPID) in ID tokens
    • Currently no re-authorization flows in Australia (full flow required when consent expires)
    • Consents valid for up to 12 months
    • PPID allows relying parties to recognize returning users
    • Allows authentication-only flows for returning users

  • Limitations of PPID:

    • Can change with bank mergers, technical upgrades, infrastructure changes

  • Dave will add content to the deployment advice document about using PPID or similar identifiers

New Issue #727: MCP servers scope and RAR

  • Discussion about rich authorization requests (RAR) vs. scopes for AI/MCP context

  • Brian Campbell's perspective:

    • OAuth scopes are well-suited for AI use cases
    • OAuth fundamentally addresses delegating consent to software to do something limited in scope
    • This is exactly what's needed for AI systems
    • RAR wasn't designed for broad adoption but for specific ecosystems
    • Should start with proven OAuth approaches before inventing new solutions

  • Dima's perspective:

    • Agrees we should evaluate existing tools first
    • OpenID Foundation has authorized work to bring AI and identity communities together
    • Fine-grained authorization is critically needed
    • Current implementations (like Australia's) grant too broad access

  • Action:

    • Avoid fragmentation by amplifying consistent voices
    • Dima will share information about the OpenID Foundation white paper group working on this topic

7. AOB (Any Other Business)

  • Nat proposed electing Dima Postnikov as an additional co-chair of the FAPI working group
    • Dave expressed support
    • Dima could host Pacific calls when Anoop is unavailable
    • Provides good geographic balance
    • Nat will send the proposal to the mailing list

Next Meeting

  • Regular weekly schedule

References

Clone this wiki locally