FIDO Credential ID vs Payment Instrument ID #49
Comments
|
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: "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"). |
|
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 |
IMHO Chris' suggestion is a different feature request from Payment Instrument ID -- maybe it should be forked into its own issue.
@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 |
|
@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.
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. |
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 |
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. |
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.
Can you be more explicit about what aspects of EMV you think are relevant/important? |
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.
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.
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).
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)
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. |
|
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)
@Goosth<https://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 GitHub<#49 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ARA57QEY6IHWJELNLQR6BATTJSVYXANCNFSM42IZT6YA>.
|
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.
+1
+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.
|
|
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.
The text was updated successfully, but these errors were encountered: