Skip to content

FAPI_Meeting_Notes_2025 08 06_Atlantic

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

FAPI Working Group Meeting Notes

Date: August 6, 2025
Time: GMT 14:00-15:00
Meeting Type: FAPI Working Group Call

Attendees

  • Nat Sakimura (Chair)
  • Mike Leszcz - OIDF
  • Filip Skokan
  • Kosuke Koiwai
  • Dima Postnikov
  • Takahiko Kawasaki
  • Peter Wallach
  • Chris Wood
  • Imran Ulghar (OBL)
  • Joseph Heenan (OIDF & Authlete)
  • Bjorn Hjelm
  • Peter Stanley
  • George Fletcher
  • Joe DeCook

Meeting Opening

Mike Leszcz opened with standard notices:

  • Code of conduct reminder - all participants to act with respect
  • Antitrust policy statement acknowledgment
  • Contribution agreement required for working group participation
  • Participation agreement required for OIDF community groups
  • All reference policies available at openid.net/policies

Agenda Adoption

Proposed agenda accepted without modifications. Agenda included roll call, events, external organizations, PRs, issues, and any other business.

Events Update

Mike Leszcz provided comprehensive 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 28-30 - 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

Mike Leszcz reported on ecosystem engagement activities:

Recent Inquiries

  1. Korea - Digital Identity Technology Standard Forum

    • Closely tied to Korean government and standards work
    • Mark Kane and Mike coordinating intro call while Gail is on holiday
    • Update expected within 1-2 weeks

  2. Peru - Peruvian Financial Authority

    • Exploring creation of open banking regulation
    • Mark Dominguez and Mike leading engagement
    • Meeting scheduled in couple of weeks

Community Groups

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

ISO Standardization Update

Nat Sakimura provided important update on ISO vote results:

Vote Results

(Confidential)

Next Steps

  • Hodari will discuss with ISO mentor on handling votes and comment
  • Likely that we need to form subgroup to address comments
  • Requires non-public meeting due to ISO process requirements
  • Special call needed with named volunteers

Member Updates

Mike Leszcz announced:

Issues Discussion

Issue #706: HTTP Message Signatures Requirements

Presenter: Takahiko Kawasaki

Problem Statement

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
  • Note: Robert unavailable today, discussion postponed to next week

Initial Reactions

Takahiko Kawasaki:

  • Supportive of M2M-only certification
  • PAR requirement main reason for FAPI 2.0 (front channel security)
  • Client credentials flow doesn't use front channel, so security rationale different
  • Would like security expert validation

Dima Postnikov:

  • Agrees with concept, makes sense
  • Previously suggested separate profile/document
  • Ended up with split sections in main profile
  • Worked for organization considering server-to-server without user interaction
  • Need formal security analysis confirmation
  • FAPI 2.0 formally proved, but researchers may not have analyzed M2M scenario

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

Presenter: Dima Postnikov

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

Discussion Points

Joseph Heenan:

  • Carried over from FAPI 1.0
  • Part of non-repudiation property
  • Provides authenticated sender/recipient and reliable timestamp
  • nbf and exp narrow down message send time window
  • nbf chosen over iat due to defined validation behavior in existing libraries

Implementation Questions:

  • Should iat (issued at) be mandated for completeness?
  • exp already mandatory and makes sense
  • iat useful for record-keeping/audit purposes
  • nbf more for runtime processing

Ecosystem Perspective

  • 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

Action Items Summary

  1. Takahiko Kawasaki: Prepare concrete text proposal for Issue #706 HTTP signatures
  2. Takahiko Kawasaki: Contact Justin for feedback on HTTP signatures approach
  3. Mike Leszcz: Coordinate non-public ISO comments meeting once Hodari provides guidance
  4. All: Provide feedback on Issue #741 NBF requirements
  5. Nat Sakimura: Follow up with Robert on Issue #740 M2M profile for next week
  6. Working Group: Request concrete use case scenarios from Mastercard for M2M certification

Next Meeting

  • Date: Next week (August 13, 2025)
  • Focus: Continue Issue #740 discussion with Robert's participation
  • Outstanding: ISO comments subgroup formation pending Hodari's guidance

Meeting Conclusion

Meeting concluded early (10 minutes returned) due to completion of agenda items and key participant unavailability for Issue #740 discussion.

Meeting adjourned at approximately 14:50 GMT

Clone this wiki locally