-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2025 12 11_Pacific
Nat Sakimura edited this page Jul 10, 2026
·
1 revision
- Anoop
- Roll Call
- Adoption of Agenda
- Events
- External Orgs & Liaisons
- PRs
- Issues
- AOB
** Events Updates ***
- March 9-13: ISO/IEC JTC 1/SC 27 Working Group Meeting – Nürnberg, Germany
- March 14-20: IETF 125 – Shenzhen, China
- March 16-17: ISO/IEC JTC 1/SC 27 Plenary – Nürnberg, Germany
Please send any 2026 events to be added to the calendar to mike.leszcz@oidf.org
- The OIDF calendar on the website and Google calendar are current and available at: https://openid.net/calendar/
- End-of-year coordination calls are being scheduled with all ecosystem partners for input into 2026 planning and budgeting
- Some meetings have been completed; others are being coordinated
- No specific ecosystem updates were reported
- December 8: Blog to be published noting nominations open with full details
- December 26: Nominations close
- December 29: 2026 elections begin
- January 12: 2026 elections conclude
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
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:
- 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
- THis PR has conflicts and recommendation is to create separate new PR for remaining minor fixes (hyphen leftovers, capitalization).