Skip to content

FAPI_Meeting_Notes_2025 08 21_Pacific

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

FAPI WG Agenda & Meeting Notes (2025-08-21)

Date & Time: 2025-08-21 17:00 PST

Attendees

  • Anoop
  • Dima
  • Mark
  • Nat

Agenda

  1. Roll Call
  2. Adoption of Agenda
  3. Events
  4. External Orgs & Liaisons
  5. PRs
  6. Issues
  7. AOB

2. Events Update

Upcoming Events

  • 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 after lunch workshop prior to IIW
    • Date updated from original schedule
    • Host venue changed from Microsoft to Cisco, then back to Microsoft
    • Working to finalize details before opening registration (expected within 1-2 weeks)
    • DCP working group meeting scheduled morning of same day
  • October 23 - IIW Fall 2025, Mountain View
  • November 1-7 - IETF 124, Montreal

Calendar Status

  • OIDF Google Calendar and website calendar are current and up to date

External Organizations & Ecosystems

  1. Inquiries from Peru/Korea Digital Identity Technology Standard Forum on Open Banking

ISO Standardization Update (Nat)

Community Groups

  • Ecosystem Support Community Group kicked off
  • Next meeting: Thursday, August 14th (US) / Friday, August 15th (Australia/APAC)
  • Details available on OIDF website

Member Updates

JARM Errata Corrections - Vote approved earlier this week - Nat, Dave, Dima, and Joseph have email regarding updates - Updated spec links needed for publication announcement

Shared Signals Spec Vote - Delayed from August 11th to August 15th - Working group scheduling extraordinary meeting to address feedback - Link shared: https://openid.net/public-review-period-for-proposed-three-shared-signals-final-specifications/

Issues Discussion

Issue #706: HTTP Message Signatures Requirements

Current specification requires signature;req and signature-input;req in HTTP signatures for FAPI, but implementation challenges exist:

  1. Current Requirement: Resource server must include signature;req when signing HTTP responses
  2. Challenge: Specification doesn't specify key parameter, potentially including intermediary signatures
  3. Security Risk: If intermediaries add signatures, signature verification fails between client and resource server due to different signature bases

Proposed Solutions

Takahiko presented two options:

  1. Remove completely - signature;req and signature-input;req requirements
  2. Add key parameter - Specify client signature label to exclude intermediary signatures

Recommendation

Option 2 preferred to maintain original security intention while ensuring implementability:

  • Use key parameter to specify client signature label
  • Exclude intermediary signatures that may be added in transit
  • Modify specification clause to include key parameter requirements

Next Steps

  • Takahiko to prepare concrete text proposal
  • Will contact Justin (original author) for feedback
  • Group agreed concrete proposal would help understanding

Issue #740: M2M FAPI Conformance Profile

Context: Request from Mastercard for machine-to-machine FAPI certification

Background

  • FAPI 2.0 split into base core (authorization/resource server interactions) and optional authorization code flow section
  • Mastercard implemented FAPI 2.0 with client credentials grant only
  • No current certification profiles exist for M2M-only implementations

Questions Raised

  • User Authorization: In M2M scenario, no user authorization occurs
  • Use Cases: Machine-to-machine with user identity passed in context (not in tokens)
  • Security Analysis: Need confirmation no security controls compromised

Action Items

  • Request concrete use case scenarios from Mastercard
  • Await Robert's availability for detailed discussion
  • Consider security analysis requirements

Issue #741: NBF Claim Requirements

Question

Is nbf (not before) claim mandatory in request objects or just useful?

Current State

  • Specification currently states nbf is "shall" (mandatory)
  • Unclear why this requirement exists in current context

Context Analysis

  • FAPI 1.0: More reliant on nbf due to different security model

  • FAPI 2.0: Uses PAR (Pushed Authorization Requests) mandatory, reducing nbf necessity

  • Use Cases: Some clients may have pre-shared request objects requiring nbf

  • Current ecosystem participants don't have strong nbf requirement

  • Questions arising from parties implementing from scratch

  • May be more relevant for specific use cases with pre-shared request objects

  • Multiple implementation questions arising from parties building from scratch rather than using existing libraries

Next Steps

  • Leave open for additional participant feedback
  • Consider relationship between nbf, iat, and exp requirements
  • Evaluate necessity in FAPI 2.0 context with mandatory PAR

Clone this wiki locally