Closed tblachowicz closed 2 years ago
This is obviously a step forward. Where is the account number in this process?
Chris Wood's presentation at the F2F proposes yet another enhancement: https://docs.google.com/document/d/1qjBPa6l0EM9A3sLl9neccq_8UPHe90jXTGXqcbge2vQ
"One should also note that an extension of limited scope to the querying mechanism in the original SPC proposal should be created to allow the Relying Party to discover the web origin to which the credential is bound. This would greatly enhance customer experience. A Relying Party could query the web origin for a given credential, resolve this to a given bank and undertake the correct payment flow without having to ask the Customer whom they bank with"
This is a pretty big step away from 3DS and centralized registers holding enrolled cards. Adding an account number to the payment credential then becomes a no-brainer. However, then you have effectively recreated EMV ("Card Present"). @danyao @tblachowicz
Adding this to the list of discussion topics for SPC Task Force once that spins up, and @stephenmcgruer FYI.
I think a key consideration is to make sure the proposed Payment Instrument ID does not become a global identifier. The FIDO credential ID is designed to be scoped to the Relying Party's origin.
@tblachowicz - what problems do you envision the Payment Instrument ID solving that are not solved by the FIDO credential ID today? Here are three on top of my mind based on the F2F discussion:
[1] https://www.w3.org/2021/Talks/spc-design-20210331.pdf, slide 7 [2] https://www.w3.org/TR/credential-management-1/ [3] https://www.w3.org/2021/Talks/ahb-wpwg-20210329.pdf, slide 8
Chris Wood's presentation at the F2F proposes yet another enhancement: https://docs.google.com/document/d/1qjBPa6l0EM9A3sLl9neccq_8UPHe90jXTGXqcbge2vQ
"One should also note that an extension of limited scope to the querying mechanism in the original SPC proposal should be created to allow the Relying Party to discover the web origin to which the credential is bound. This would greatly enhance customer experience. A Relying Party could query the web origin for a given credential, resolve this to a given bank and undertake the correct payment flow without having to ask the Customer whom they bank with"
IMHO Chris' suggestion is a different feature request from Payment Instrument ID -- maybe it should be forked into its own issue.
This is a pretty big step away from 3DS and centralized registers holding enrolled cards. Adding an account number to the payment credential then becomes a no-brainer. However, then you have effectively recreated EMV ("Card Present").
@cyberphone I think we should be careful not to conflate SPC with any specific network protocol (e.g. 3DS). SPC is designed to be complementary and agnostic of network protocols that merchants and financial institutions may use to communicate. In the SPC Design Space [1] discussion during F2F, we identified 5 key components that all need to be designed to support SPC end-to-end, namely:
The Payment Instrument ID discussion is part of Assert Data Model. 3DS support is part of Network Protocol (so is Open Banking support). Querying-web-origin-of-credential probably fits better into Web APIs.
[1] https://www.w3.org/2021/Talks/spc-design-20210331.pdf, slide 8
@danyao Long story short: The reason why payments in the physical world works just about everywhere is because there is a very specific standard known as EMV. It was designed for convenience and security.
Imagine you created a Web equivalent to EMV!
BR AR
@danyao 3DS give Merchants the User's account number. This violates the privacy-by-design principles that are the origins of FIDO (Merchants only need to get payed). State-of-the-art payment authorization schemes as well as Google Pay encrypts authorization data. 3DS is OK as a "product project" but unfit as the foundation for a (potentially) ubiquitous W3C standard.
@danyao @tblachowicz @adrianhopebailie @stephenmcgruer @btidor-stripe @equalsJeffH Since EMV have not been elaborated on, it might be useful for the coming Task Force having some EMV facts on the table for consideration.
PaymentRequest
. There are no pre-defined payment network protocols.What's missing is encryption of privacy-impeding data because that was infeasible as well as not paramount back in the days when EMV was created. Since EMV builds on an end-to-end security model for authorization, it seems logical to maintain the same principle for encryption.
Imagine you created a Web equivalent to EMV!
EMV is dependent on a complex ecosystem of certified hardware devices and certification programs for parties on both sides of the transaction. The model simply won't work on the Web.
The problem Chris is trying to solve is routing to the RP based on the selected instrument. A solved problem in the card world but not for other payment methods.
I believe the correct way to solve Chris' problem is through Payment Handlers that are linked to a Payment Instrument
EMV is dependent on a complex ecosystem of certified hardware devices and certification programs for parties on both sides of the transaction. The model simply won't work on the Web.
I'm only proposing looking into the EMV "concept". The trustworthiness of whatever FIDO/browser-intrinsic auth* solution should (at least with respect to the client side) be equivalent.
Introducing additional dependencies on https://www.w3.org/TR/payment-handler/ or native payment handlers, would make the standard-to-be very complex. A local credential database (a.k.a. "wallet") should address all reasonable credential discovery issues as well as dealing with issuer identification.
The trustworthiness of whatever FIDO/browser-intrinsic auth* solution should (at least with respect to the client side) be equivalent.
I don't think that is true. The whole reason for WebAuthn needing to exist is precisely because browsers are just software and there needs to be a way to interface with secure hardware in a manner that can provide security guarantees to RPs.
Designing this general purpose interface is obviously harder than something as specialised as an EMV certified POS for example.
I'm only proposing looking into the EMV "concept".
Can you be more explicit about what aspects of EMV you think are relevant/important?
The trustworthiness of whatever FIDO/browser-intrinsic auth* solution should (at least with respect to the client side) be equivalent.
I don't think that is true. The whole reason for WebAuthn needing to exist is precisely because browsers are just software and there needs to be a way to interface with secure hardware in a manner that can provide security guarantees to RPs.
AFAICT, if the part of WebAuthn that is built-in and runs in the browser is corrupted, all bets are off except theft of private keys.
Designing this general purpose interface is obviously harder than something as specialised as an EMV certified POS for example.
It depends on what the requirements are. If for example the SEPA camp insist on ISO 20022 compatible user authorization data, progress would probably stall indefinitely. Fortunately, existing systems show that user authorization without major drawbacks, indeed can be treated as a universal, separate event and process.
Can you be more explicit about what aspects of EMV you think are relevant/important?
If the Task Force actually is interested in this topic, I would suggest a video-chat or two. There is also a fairly complete writeup which I have "generously" provided links to in quite a bunch of forums 😼
@adrianhopebailie @ianbjacobs @stephenmcgruer @btidor-stripe Please don't get me wrong, the Stripe pilot served an extremely important purpose: it proved that there is genuine interest in this project. "Vibrant discussion" as Ian wrote in the F2F minutes. However, this also represent a "momentum". I guess the members could be interested in something that actually becomes a standard deployment wise as well. Maybe even getting a cool logotype and brand name! Seen from my horizon it is more about what could give "most bang for the buck", than creating the perfect solution. Personally, I have no idea what the perfect solution could possibly be except that it must arrive in a timely manner 😇
It is really important to get clarity on the tracking prevention at an early stage. I would agree that we’re opening up potential misuse if we share the FIDO credential ID’s.
Imagine Alice has a PaymentCredential (For PlatinumCard) setup on both her HomePC and PersonalPhone, issued to her by bank.com. Linked to these are two platform authenticators (one for each device).
When shopping at merchant-A.com, these two FIDO credential ID’s will be shared with merchant A (as part of the network flow, in the card case via the 3DS ARes). The same set of credentials will be shared with Merchant B, when she shops at merchant-B.com.
if both Merchant A and Merchant B partner with AddProvider.com and these ID’s to AddProvider, they would be able to track Alice across both of these two browsers when she shops with her PlatinumCard.
So this means it's possible to track a user across and even wider context than a single browser, since both ID’s would be shared.
I’m not sure that just creating a new Payment Instrument ID that maps one-to-one to a Fido Credential ID + PaymentCredential(e.g. Card) would help. The whole list of Payment Credential ID’s would still be shared in a purchase, and that list could be used to track that payment credential (and therefore the user).
Ideally we don’t want this tracking to happen. I can see three ways to prevent this from happening (some industry examples of this)
Enable Bank.com to generate unique ID’s for each merchant+bank combination (separate id’s for Merchant A and Merchant B). This would be difficult to execute if bank.com is not able to access the browser when a new merchant wants to get the information. But achievable if bank.com can retrieve this during a browser call (E.g. 3DS MethodURL in 3D Secure).
Create a list of one-time-use unique ID’s that can be shared with different merchants. So the list of values change/are unpredictable, making the linking impossible. This could also be genereted as needed by bank.com if they can run javascript before they return the ID’s to the merchant.
Encrypt the payment instruments (as a JWT) using a transmission key in the browser and provide a seed value (nonce+timestamp+merchant) that makes the encrypted value different for each use. The browser agent could then decrypt this and get the ID’s but this would be hidden from the Merchant. The public key would have to be shared for every transaction (included in the AReq for 3D Secure).
Are there other techniques? Which of these should we pursue further?
Are there other techniques? Which of these should we pursue further?
@Goosth These are very good questions!
AFAICT, the Task Force is at a cross-road: https://github.com/rsolomakhin/secure-payment-confirmation/issues/52
Apple Pay doesn't suffer from the issues above because it builds on authorization, encryption, and a credential database.
@Goosth,
In your scenario, Alice is paying with the same card on merchant-A.com and merchant-B.com. Is that card credential already sufficient information for AddProvider.com to track her?
@Ian @.***>,
Great observation. In traditional card payments the merchant would indeed be able to track the user through their PAN (Primary Account Number). The card world is however trying to get rid of that with tokenization, where a unique Digital PAN is issued for every merchant. This is then stored by the merchant and used in subsequent payments. Furthermore, some banks are offering "virtual"/one time use PAN's to allow users to get a unique PAN for every transaction.
So, there are many other ways of tracking users today. Organizations are working to close them down however.
In the case of the PAN, it's entered by a user at the merchant. Should we not at least try to not open up new ways to track people across domains without their consent? In other examples I've seen (e.g. Verifiable Credentials) there is a unique DID for every two parties interacting, to prevent this type of linking of a specific user through ID's. That's may however be too excessive for us here.. Perhaps we shoud just start with sharing the Payment Credential ID, and make it more explicit in the initial creation consent screen.
From: ianbjacobs @.> Sent: Tuesday, April 20, 2021 00:35 To: w3c/secure-payment-confirmation @.> Cc: Gerhard Oosthuizen @.>; Mention @.> Subject: Re: [w3c/secure-payment-confirmation] FIDO Credential ID vs Payment Instrument ID (#49)
@Goosthhttps://github.com/Goosth,
In your scenario, Alice is paying with the same card on merchant-A.com and merchant-B.com. Is that card credential already sufficient information for AddProvider.com to track her?
- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/w3c/secure-payment-confirmation/issues/49#issuecomment-822832896, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARA57QEY6IHWJELNLQR6BATTJSVYXANCNFSM42IZT6YA.
I think a key consideration is to make sure the proposed Payment Instrument ID does not become a global identifier. The FIDO credential ID is designed to be scoped to the Relying Party's origin.
I do understand the challenge related to the Payment Instrument ID (PI ID). However I'm not entirely clear how the tracker might utilize the PI ID if it cannot be used to query the bowser silently and would trigger the dialog window requiring the end-user to authenticate.
Furthermore, to my understanding no API designed for SPC is going to silently reveal the PI ID. The client code requesting the SPC has to provide the PI ID into the request e.g. PR API. The PI ID is generated by the browser during Payment Instrument enrollment, so it's actually only returned to the actual RP.
@tblachowicz - what problems do you envision the Payment Instrument ID solving that are not solved by the FIDO credential ID today? Here are three on top of my mind based on the F2F discussion:
- Allows a different "authenticator backend" [1] other than FIDO to be used. [An alternative is to generalize the FIDO Credential ID concept to cover other types of credentials that might be managed via Credential Management API [2]
+1
- Allow multiple payment instruments to be associated with a single FIDO credential [Caveat: this disambiguation may not be necessary until we need to support instrument selection]
+1
I think this is important design concept to allow multiple Payment Instruments (PIs) being enrolled for single FIDO Credential. The use-case I have in mind is the Bank that allows its customer to enroll multiple cards as PIs into the browser, perhaps reusing the existing FIDO Credential. Alternatively, the Bank would need to enroll each card separately as separate FIDO credential.
Furthermore, the above consideration opens a topic of possibility to enroll multiple PIs at the same time. Going back to the example use-case above, the Bank would like to allow its consumer to enroll multiple card at a time with only one biometric gesture to authenticate the end-user. Alternatively, the bank consumer would need to authenticate multiple times, separately for each PI.
- [Future, related to 2] Enable browser-facilitated instrument selection [3] [Must solve the origin scoping problem to avoid the browser handing out global identifiers]
The consideration are related to #13
When there are multiple authenticators used for a single instrument, the user should be able to manage them (read: remove an authenticator, add an authenticator).
Closing this issue because as of the FPWD we are using credential IDs.
My understating of the explainer is that the FIDO Credential ID is used to query the credentials and trigger the SPC flow for the matching credential.
It has been discussed during the annual (virtual) F2F meeting that the new Payment Instrument ID could be introduced instead of the generic FIDO Credential ID. When a new payment instrument gets enrolled in the user agent the Payment Instrument ID would be generated. The ID would be associated with the card meta-data, FIDO Cred ID, and RP ID stored by the user agent. During checkout, the client would provide only Payment Instrument ID(s) in the SPC request and the user agent would find the matching stored credentials based on the FIDO Cred Id and RP ID associated with the Payment Instrument ID.