Skip to content

FAPI_Meeting_Notes_2025 04 16_Atlantic

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

FAPI Working Group Meeting Notes (2024-04-16)

  • Date & Time: 2024-04-16 14:00 UTC
  • Location: Zoom

Attendees

  • Nat Sakimura (Chair)
  • Dave Tonge (Chair)
  • Peter Wallach (Mastercard)
  • Hideki Ikeda
  • Imran Ulghar (OBL)
  • Kosuke Koiwai
  • Filip Skokan
  • George Fletcher
  • Joseph Heenan (OIDF & Authlete)
  • Kelley Burgin

Regrets

  • Mike Leszcz

1. Roll Call

  • Attendance taken at the beginning of the meeting.

2. Agenda Adoption

Agenda was posted in the chat and adopted without changes:

  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)

3. Events

Mike L. was not present, but sent the event updates:

OIDF calendar on website is current (as is the OIDF Google calendar): https://openid.net/calendar/

4. External Orgs & Liaisons

Nat mentioned there is a spreadsheet created by Dima to track different ecosystems. Nat plans to use this information in an EIC session as a report. Kosuke requested information about the number of participants (both OP and RP sides) for each ecosystem. Joseph noted that in the UK there are at least 40 banks live, not just the CMA 9, but only the CMA 9 are mandated to certify. Nat suggested potentially adding number of users as well.

5. Member Reminders

6. Pull Requests (Dave)

Dave discussed several PRs:

PR 538 - Message Signing and JARM

  • Finally received review feedback for the message signing specification, trying to start public review process
  • Both specifications need abstracts now
  • For FAPI Message Signing: "OIDF FAPI 2.0 Message Signing is an API security profile that provides interoperable support for non-repudiation across OAuth 2.0 based requests and responses."
  • For JARM: "This specification defines a JWT-based mode for encoding OAuth 2 authorization responses that allows clients to receive authorization response parameters in a signed and optionally encrypted JWT format, providing enhanced security through message integrity, sender authentication, audience restriction, and protection from mixup attacks."
  • Some process changes: JARM will be published as a new draft first, then as an errata once approved

PR 539 - Large Access Tokens

  • Added text regarding security and performance issues with large access tokens
  • Kosuke noted that the text implies ATs are JWTs, which may not always be the case
  • George suggested replacing "claims" with "elements" to avoid implying JWTs
  • George also suggested adding information about logging header size to preemptively troubleshoot issues
  • Dave agreed that as this is deployment advice, they should make it as helpful as possible without being too strict

PR 540 - DPoP vs MTLS

  • Discusses considerations for choosing DPoP or MTLS

  • DPoP considerations:

    1. DPoP operates at application layer rather than transport layer
    2. DPoP requires cryptographic operations for each request (performance implications)
    3. DPoP introduces protocol complexity
    4. DPoP is the only viable option for browser-based clients

  • MTLS considerations:

    1. MTLS amortizes cryptographic operations cost by performing them during TLS handshake
    2. MTLS presents integration challenges at transport layer, especially at scale
    3. MTLS implementations may encounter interoperability issues

  • Draft guidance suggests MTLS makes more sense for closed ecosystems with existing PKI infrastructure, others should consider DPoP

  • Joseph (who missed last week's discussion) noted that MTLS fully protects the request while DPoP only provides partial signature

  • Extensive discussion about the complexities of MTLS in production environments, especially with proxies and load balancers

PR 541 - State/Nonce Parameter Values

  • Discussion about authorization servers rejecting suspicious state/nonce values
  • Extensive discussion about URL-safe characters in state and nonce parameters
  • George suggested recommending that clients use only URL-safe values
  • Joseph mentioned that RFC 6749 defines which characters are legal in state
  • Kosuke referenced section 10.14 of RFC 6749 which states that "The authorization server and client MUST sanitize (and validate when possible) any value received -- in particular, the value of the 'state' and 'redirect_uri' parameters"
  • Discussion about what "sanitize" means in this context
  • Joseph opened an issue against OAuth 2.1 for clarification: https://github.com/oauth-wg/oauth-v2-1/issues/209
  • Concerns about log injection attacks with unsafe characters

PR 542 - x-fapi Headers

  • Added note that clients may reuse the same interaction ID across related requests within a single authorization code flow
  • Added definition for X-FAPI-End-User-Present header to be "true" or "false"
  • Discussion that this is not a security feature and servers must trust clients
  • George noted that this has limited value outside of regulated ecosystems where there is recourse against clients falsifying data

7. AOB

No additional business was raised.

The meeting ended 3 minutes early.

Clone this wiki locally