-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2025 11 26_Atlantic
Nat Sakimura edited this page Jul 10, 2026
·
1 revision
Date: 2025-11-26
Time: 14:02 UTC
Chair: Nat Sakimura
- Nat Sakimura (Chair) – joining remotely via phone, in transit
- Filip Skokan (partial attendance – left early)
- Bjorn Hjelm
- Kosuke Koiwai (assisted with screen sharing and meeting facilitation)
- Chris Wood
- Robert Gallagher (Mastercard)
- Matthew Murphy (Mastercard)
- Hideki Ikeda
- Roll Call (Dave/Nat)
- Adoption of Agenda (Dave/Nat)
- Events (Mike L.)
- External Orgs & Liaisons (Mike L.)
- PRs (Dave)
- Issues (Dave)
- AOB (Nat)
Bjorn provided an update on the ITU submission:
- FAPI 2.0 Security Profile and FAPI 2.0 Attacker Model have been submitted to ITU
- The documents will be discussed for adoption at the upcoming ITU meeting (December 3–11, 2024)
- Bjorn will attend remotely to represent the submissions (not traveling to Geneva)
- The documents were reformatted to ITU template format, similar to how OpenID Connect Core was reformatted previously
- The FAPI 2.0 specs were simpler to reformat than the larger OpenID Connect Core specification
- The main effort involved correcting references, as ITU handles normative vs. informative bibliography differently from OpenID conventions
- ITU uses "incorporation by reference" rather than standard reference formatting
Discussion: Nat noted that ITU and ISO meetings typically run long with many working items. ISO SC27 currently has 78 working items.
Kosuke Koiwai shared his screen to assist with reviewing PRs while Nat was in transit.
- Status: Has 2 approvals
- Content: Editorial changes from ISO comments (e.g., adding space between "RFC" and number)
- Discussion: Kosuke noted some leftover hyphens that were taken out in Part 2, and some capitalization inconsistencies
- Action: Nat suggested merging this PR and creating a separate issue for the remaining minor fixes (hyphen leftovers, capitalization)
- Action Item: Kosuke to create a new issue for RFC spacing inconsistencies in FAPI 1 Part 2 (e.g., BCP 195, RFC 4122 spacing)
- Status: Approved by Dave
- Content: Updates reference from preprint to the published version (IEEE)
- Notes: Non-controversial change; the published version is freely available
- Action: Needs second approval to merge
- Status: Pending review
- Content: Date and draft revision updates
- Notes: Non-controversial editorial change
- Action: Needs approval
- Status: Approved by 2 people
- Content: Removes reference to non-existent Section 4.4 of JARM
- Action: Ready to merge
- Status: Same fix as above, different document location
- Action: Needs review
- Status: Waiting for Dave to resolve conflicts
- Action: Skipped pending conflict resolution
Background:
- FAPI 1 has specific requirements for key lengths:
- RSA: 2048 bits
- Elliptic Curve: 160 bits
- These values are becoming inadequate and will be insufficient in a few years
ISO Feedback:
- Suggested referencing a living document that gets timely updates rather than hard-coding values in the spec itself
- FAPI already does this for algorithms but not for key lengths
Current Recommendations (FIPS 186-5):
- RSA: 3072 bits (vs. FAPI 1's 2048)
- Elliptic Curve: 256 bits (vs. FAPI 1's 160)
Considerations:
- Changes would impact existing ecosystems using FAPI 1
- Open Banking UK has indicated they will continue using FAPI 1 for 5–6 more years
- Other ecosystems are planning to move to FAPI 2
- BCP 195 is referenced for algorithms but doesn't provide key length guidance
- FAPI 2 comments from ISO haven't come back yet
- With FAPI 2 being submitted to ITU, key length requirements should be verified
Action Items:
- Nat to proactively reach out to Open Banking UK for their input
- Working group members to provide feedback on the issue
- Verify FAPI 2 key length requirements before ITU submission
Background:
- Discussed at the working group meeting on November 3rd/4th
- Introduced as a novel attack, but was actually discussed 2–3 years ago
- Dave has linked the full discussion thread in the issue
Technical Details:
- Involves a scenario where the user agent is taken over by an attacker
- Not much can be done in this attack scenario
- During formal analysis, the attacker's capabilities were weakened slightly to prove security
Resolution:
- May add to security considerations section
- Issue to remain open until the OAuth thread discussion is complete
Background:
- Dave sent out the registration request to IANA on November 6th
Status:
- Essentially considered done
- Waiting for IANA confirmation
- Will close once IANA confirms or requests fixes
Status:
- Similar to HTTP Message Signing registration
- Done unless IANA comes back requesting fixes
Question from Kosuke: Do we need to remove the section from the OpenID website version as well as the ISO submitted document?
Clarification from Nat:
- For the OIDF version: section should remain
- For the ISO version: section should be removed
Action: Keep issue open; task Hodari to handle during MS Word version editing
Background:
- Issue about whether conformance testing should allow non-standard TLS ports
Discussion:
- Understandable that developers might use non-standard ports for development servers
- For public-facing servers, using non-standard ports doesn't make sense
- Since FAPI certification is about real deployment testing, standard port should be required
Consensus Direction:
- Require port 443 for TLS for certification
- Open question: Should this be mandated in the spec itself?
Action: Working group members to provide opinions on the issue; will revisit next week
Background:
- Comment asking for use of RFC 9207 for IdP mix-up attack protection
Technical Context:
- RFC 9207 defines AS (Authorization Server) identifier
- The IDP mix-up attack primarily affects OAuth 2.0 servers that don't have issuer identifier
- FAPI 1 uses OpenID Connect, which already has issuer identifier
- OpenID Connect is not subject to this attack when using hybrid flow
- The issuer identifier goes into the authorization server metadata
Discussion:
- Could potentially add to security considerations
- May be relevant to FAPI 2 if not already addressed
- Formal analysis was done by the team that discovered the IdP mix-up attack, so should catch any issues
Action: Nat wants feedback from working group on whether this merits inclusion
Status: Dima is not present; skipped until next meeting
No additional business was raised.
- Nat thanked attendees for joining despite no meeting reminder being sent
- Special thanks to Kosuke for helping conduct the meeting and screen sharing
- Next meeting: Following week (regular schedule)
- Bio break before the eKYC Working Group meeting
| # | Action Item | Owner | Status |
|---|---|---|---|
| 1 | Create issue for RFC spacing inconsistencies (BCP 195, RFC 4122) in FAPI 1 Part 2 | Kosuke Koiwai | New |
| 2 | Merge PR #552 (ISO editorial comments) | Nat Sakimura | Pending |
| 3 | Approve and merge Section 4.4 reference removal PR | Editors | Ready |
| 4 | Reach out to Open Banking UK regarding key length requirements | Nat Sakimura | New |
| 5 | Verify FAPI 2 key length requirements before ITU submission | Working Group | New |
| 6 | Resolve PR conflicts | Dave | Ongoing |
| 7 | Provide feedback on non-standard TLS port issue | Working Group | By next week |
| 8 | Provide feedback on RFC 9207 (IDP mix-up attack) inclusion | Working Group | Ongoing |
| 9 | Handle section removal differentiation for ISO vs. OIDF versions | Auditor | Pending |
Next week, same time.
The OIDF Antitrust Policy is available at www.openid.net