Skip to content

FAPI_Meeting_Notes_2026 01 14_Atlantic

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

FAPI Working Group Meeting Notes

Date: 2025-01-14
Time: 14:00 UTC
Chairs: Nat Sakimura, Dave Tonge

Attendees

  1. Christopher Robbertse (OBL)
  2. Kosuke Koiwai (KDDI)
  3. Nat Sakimura (Chair)
  4. Hideki Ikeda (Authlete)
  5. Mike Leszcz (OIDF)
  6. Dave Tonge (Co-chair)
  7. Matthew Murphy (Mastercard)
  8. Imran Ulghar (OBL)
  9. Robert Gallagher (Mastercard)
  10. Bjorn Hjelm (Yubico)
  11. Joseph Heenan (OIDF & Authlete)
  12. Filip Skokan (Okta)

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. Discussions around OpenAPI.
  7. Issues (Dave)
  8. AOB (Nat)

1. Roll Call

Attendees recorded their names in the chat. The meeting started approximately 4 minutes past the hour.

2. Adoption of Agenda

Two additional topics were proposed for inclusion:

  1. Issue #835 (Mastercard): Robert Gallagher raised an issue regarding TLS 1.2 cipher suite testing failures, specifically related to ChaCha20-Poly1305. Mike Leszcz confirmed that Robert is covered by MasterCard's existing Working Group contribution agreement.

  2. FAPI in OpenAPI (OBL): Chris Robbertse requested discussion about integrating FAPI into OpenAPI as a security standard. This was added as a general discussion topic.

The agenda was adopted with these additions.

3. Events

Mike Leszcz provided the following updates:

Q1 2026 Events

  • Q1 2026 internal meetings and industry events have been added to all calendars
  • March 9-13: ISO/IEC JTC 1/SC 27 WG Meeting - Nürnberg, Germany
  • March 14-20: IETF 125 - Shenzhen, China
  • March 16-17: ISO/IEC JTC 1/SC 27 Plenary - Nürnberg, Germany

Calendar Updates

  • Q2-Q4 2026 meetings and events to be added to calendars this week as they have been confirmed
  • OpenID events will be hosted adjacent to spring and fall IIWs (traditionally working group meetings in the morning followed by a workshop in the afternoon on the Monday prior to IIW)
  • Contact: mike.leszcz@oidf.org for any 2026 events to be added to the calendar

4. External Organizations & Ecosystem Engagement

Mike Leszcz provided updates on ecosystem engagement activities:

Chile/CMF

  • Plan to have regulation in place in August 2026
  • Anticipate a few FAPI2 certifications in 2026 with ecosystem going live in earnest in early 2027
  • Minstait is CMF's implementation partner and may join the Foundation in place of CMF to provide directed funding

SAMA (Saudi Arabia)

  • Anticipate directed funding early 2026 to support new KSA FAPI2 Profile
  • Ecosystem will then certify to the new profile

UAE

  • Follow-up call scheduled for mid-January to discuss transition from FAPI2 ID to FAPI2 Final

OFB & OPIN (Brazil)

  • 2026 certification confirmed

Peru

  • Intro call scheduled for January 14, 2026
  • Domingos has made introductions to OFB and CMF
  • Peru's implementation partner is Minstait (same as Chile)
  • Minstait anticipated to become a member of the OpenID Foundation in early 2026 to provide directed funding for Chilean and Peruvian ecosystems

Member Reminders

  1. Authorization API 1.0 Final Specification Approved: https://openid.net/authorization-api-1-0-final-specification-approved/

  2. 2026 Board of Director Elections: Results announced - https://openid.net/2026-openid-foundation-board-of-directors-election-results/

  3. Public Review Period: OpenID Connect Relying Party Metadata Choices 1.0 Final Specification

5. Pull Requests

Dave Tonge reviewed several PRs related to the FAPI Implementation Advice document:

PR #542 - Implementation Advice

PR #541 - Authorization Server Rejecting Nonce or State

  • Link: https://bitbucket.org/openid/fapi/pull-requests/541

  • Summary: Provides guidance on how authorization servers should handle suspicious parameter values in state and nonce

  • Key Recommendations:

    • Authorization servers MAY reject requests containing suspicious parameter values that could indicate malicious intent (such as potential XSS attack vectors)
    • Authorization servers SHOULD NOT have blanket restrictions like blocking certain characters
    • Authorization servers SHOULD accept any random state/nonce values that comply with underlying specs
    • Authorization servers SHOULD use appropriate error codes when rejecting requests
    • Clients SHOULD use URL-safe characters when generating state or nonce values
    • If clients need to include non-URL-safe characters, they SHOULD Base64 URL encode them

  • Status: Recently updated, not merging immediately

  • Action: Reviewers requested to leave comments or approvals

PR #560 - Key Management Guidance

  • Link: https://bitbucket.org/openid/fapi/pull-requests/560

  • Related Issue: #734

  • Summary: Adds a new section on key management best practices

  • Key Content:

    • Acknowledges that key management is out of scope for FAPI but addresses the gap of not mentioning it at all
    • Recommends having good policies and procedures
    • References NIST guidelines and OWASP Key Management Cheat Sheet
    • Recommends HSMs or similar secure key storage mechanisms for production environments

  • Status: Not merging today, requesting review

  • Action: Reviewers requested to provide feedback

PR #540 - DPoP vs MTLS Considerations

  • Link: https://bitbucket.org/openid/fapi/pull-requests/540

  • Summary: Reworked to provide balanced considerations for both DPoP and MTLS approaches

  • Key Content:

    • Presents considerations around DPoP
    • Presents considerations around MTLS
    • Provides examples of when MTLS may be more suitable
    • Provides examples of when DPoP may be more suitable

  • Status: Previous version had recommendations that generated extensive discussion; now reworked to be more balanced

  • Action: Reviewers requested to review and leave comments for discussion at next meeting

6. General Discussion: FAPI in OpenAPI

Chris Robbertse (on behalf of Pete from OBL) raised the question of whether there has been progress toward integrating FAPI into OpenAPI as a security standard.

Discussion Points

  • Dave Tonge noted that OAuth 2.0 can already be specified as a mechanism in OpenAPI specs, and routes can specify bearer token requirements
  • Chris acknowledged uncertainty about what specific FAPI integration would look like beyond the existing OAuth 2 capabilities
  • Dave suggested opening an issue to capture the discussion and requirements more formally
  • There was historical discussion with people behind the OpenAPI specs, but the specific differentiators from current OAuth 2 mechanisms are unclear

Action Item

  • Chris Robbertse: To follow up with more specific questions and potentially open an issue for further discussion

7. Issues

Issue #835 - TLS 1.2 ChaCha20-Poly1305 Cipher Suite

Background

MasterCard encountered a conformance test failure when using the ChaCha20-Poly1305 cipher suite with TLS 1.2. The test fails because ChaCha20-Poly1305 is not one of the four cipher suites specifically recommended in BCP-195.

MasterCard's Position

Robert Gallagher presented MasterCard's position:

  1. ChaCha20-Poly1305 is an IETF-approved cipher (RFC 7539, RFC 7905 for TLS 1.2)
  2. It is explicitly included in TLS 1.3 (so no issue there)
  3. It has been in active use for approximately 10 years (written in 2008)
  4. It fits the AEAD cipher type that BCP-195 recommends
  5. BCP-195 uses "recommended" language, not "required" or "mandatory"
  6. MasterCard's view is that you can meet the BCP priority requirements (supporting the four recommended ciphers in the specified order) while also supporting ChaCha20-Poly1305

Technical Discussion

Filip Skokan provided historical context:

  • In FAPI 1.0, specific cipher suites were listed explicitly
  • These were carried over to FAPI 2.0 initially
  • The spec was later changed to reference BCP-195 rather than listing specific ciphers
  • The conformance suite currently checks for only the four recommended ciphers

Joseph Heenan explained the test suite perspective:

  • TLS 1.3 support is now fully implemented in the conformance suite
  • The problematic language in FAPI 2 states: "Authorization servers and resource servers shall follow the recommendations"
  • This "shall follow the recommendations" effectively upgrades the BCP recommendations to requirements for FAPI conformance
  • The IETF updated BCP-195 but did not add ChaCha20-Poly1305 to the recommended list, despite the cipher existing for 7+ years at that point
  • There's also an interoperability concern: if servers only supported ChaCha, it could cause compatibility issues

Additional Context from Joseph Heenan:

  • One reason organizations want to use ChaCha20-Poly1305 is that ARM Android devices don't offer hardware acceleration for AES but do for ChaCha
  • This provides better performance and battery life on mobile devices
  • ChaCha is reported to provide similar security levels, though the working group lacks cryptographic expertise to formally validate this

Proposed Resolution Approaches

Several approaches were discussed:

  1. Filip Skokan's suggestion: Change the conformance suite to check for interoperability (ensuring at least one of the four ciphers works) rather than failing if additional ciphers are supported. This would separate the interoperability test from the allowed-cipher test.

  2. Dave Tonge's suggestion: Have MasterCard send a message to the IETF TLS working group mailing list asking if ChaCha20-Poly1305 is recommended under BCP-195 (or at least equivalent to the lowest-ranked of the four recommended ciphers). If the IETF confirms, the cipher could be added to the allow list.

  3. Joseph Heenan's perspective: The working group should consider both allow lists (ciphers that are acceptable) and deny lists (ciphers that should definitely be rejected). Getting IETF confirmation would help "offload the responsibility" for the cryptographic security assessment.

Consensus and Action Items

The working group agreed that:

  • The group lacks the cryptographic expertise to independently assess ChaCha20-Poly1305's security equivalence
  • External validation from IETF would be valuable
  • The question to IETF should be: "Is ChaCha20-Poly1305 equivalent in security to at least the lowest-ranked of the four currently recommended TLS 1.2 cipher suites in BCP-195?"

Action Items:

  1. Robert Gallagher (Mastercard):

    • Reach out to the IETF TLS working group (potentially via mailing list or through MasterCard contacts who may already be members)
    • Ask whether ChaCha20-Poly1305 should be considered equivalent to the recommended ciphers
    • Share the inquiry and any responses back to the FAPI working group
    • Reference RFC 7905 (which approves ChaCha20 for TLS 1.2) in the inquiry

  2. Dave Tonge: Add notes to Issue #835 summarizing the discussion and agreed approach

  3. Working Group: If no response is received from IETF, the group will leverage its network of contacts to try to elicit a response

8. Any Other Business

No additional business was raised.

Meeting Adjourned

The meeting concluded approximately 7 minutes early at 13:53 UTC.

Action Items Summary

# Action Item Owner Status
1 Merge PR #542 after the call Dave Tonge Pending
2 Review PR #541 (state/nonce handling) All members Open
3 Review PR #560 (key management) All members Open
4 Review PR #540 (DPoP vs MTLS) All members Open
5 Follow up with specific questions about FAPI in OpenAPI; consider opening an issue Chris Robbertse Open
6 Contact IETF TLS working group regarding ChaCha20-Poly1305 equivalence to BCP-195 recommended ciphers Robert Gallagher Open
7 Add discussion notes to Issue #835 Dave Tonge Open
8 Share IETF inquiry and responses with the working group Robert Gallagher Open

Reference Links

Next Meeting

Weekly FAPI Working Group call - January 21, 2026

Clone this wiki locally