Meeting minutes
SPC Status
1) SPC => FPWD
Ian: Any initial test work?
Stephen: Yes, we have about 1/2 the coverage I'd like for a launch
… we are doing our work in Web Platform Tests: see the SPC tests
… web driver
<smcgruer_[EST]> https://
Using SPC to fulfill PSD2 Requirements for SCA and Dynamic Linking
Ian: One idea is to develop tests to help fulfill expectations of financial institutions, on top of web platform tests. Need to have some compliance conversations.
Ian: I think the answer is "there should be specificity"
Gerhard: You can get an eMVCo "sticker" but I don't think you can get a sticker for "SCA". You commission a reputable and independent security company to provide their opinion
Ian: Like who?
Gerhard: I will find the name of an EU security firm. FIDO Alliance has done a lot in this space. Keep checking with them.
… maybe a collaboration with FIDO would be helpful
NickTR: There is no standard regulatory path; each country has its own competent authorities. I'm not aware of a certification regime to get a "sticker" about SCA.
Ian: Any implementation expectations to set?
Stephen: We are looking to ship in M95 (MacOS, Windows) ... not guaranteed.
… this is shippable for experimentation but not done.
Charter
Ian: Call for Consensus is underway; please send in your comments by 9 September.
Payment Request API
ian: Marcos is working on cleaning up the tests and spec for final move to PR
… we've not received any further public comments since removing features
Basic Card Replacement
ian: Klarna has a interesting use case. If there is a standardised format, then as an App provider, you can send transactions without the merchant having to make changes. Deprecating basic card removes that ability
… we also had work going on tokenised card format, which was superseded by SRC, which was superseded by SPC
Ian: What are the use cases?
AdrianHB: What I'd love to solve for is instrument selection. Not necessarily storing anything sensitive, but storing a handle that makes it easy for users to choose a payment instrument.
… but in a generalized fashion so that it can be used for a variety of payment methods (e.g., SEPA)
… it would be useful if the browser could store that information and for browsers to provide a selection UX.
… instead of choosing a payment app, simpler: choose a payment instrument.
… and then, for example, SPC could be used for authentication, or the user could be redirected to a payment provider page.
… this would be an improvement beyond autofill.
… and browsers could sync across browser instances
Jean-Michel: The big problem for us is regarding the merchant. How does the merchant know what the user has to pay with?
… best solution for us is to use a PSP to propose contracts to the browser, and for the browser to present what can be used to pay.
… another issue we have regards merchants that have more than one PSP. How do they know which PSP to use based on what the customer can pay with?
… we don't have any proposals at this time.
… we also have some tokenized services....
Gerhard: We've been doing a lot of thinking around open banking. One thing that it does well is move the user from the merchant domain to the banking domain for instrument selection.
… the merchant doesn't get to know
… I think that open banking and SRC are going to be dominant models, where the user interacts with a party that returns (opaque) data to the merchant.
… standardized fields might be:
* Token
* Expiry date
* Dynamic data
… and you may need notification of payment with an account push.
… summarizing use cases:
* Instrument selection
* Notification payment on the way
* Authentication (SPC)
… within instrument selection, there are push and pull variations.
<Gerhard> 4'th is SPC as defined today (payment consent)
NickTR: We have an architecture of Payment Request and Payment Handlers (with canMakePayment), with computation of the interaction of what is accepted and what is available. For push payments, the payment response data is a handle that something is underway
Gerhard: Use case I have in mind is "guest checkout" to get a tokenization process going.
… I think we might make progress with a less generic solution.
Gerhard: Some users are happy to store card info in their browser.
… I think that browsers already provide some selection mechanism (auto-fill)
smcgruer_[EST]: I think this is an interesting topic. As a user, I observe that digital wallets have not yet won!
… I assume it's a chicken and egg problem (adoption only if ubiquitously used by users)
… I heard Gerhard's proposal is a "marketplace" with multiple backends.
… I agree that merchants want to control the UX. Digital wallets control *everything* for the merchant, which is more than what Basic Card offered.
<Zakim> AdrianHB_, you wanted to comment on background of basic card vs payment handler
AdrianHB: Recall that the two problems we set out to solve originally were for browser-stored data (especially on mobile due to data capture friction) and digital wallet connections.
AdrianHB: Maybe we need a simpler PR API that still has payment apps. But I see challenge of getting more browser adoption.
Clinton: Where is adoption documented?
https://
https://
"Payment Handler API and Payment Method Manifest do not yet have sufficient cross-browser implementation experience to advance to Recommendation. However, the implementation in Chromium browsers enables experimentation and the Working Group intends to maintain them as Working Drafts. If the implementation landscape changes, the Working Group will revisit the question of advancement to Recommendation and re-charter as needed."
Next meeting
16 september