Skip to content

FAPI_Meeting_Notes_2025 12 17_Atlantic

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

FAPI Working Group Meeting Notes

Date: 2025-12-17
Time: 14:00-15:00 UTC

Attendees

  • Nat Sakimura (Chair)
  • Dave Tonge (Co-chair) - departed at 14:30
  • Matthew Murphy (Mastercard)
  • Robert Gallagher (Mastercard)
  • Lukasz Jaromin (Raidiam)
  • Peter Stanley (Open Banking Limited)
  • Bjorn Hjelm
  • George Fletcher
  • Dima Postnikov
  • Hideki Ikeda (Authlete)

Apologies: Mike Leszcz (overlapping meeting)

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 conducted via chat. All attendees listed their names in the chat window.

2. Adoption of Agenda

Peter Stanley requested clarification on whether the key length issue raised by Imman from OBL would be discussed. Nat confirmed this would be covered.

Nat also noted that since Dima was present, they could discuss issues around client credential flow.

Agenda adopted with no other additions.

3. Events

Mike Leszcz provided updates via notes (shared in chat by Nat):

Q1 2026 Events

  • March 9-13, 2026: ISO/IEC JTC 1/SC 27 WG Meeting - Nürnberg, Germany
  • March 14-20, 2026: IETF 125 - Shenzhen, China
  • March 16-17, 2026: ISO/IEC JTC 1/SC 27 Plenary - Nürnberg, Germany

All Q1 2026 internal meetings and industry events have been added to calendars.

Q2-Q4 2026 meetings and events to be added to calendars and website this week.

Members were encouraged to send any 2026 events to be added to the calendar to mike.leszcz@oidf.org.

4. External Organizations & Liaisons

Ecosystem Engagement

End-of-year coordination calls with all ecosystem partners for input into 2026 planning and budgeting are well underway.

Member Reminders

  1. HAIP 1.0 Vote: Notice of Vote to Approve Proposed OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0 Final Specification. Voting open through December 23rd.

  2. Authorization API 1.0: Public Review Period for Proposed Authorization API 1.0 Final Specification through Monday, December 22nd. Vote announcement published with voting opening Tuesday, December 23rd.

  3. 2026 OIDF Board Elections: Board elections have begun with nominations open through December 26th.

No additional updates from other participants on external organizations and liaisons.

5. Pull Requests

Dave Tonge led the PR discussion.

PR #559

  • Link: https://bitbucket.org/openid/fapi/pull-requests/559
  • Status: Kosuke raised some issues on this PR
  • Details: Nat noted the issues are purely editorial (e.g., missing space between RFC and 8705)
  • Action: Nat will work on these editorial fixes, likely the week after due to time constraints
  • Note: Dave acknowledged everyone is quite time-pressed

PR #558

Dave noted there are no other PRs ready to look at apart from these two.

Dave departed the meeting at 00:29:38 (acknowledged by Peter Stanley with a thumbs up reaction).

6. Issues

Issue #778: Key Length Requirements

Link: https://github.com/openid/fapi/issues/778

Background: This issue was raised by Imman from Open Banking Limited regarding key length requirements, specifically related to ISO/IEC 25791-1 review comments.

Discussion Summary

Context:

  • ISO review comments suggested updating RSA key lengths from 2048 bits to 3072 bits
  • Current FAPI 1.0 Part 1 Advanced (Section 8.6) states: "shall use 2048-bit or longer keys"
  • Question: Should the specification be updated to reflect newer cryptographic recommendations?

Key Points Raised:

  1. Nat's Position:

    • Reluctant to change FAPI 1.0 at this point
    • FAPI 1.0 has been finalized and is widely deployed
    • Changing the specification could create compatibility issues with existing implementations
    • Any change would require a new version (e.g., FAPI 1.1) rather than modification of current version
    • Suggested approach: Issue an errata or informational note rather than changing the normative requirement

  2. Peter Stanley's Feedback (from Open Banking Limited):

    • OBL is not planning to mandate 3072-bit keys in the near term
    • Acknowledged that 2048-bit keys are still considered secure for the foreseeable future
    • Agreed with not rushing to update the specification

  3. Discussion on Approach:

    • Consensus that ecosystems should be free to set more restrictive requirements than the specification
    • For example, UK Open Banking or other ecosystems could mandate 3072-bit keys in their profiles
    • The specification should set minimum requirements, not dictate all ecosystem choices
    • Question raised: Should the specification explicitly allow ecosystems to set stricter requirements?

  4. George Fletcher's Comments (via chat at 00:42:35):

    • An errata statement that is editorial makes sense
    • Ecosystems should have the ability to set their own more restrictive profiles
    • Updating the spec should only be required if there are known attacks against explicitly permitted key-lengths/algorithms
    • Future version of the spec could reference something that tracks algorithms that MUST NOT be supported
    • Ecosystems should probably be able to set their own rules

  5. Lukasz Jaromin's Query:

    • Asked for clarification: "FAPI 1.1?" (in chat at 00:21:51)
    • Confirmed understanding with smile emoji

Proposed Resolution

The group leaned toward:

  1. Not updating FAPI 1.0 Part 1 Advanced to change the 2048-bit requirement
  2. Issuing an errata or informational note that:
    • Acknowledges current best practices recommend 3072-bit keys
    • Clarifies that ecosystems may set more restrictive requirements
    • Notes that 2048-bit keys remain secure but 3072-bit is preferred for new implementations
  3. Future consideration: Any substantive change would be addressed in a future version (FAPI 1.1 or FAPI 2.0)

Action Items:

  • Group to finalize approach for addressing ISO comments without breaking existing implementations
  • Consider drafting errata statement for review

Client Credentials Flow Discussion

Background: Dima and the Mastercard team have been working through conformance testing for FAPI 2.0 client credentials (machine-to-machine) scenarios.

Summary of Findings

Dima provided an extensive update on conformance testing work:

  1. Reference to Incorrect OpenID Connect Discovery:

    • FAPI specification may be referencing an incorrect OpenID Connect discovery document
    • The link needs to be double-checked and potentially updated in the FAPI spec

  2. Conformance Testing Questions:

    • Multiple questions have been identified that need clarification from the conformance testing team
    • Some requirements appear to be enforced in tests, but the source specification is unclear
    • Need to determine if test cases come from specifications or from separate conformance team discussions

  3. OpenID Connect Discovery Endpoint Requirement:

    • Current tests expect an OpenID Connect discovery endpoint
    • This requirement may not be necessary for system-to-system interactions (client credentials flow)
    • Potential adjustment needed: Tests should not fail if discovery endpoint is absent for machine-to-machine scenarios
    • Dima noted this makes sense as a potential adjustment

  4. Metadata Distribution Requirement:

    • FAPI 2.0 general requirements for authorization service states: "shall distribute discovery metadata via metadata document as specified in OpenID discovery and OAuth server metadata"
    • Current wording is "a little bit vague" but uses "shall"
    • May need to wordsmith this requirement for more clarity if this issue is resolved

Nat's Input on OAuth vs. OpenID Connect Discovery

Nat provided background information from a conversation with Joseph (in Japan time):

  1. Current Conformance Suite Status:

    • Current conformance suite does not support OAuth authorization server metadata discovery (the well-known metadata document)
    • Once OAuth authorization server metadata is supported in the conformance suite, Mastercard testing should be fine

  2. Historical Context - Audience Parameter:

    • OAuth didn't historically have an issue with the audience parameter
    • OpenID Connect has always had this issue
    • In OpenID Connect, the specification says the audience "should be" (not "must be") the token endpoint URL
    • This is further constraining the issuer

  3. Challenge with Changing OpenID Connect Spec:

    • Changing the audience requirement in OpenID Connect to use the issuer URL (instead of token endpoint) might be a hard ask
    • This would be relaxing a requirement, not tightening it
    • May change the security posture
    • Nat provided this as background information for context

Lukasz Jaromin's Interest

Lukasz asked where he could read more about this issue:

  • Dima explained it's currently documented in an email thread (not yet logged as an issue)
  • Dima offered to forward the email to anyone interested in the background
  • Individual issues will be logged separately as they are clarified
  • Lukasz commented that client credentials is a good direction as "this was kind of not precisely addressed, always, right?"

Matthew Murphy's Note

Matthew Murphy (Mastercard) indicated that Robert Gallagher was having technical difficulties and couldn't unmute to respond to questions.

Nat encouraged the Mastercard team to chime in as appropriate once issues are clarified.

Action Items

  1. Conformance Team: Answer pending questions from Mastercard about test case sources and requirements
  2. FAPI WG:
    • Dima will raise separate tickets in Bitbucket as issues are clarified
    • Review and potentially update FAPI 2.0 metadata distribution requirements for clarity
    • Consider adjusting OpenID Connect discovery requirement for client credentials scenarios
  3. OpenID Connect WG:
    • Background discussion needed on audience parameter handling
    • Consider implications of any changes to existing requirements

Status: Not ready for resolution; waiting on conformance team answers before bringing specific issues back to FAPI WG.

7. Any Other Business

No additional business was raised.

Nat noted this would be the last FAPI Working Group call of the year.

Closing Remarks

  • Nat: Thanked everyone for joining and for the lively discussion
  • Nat: Wished everyone "Happy Holidays" and said "See you guys in the new year"
  • Various participants: Exchanged "Merry Christmas" greetings

Meeting adjourned at approximately 00:59:00.

Action Items Summary

  1. Nat Sakimura:

    • Address editorial comments from Kosuke on PR #559 and #558 (likely week after meeting)
    • Draft errata statement approach for Issue #778 (key length requirements)

  2. Conformance Team (via Joseph):

    • Answer Mastercard's questions about conformance test requirements and sources
    • Consider supporting OAuth authorization server metadata in conformance suite

  3. Dima Postnikov:

    • Follow up with conformance team on outstanding questions
    • Log individual issues in Bitbucket as items are clarified
    • Coordinate with OpenID Connect Working Group on audience parameter discussion

  4. FAPI Working Group:

    • Finalize approach for key length issue (Issue #778) - errata vs. specification change
    • Review metadata distribution requirements in FAPI 2.0 for clarity
    • Consider OpenID Connect discovery requirement adjustments for client credentials flow

  5. All members: Submit 2026 events to mike.leszcz@oidf.org for calendar inclusion

Links Referenced

Next Meeting

Next FAPI Working Group meeting will be in the new year (2026).

Meeting notes compiled from VTT transcript and chat log. Note: Some timestamps reference the recording time offset (MM:SS format from start of recording).

Clone this wiki locally