Meeting minutes
Happy New Year
NickTR: Welcome all!
… we traditionally take time at an early meeting to reflect and look ahead at plans
… these are momentous times at W3C (governance transition)
… we can take comments on the transition
… 2022 was a successful year for the WB
… we advanced PR API to Recommendation
… very grateful for payments industry, implementers, and all who helped move this forward
… we have also built a lot of momentum around SPC which is really turning heads, at least in the card payment community
… 3DS integration is big validation of the work
… it's easy to lose track of time and think things aren't moving forward, so valuable to pause to look at these achievements
… in 2023 we may see a slight "gear change": slow down on Payment Request (tweaks, bug fixes, etc.)
… we can look at features for version 2
… we can continue to debate "payments API" v "e-commerce API"
… I also hope that we can get broader interest in non-card payment authentication with SPC
… there are some initiatives that are gaining traction (e.g., open banking in North America)
… and I expect clearer direction for open banking in Europe (e.g., focus on a single standard)
… it would be great to foster experimentation in open banking with SPC
… I would say that this is the first time in my career there is an opportunity for a unified authentication approach in payments
… at the current time we have one (awesome! :)) implementation; we will need to work to get a second
… as always, I think more experimentation around payment handlers would be valuable to create more competition and innovation; payment handlers are a valuable extension point
NickTR: Logistical question in light of this -- whether we slow meeting cadence
NickTR: So thank you all and take a moment to appreciate your accomplishments from 2022.
Rick: Thanks for that intro! On behalf of Google we share your optimism.
… I think we are at a unique moment in the history of the Web to accomplish those things you mentioned
… I think there are great opportunities to brainstorm about how to improve the web for payments
… big opportunities; keep up the enthusiasm
<AdrianHB_> +1 to in-person collaboration. Yay!
SPC V1
Horz review started; would expect to advance to CR once done
SPC post-V1
...continuation of Nov 2022 discussion.
Gerhard: There are some new topics to cover (e.g., PSD3)
… open banking gaining traction
… there will still be a desire for safe frictionless experiences where SCA not required
NickTR: Push payment fraud in the UK appears to be about the same size as card payments but with only 1% of the volume of payments
… it's a huge problem
Gerhard: Transition between payments is important and friction is a big problem
Gerhard: My theory why we are not yet seeing SPC with open banking is that we don't handle the "handover"
… if we want to cater to more flows, how do we extend the consent piece?
… we could go small (e.g., add more fields to transaction dialog)
… or we could extend to more use cases
… we had a number of use cases with a first consent to issue a credential
… the initial friction allows lower friction subsequent payments
… so there are other types of approval such as "recurring" or "subsequent low friction payments"
… we could also look at implementing SPC on top of other auth mechanisms (e.g., roaming authenticators, but also non-biometric auth mechanisms)
… or single-factor FIDO
… these three buckets I've identified overlap.
[Slide 6 - grouping open issues into the three buckets]
[Note: Some of these use cases also identified by EMVCo (recurring, card on file registration)]
Gerhard: Another example if future-dated payments (where we might need to display the future date)
Gerhard: Slide 7 - there are goals of allowing the user to say "trust this merchant" or "trust this device"
… the browser could play an important role "trust this browser"
… currently this is done with fingerprinting; there could be better ways to bring the browser into the mix
… could be an SPC flag leading to some browser behavior on a given origin
… in a push payment environment there are opportunities for fraud; e.g., bad spelling of a merchant. The browser could provide additional protections to help reduce spoofing
[Regarding handing over]
… handing over to browser instead of app could offer a better UX in some cases
Gerhard: Another field that could be interesting to display is "account selection"
… in the SPC dialog
Nick: We have scars from those discussions
Gerhard: I agree that instrument selection in the dialog might be too far
Rick: +1 to minimize UX owned by the browser
… due to complexity and challenge of inter
… let's keep it essential
… we still need to understand what will drive adoption of SPC
… want to see more adoption before we invest in lots of new features
Gerhard: Use case scope may be impacting adoption
Ian: I think it helps to look at use cases and figure out the sweet spot scope from both industry and browser implementer perspectives.
[More use cases: storage of token, recurring, future dated, standing orders, P2P)
Praveena: As a merchant trying to implement SPC is to make sure all the parties can work together (processes, contracts, etc.)
… I will say that people are excited to see this
[Gerhard compares recurring payments data for 3DS and Open banking UK]
… frequency, amount, end date
[International payments]
Gerhard: More fields are shown (IBAN, country, currency, exchange rates, ...)
… may not be a big enough market for prioritizing at this time
[Bulk payments]
[Multi-auth payments]
Gerhard: In this case, multiple parties have to authenticate; this use case is not front of mind for me
[Additional forms of authentication]
Gerhard: There are opportunities like registering a card on file or indicating that the user trusts a merchant.
… regarding additional forms of authentication:
- possession only (not EU SCA)
… OTP technically is not a possession factor, but it's used as one. We could consider a browser capability with a binary response "Yes; trusted"
… in this case, merchant could still opt for higher security flows
… but I think there are some low friction opportunities that don't rely on FIDO under the hood
Gerhard: Might be some ways for user to express frictionless conditions like "No friction for 3 weeks" or "No friction for payments under amount X"
Ian: Who consumes the trust signal?
Gerhard: The bank. The user sets a flag; the flag value is signed in SPC data.
… and that input could go to issuer e.g., to not challenge
NickTR: There are credit card flows that support that today
… you don't get 3DS challenges for trusted merchants
… this type of exemption is called out in PSD2
Gerhard: Anyone want to weigh in regarding use cases / prioritization?
<JeanLuc> as per EBA an app installed on a device (a browser) is not considered as reliable as a "possession" element - https://
Gerhard: The EBA is quite strict
… they require 2FA; but there are other markets than EU
Payment Handler API
Rouslan: We removed shipping info from payment handlers
https://
Rouslan: In Payment Request 1.0 we removed shipping information following privacy review
… PR API 1.0 went to rec without address support.
… we adjusted the payment handler API at the same time
… in payment handler API, address support is provided by the payment handler (not the browser)
… Chrome users of PR API still want shipping addresses.
… we don't think we can remove the feature from the implementation, and we want the specs to align with implementations
… Apple's implementation also uses addresses
… implementations are thus aligned and so we need to work again in the W3C community to find a good way to bring the features back in the API
… we also want to update the payment handler API to match the PR API
… this is a heads-up to the WG that we've restored addresses (cf pull request 406, which reversed previous removal)
… meanwhile we have been aligning payment handlers with the privacy sandbox
… we want to ensure payment handlers are not used to track users
… e.g., we are removing very soon "payment instruments"
… it will no longer be possible to silently install a payment handler in the user's browser
… this feature is not being used, by the way
… what's being used everywhere is "just in time installation"
… so we are updating the spec to talk about JIT installation
https://
… we also plan to remove payment instruments API surface
… so the only way to install a payment handler henceforth will be for a merchant to request API with that app for the first time.
Ian: Can you install a payment app on the bank site?
Rouslan: Yes, but via a "mock payment" (just in time)
TPAC 2023
See announcement about TPAC 2023, 11-15 September in Seville, Spain.
Next meeting
2 February