Meeting minutes
Changes to browsers and impact on Open Banking
Stephen: Browsers are changing for privacy reasons, including restrictions related to 3p cookies.
… already restricted in Safari, Firefox; Chrome removing them in 2023 time frame.
… cookie changes are just one of the changes in this space
… so we are having discussions about use cases that will be impacted
... We are asking people to think about how flows will break (or are breaking)
Ian: Example of impact: during checkout the user chooses a bank; when returning the user does not want to have to reselct the bank from a list.
Herve: Regarding cookie removal; is this just removal when the browser is closed or even in-session?
Stephen: Browsers are restricting access in a 3p context. If you are on merchant.com and there is a PISP in an iframe; the PISP will no longer have access to cookies
… there won't be access via HTTP headers or JS
… embedded iframe is a frequent scenario in advertising use cases
… but it also has an impact in other use cases.
… for example, request to get one-pixel images (used for tracking) used to carry cookies
… but will no longer do so.
… Ian referred to the open banking flow where the user has to choose their bank.
… and after the first time that choice is stored. That functionality (as it is currently implemented) will go away
Ian: Another use case - risk assessment by examining device data.
Gerhard: I want to clarify - iframes will continue to work; cookies will not
Stephen: Right. I think few things will outright break, but instead won't work as well or as intended
Gerhard: Another pattern that is changing - storage access is double-keyed (e.g,. indexDB)
… where in your protocols are you aware of iframe use cases or storage use cases
Herve: I don't think there are many specific uses of cookies in our protocols because they are intended to be RESTful.
… in France the application of open banking is most likely through the use of mobile apps
… thus the payment app embeds the session information.
… but I do see one case where cookies are useful -- to avoid a "session hijack attack"
… the the user is redirected to the bank and then bank. The TPP (third-party provider) checks the cookie to be sure there is no swap in users during the interaction.
… the threat is: user makes a purchase, is redirected, and then sent back to another user environment. The TPP's job is to prevent this attack (and uses cookies)
… I think that's the sole case that involves user cookies
Ortwin: I agree with that assessment
Herve: The TPP may also use cookies for their own business.
Ortwin: The TPP's job is integration into the merchant site. You need to be talking to Plaid, Klarna, etc. You might want to reach out to to the European TPP Association (ETPPA).
Manish: And in the UK: the Financial Data and Technology Association (FDATA)
… there are TPP use cases in both 3p and 1p contexts.
… e.g., list of banks is constantly changing so sometimes choice happens in 1p context
ACTION: Ian to follow up with Manish on FDATA outreach
ACTION: Ian to follow up with Ortwin re: ETTPA outreach.
Ian: Any other checkout context use cases?
Orwin: Go ask the TPPs.
Manish: Here's how the list of banks works - either the TPP provides an API
… in which case the merchant manages the list in a 1p context
… or the TPP provides a web-hosted page (in a 3p context, for example). Stephen, you mentioned the timeline (2023). Is that tentative?
Stephen: that's the declared Chrome timeline.
… second half of 2023. But other browsers have already made changes (e.g., Safari a couple of years ago)
… bear in mind that there are also changes not related to cookies
<SameerT> q: +1 to exciting and scary times
Gerhard: If we are aware of cases where browser fingerprinting happens (e.g, user agent string)
… would be good to know
Stephen: User agent string changes happening sooner.
See recent presentation to WPWG on user agent string and slides
Open Banking and SPC
Wijnand: Berlin Group is one of the groups doing APIs related to open banking; we have a roadmap in 2022
… first half of year is handling overflow from 2021
… for new architecture items in the roadmap
… some considerations: OpenID, FAPI
… API access scheme development
… the European Payments Council (EPC) was tasked by the ECB to work on a safer access scheme
… Berlin Group and others will be involved in this work soon
… this might still impact our 2022 work plan
… another work item is to provide for direct access and signed transaction data
... We are also reviewing EIDAS regulation
… the ECB also started work in the space of digital Euro
Gerhard: Very interesting. The one that stands out for me (in this context) is digital signing.
… SPC uses crypto signature mechanism as part of a payment display
… signs what is displayed to the user.
… it would be valuable to know what fields you need to be signed
… then we could SPC sign something that you can leverage on the server
… we'd like to align.
Wijnand: Alignment would be extremely valuable. As soon as SPC can share data with us, that would be great.
… we've not looked at the SPC draft yet in detail; we don't have details on our side yet
Ortwin: We'll use JSON signature to sign the full payment data
… we are turning APIs also into "direct access"; this lets companies use the APIs with their own banks.
… the SCA mechanisms are normally in the enterprise context
… there will be other resources that need to be signed as well (e.g., subscriptions)
… theoretically you might use not only the classical signing mechanisms (certificates) but other methodologies as well.
… we'll be investigating signing mechanisms
Ian: How connected are you to FIDO?
Ortwin: They are part of our advisory board.
Gerhard: If we want to evolve SPC we might want to look at some of the open banking use cases. Currently we support immediate payment consent, but there might also be consent for recurring payments.
… so would be good to hear more use cases to see whether SPC can handle them.
Ortwin: Have a look in the roadmap for that
… the EPC is looking into use cases like guarantees, deferred payments (to be executed later), split payments, recurring payments.
...You need also to talk to the TPPs regarding integration
… banks are driving this from a 1p access; providers from a 3p point of view
Ian: What options do we have to collaborate more closely?
Ortwin: Probably too soon, but when market consultations start, we would like to collaborate
Ian: How does that work?
Ortwin: We publish publicly. We can ask our advisors if they are interested in a closer relationship.
Herve: Re STET, we have standardized functionalities required by regulators; talking about extensions with people.
… on security layer we are still working on a signature mechanism
… we have a client-signed mechanism that was using HTTP signature but there is now a new IETF draft
… we also worked with ETSI to implement a JSON signature mechanism.
… on the client side signature front, we are working with FIDO
… but there are 2 concerns. First, the FIDO mechanisms were not providing all that I needed ... a payment signature. But I think SPC will potentially help.
… my second concern has to do with adoption
Ian: What are barriers to adoption of FIDO?
Herve: In some cases, people already have 2-factor mechanisms and don't want to implement a new architecture
… regarding OpenID connect; banks in France are used to OAuth2. But the move to OpenID connect is not obvious to them.
… we were inspired by FAPI-decoupled approach
… we implemented a version of this approach in the most recent release, but it's not based on OpenID Connect
Kris: With my ISO 20022 RA hat on, here's a quick update
… we are revising ISO 20022; new work will enable people to register business APIs with ISO 20022
Vincent: One thing that might be of interest to this group -- a study group in ISO 20022 to look at standardizing digital wallets
… the scope is not yet defined
… e.g., questions on tokens, fiat currencies, etc.
Ian: Let's stay in touch on that!
Upcoming TPAC 2022 Survey
TPAC 2022: 12-16 September in Vancouver (likely hybrid); I plan to send out a survey regarding interest in in-person participation.