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.
• https://www.kuppingercole.com/events/eic2024/agenda with SIDI HUB Workshop following.

3.3.   Open Banking Expo Canada

• June 11th: https://www.openbankingexpo.com/canada/. OIDF doesn't currently have anyone attending but that may change

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.

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.

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

• https://bitbucket.org/openid/fapi/pull-requests/496
• Clarify that it is a OAuth 2 profile and to reference the Security BCP but without saying or implying that we implement all of it
• Dave will update text

5.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
• Make suggestion for adjusting limits based on environment/ecosystem
• Putting into normative text is for making conformance tests to ensure interoperability
• Some ecosystem regulations require compliance to FAPI so we need to provide certification
• Could also remove the 10-60s text and explain in informative language rather than normative
• 10s clock skew solves most interop problems but not all
• Libraries that have higher default clock skew tolerances don’t see clock skew problems
• WG is most comfortable with high limit of 60s
• Dave will reword with note regarding interoperability
• Timestamps help in non-repudiation qualities in Message Signing, DPoP proofs
• Check with security analysis team if not having higher limit will pose security issue

5.3.   495 - editorial content for the MTLS ecosystem section

• https://bitbucket.org/openid/fapi/pull-requests/495
• Dima made suggestions in issue
• Dave will update

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

• https://bitbucket.org/openid/fapi/pull-requests/494
• Related to #694 - Refresh token clause readability
• Clarifies language around refresh token rotation and resubmission of token requests
• Refer to note to clarify but will it will contain normative language which isn’t best practice
• Puts an example directly in the normative clause

6.1.   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.

• Latest BCP no longer recommends 2 of the suggested ciphers in FAPI2
• Ciphers are mentioned in FAPI2 to bring attention to them as BCP is huge and mentioning them allows for conformance tests to be developed
• Suggested to remove ciphers list and reference the BCP with specific attention to the ciphers
• If BCP changes, we should allow grace period but not in spec itself
• BCP also change minimum key sizes mentioned in appendix A
  • 2048 for RSA
• JWS already requires 2048