1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi

Wiki

Clone wiki

fapi / FAPI_Meeting_Notes_2024-05-15_Atlantic

View History

FAPI WG Agenda & Meeting Notes (2024-05-15)

The meeting was called to order at 14:05 UTC.

1.   Roll Call (Nat)

  • Attendees: Robert Gallagher, Nat Sakimura, Peter Wallach, Kosuke Koiwai, Lukasz Jaromin, Daniel Fett, Mike Leszcz, Riffaat Shekh-Yusef, Marko Milch, Chris Wood, Dave Tonge, Joseph Heenan, Hideki Ikeda, Bjorn Hjelm, Mark Andrus, Brian Campbel, Domingos Creado< Ralph Bragg, Marko Milich
  • Regrets:

2.   Adoption of agenda (Nat)

  • The default agenda adopted.

3.   Events (Mike L.)

3.1.   Identiverse

  • May 28-31 in Las Vegas – OIDF is planning to have breakout room if the WG is interested in meeting
  • FAPI WG is confirmed for F2F meeting on Wednesday, May 29, 2024 7-8am PT in Bluethorn 8 on the same level as the expo floor. Mike Leszcz sent a message to the FAPI mail list last week requesting those that plan to attend in person respond to that message. Mike will send a reminder this week. Virtual participants will use the standard FAPI WG Zoom session.

3.2.   EIC

  • June 4-7 in Berlin. OIDF Workshop on June 4.

3.3.   Open Banking Expo Canada

3.4.   OIDF Workshop Fall

  • OIDF workshop in the Mountain View area on Monday, October 28th prior to IIW. Location yet to be determined.

3.5.   OAuth WG Interim

  • Interim. Slides and recordings available. FedCM, OAuth 2.1 already covered. * Next week: Attestation-based OAuth Client, * June 4: PICA, * June 11: Token revocation, Token status list, etc.

3.6.   FIDO Alliance OSAKA

  • FIDO Alliance will have the seminar and plenary on the week of May 20, so plenty of identity people will be around Osaka, Japan in that week.

4.   External Orgs & Liaisons (Mike L.)

4.1.   Brazil

  • OFBR - Continuing to process FAPI recertification requests for Open Finance Brazil ecosystem.
  • OPIN – Open Insurance Brazil requested keeping old FAPI profile available alongside new FAPI profile for a few months, expected to take 2-3 weeks to implement. Domingos leading efforts.

4.2.   UAE

  • Domingos is leading the analysis of the draft FAPI profile with the Raidiam technical team, awaiting next draft from Raidiam.

4.3.   Chile

  • Follow up call with Chilean regulator to address open FAPI questions including FAPI 2 final availability.

4.4.   CFPB

  • Open Banking Rule Making in the US. OIDF putting together open letter to CFPB director to clarify points made in recent remarks at FDX Summit.
  • Will share with Board of Directors for feedback before publishing the letter to the OIDF website

5.   FAPI 2 Status Update

  • Still processing last call working group comments, on track for FAPI 2 to be final by end of August

6.   PRs (Dave)

6.1.   #496: remove grant management and other non final specs

  • https://bitbucket.org/openid/fapi/pull-requests/496
  • Removes specific references to some additional documents and simplifies intro
  • Adds sentence referencing Oidf publishing additional FAPI 2 framework docs that build on the profile
  • Moves some clauses to a FAPI 2 implementation advice document
  • Leaves in reference to PAR (Pushed Authorization Requests) as it's a final spec
  • FAPI CIBA, and Message Signing are mentioned in notes and aren’t normative
    • Update links to use openid.bitbucket.io files (Joseph will create issue)
  • FAPI1 security analysis is referenced but not FAPI2 analysis. Joseph will create issue.
  • OAuth security topics is close to final

6.2.   497 - editorial: attempt to improve readability for clock skew clause

  • https://bitbucket.org/openid/fapi/pull-requests/497
  • Attempts to clarify language around clock skew and when authorization servers must/should/may accept tokens in the future
  • Defines 3 scenarios:
    • Must accept up to 10s in future
    • May accept between 10-60s in future
    • Should reject after 60s in future
  • Applies to both iat and nbf claims
  • Need to provide rationale for implementers or accepting 10-60s
  • Mostly for interoperability reasons

6.3.   495 - editorial content for the MTLS ecosystem section

  • https://bitbucket.org/openid/fapi/pull-requests/495
  • Tries to make mutual TLS ecosystems section more understandable
  • Explicitly calls out private key JWT assertions or DPoP proofs enabling mTLS connections
  • Removes some rationale text about easing integration, security and interoperability concerns
  • Awaiting feedback from Ralph, Dima

6.4.   494 - issue-694 readability of refresh token rotation clause

6.5.   493 - typ in request objects

  • https://bitbucket.org/openid/fapi/pull-requests/493
  • Related to #684
  • Causing interoperability issues in some ecosystems
  • FAPI language is unclear, implying typ header can be used but may not be accepted by existing deployments
  • PR from Filip to clarify clients should send the header and servers need to accept it
  • Discussion around mandating this and potential for disruption if done too quickly, need to consider messaging and scheduling

7.   Issues (Dave)

7.1.   692 - CAA records

  • https://bitbucket.org/openid/fapi/issues/692/caa-records
  • Provide hints to implementers to mitigate impersonated domain validated certificates
  • It is hard to test and so we will not make it normaitve.
  • Consensus to leave current text as-is recommending but not requiring CAA records, as requiring them would be outside the scope of FAPI

7.2.   685 - Use of TLS 1.2 Ciphers

  • https://bitbucket.org/openid/fapi/issues/685/use-of-tls-12-ciphers
  • Agreement current clause allows for a wider set of cipher suites for endpoints used by web browsers
  • Discussion around some banks supporting legacy ciphers for compliance reasons
  • Proposal to add a line to the FAPI 1 vs FAPI 2 differences table to clarify FAPI 2 is more permissive in this area
  • Restriction are for non-browser endpoints
  • Text from FAPI 1
For the authorization_endpoint, the authorization server MAY allow additional cipher suites that
are permitted by the latest version of BCP195, if necessary to allow sufficient interoperability
with users' web browsers or are required by local regulations. NOTE: Permitted cipher suites are
those that BCP195 does not explicity say MUST NOT use.

8.   AOB

  • No other business raised

The meeting adjourned at 15:02.

Updated