3.1.   IIW Workshop

OIDF will host workshop prior to IIW, Monday Oct 28, 2024 at Cisco There will be room and time availability in the morning and afternoon for WG meetings.

3.2.   OIDF Calendar

https://openid.net/calendar/

4.1.   Brazil

• OPIN
  • Domingoes has updated OPIN tests to reflect the simpler profiles
  • OPIN is moving towards adopting a single FAPI1 profile same as OpenFinance Braziil
  • Both sets of tests are available now through September. Old profiles will sunset beginning of October.

4.2.   UAE

Received updated UAE FAPI spec

Domingoes has evaluated the spec and we’re currently evaluating the effort and cost for implementation

26 Banks will certify but uncertain about number of RPs

4.3.   Chile

Regulator ask for clarification regarding some FAPI questions

Joseph is following up

ETA to adoption is 12 - 18 months

4.4.   CFPB

OIDF published an open letter - https://openid.net/letter-cfpb-open-banking/

Received some feedback

Last week per 1033 appendix A, CFPB has published a process for how to apply for recognition as a Standard setter

OIDF is consulting with with others to navigate requirements as well as Linda Jeng who wrote the Dodd Frank regulation which created the CFPB

4.5.   Canada

Mark Haines has analyzed Canadian Consumer Driven Banking Security Workgroup session notes.

There was no direct mention of OIDF or FAPI.

Canadian Consumer Driven Banking Security Working Group session notes: https://www.canada.ca/en/department-finance/programs/financial-sector-policy/open-banking-implementation.html

Attempting to schedule a meeting with banking leads

5.1.   500 - Remove explicit reference to ciphers

• PR #500
• Joseph proposes mentioning a timeline for compliance when BCP changes are made
• Allow grace period in certification tests
• Filip mentioned that compliance depends on how fast changes to certification suite are made
• Policy is that people must comply with standards so certification suite will change ASAP
• Certification suite has allowed 2 months grace period before breaking change tests are implemented but may be too quick for some
• The 2 dropped ciphers are used for DOS attacks so it may not be an urgent security issue
• 2 cases to consider
  1. Urgent
     • 2 months may be too lax
  2. Nice to haves
     • Allow more leeway
• Endpoint to endpoint communications most likely are used for internal infrastructure services and risk may be low based on organizations security controls
• Could allow grace period before new controls are implemented
• If public facing, then risk could be higher and timeline can be shorter
• FAPI endpoints are exposed externally
• FAPI1 will adopt sames changes as PR #500
• Nat proposed moving FAPI1 to 1.1 but staying as an errata will allow changes to apply to FAPI 1 1.0
  • WG prefers FAPI1 to stay as an errata
• Suite does not support TLS 1.3 and EC keys may not be popular
• May only be a problem for RPs
• Need to inform ecosystems of changes
• Timeline for compliance can be an ecosystem choice
• Nat will create an issue for FAPI 1
• WG members should review and provide feedback for changes in https://bitbucket.org/openid/fapi/commits/d5bab018b2a385ce1509d665453fdf8c73430ef7

6.1.   698 - Vulnerability in TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

# 698

BCP 195 has been updated to drop usage of 2 ciphers mentioned in FAPI 1 and 2

RSA TLS keys will not work anymore because there are no approved ciphers for them

Only applies to endpoint to endpoint TLS. FAPI allows exceptions for browser communications.

Propose to reference BCP 195 for approved ciphers

Removal of FAPI1 ID2 tests will start beginning of December

Notifications have been sent in FAPI mailing list and has been made clear in the certification suite

6.2.   699 - FAPI 2 vs. Security BCP Gap Analysis

Latest BCP (-29) has some discrepancies with FAPI2

• Access token privilege restriction
  • should be restricted to minimum required
• Client ID
  • Under certain conditions, RS can mistake an access token for client in a client credentials grant for one issued to an end user
  • Ecosystems may not encounter such conditions
• TLS requirements
  • Recommended to use end-to-end TLS
  • Authorization responses MUST NOT be transmitted over unencrypted network connections.
  • Authorization servers MUST NOT allow redirect URIs that use the http scheme except for native clients that use Loopback Interface Redirection. (NOT explicitly mentioned in FAPI2)
• In-Browser communication
  • If the authorization response is sent with in-browser communication techniques like postMessage WHATWG.postmessage_api instead of HTTP redirects, both the initiator and receiver of the in-browser message MUST be strictly verified as described in Section 4.17.
  • Post message not used with FAPI 2
  • Adding this to FAPI2 will need extra text for context due to uncommon use case
• Cross-Origin Resource Sharing
  • List requirements for browser based clients which are out of scope for FAPI2

Add text in FAPI2 for easy ones and reference BCP for others

• Client ID
  • Client credential grant not used by FAPI2
• Browser communications
  • Explicitly mention in browser communication is not used by FAPI2

Clarify assumptions for FAPI2

Dave will make separate PR for each issue mentioned.

BCP is living document and the intent is to keep up with the BCP where possible.

Make it clear implementers should keep up with it