Re: [w3c/3ds] Some high-level issues to discuss (#2)

[This turned into a bit of a screed of the kind that might be best shared at a face-to-face meeting, but it might raise some topics for further thinking and discussion.]

First, taking a step back, we have a tussle [1] here, driven as @asolove-stripe has explained by the differing worldviews of the closed payments ecosystem and the open web ecosystem, and also by the differing values of the various actors involved, which include:

* Card issuers want to reduce fraud and increase trust in the overall payments ecosystem.
* Merchants want to reduce shopping cart abandonment so they can increase revenue and they also want to minimize the costs of compliance and implementation for risk mitigation features.
* Customers want shopping to be convenient and want to avoid identity theft (many of them also want to protect their privacy).
* Browser vendors want to enhance trust in their software through appropriate privacy and security protections against bad actors on the web, while not losing market share in the process.
* Various malefactors want new attack vectors so they can perpetrate fraud, steal people's identifying information, etc.

One of the browser/user-oriented concerns is that much about 3DS is currently opaque and the protocol enables extremely strong fingerprinting of a user's device (by design). The Device Information specification within the 3DS SDK makes it clear that an enormous amount of information could be gathered (especially on Android), but it is quite unclear how some of that information is relevant to risk-based decision processes. Naturally, issuers might want to gather as much information as possible, on the theory that you never know what bits of data might inform a risk decision. On the other hand, users might see no need for issuers to know whether, say, haptic feedback is enabled on their device (feature A107 HAPTIC_FEEDBACK_ENABLED in the Device Information spec). There's a tension here that could potentially be eased by enabling users to choose their level of disclosure, to choose who can receive such information (e.g., my bank but not a random merchant or payment service processor), to have insight into what information is being requested or revealed (and by/to whom), to know that the data is end-to-end encrypted and not visible to intermediaries such as merchants or PSPs, etc. (One alignment is that merchants and PSPs probably don't want this information either for liability reasons.) Privacy-concerned customers might be happy to never allow the "frictionless" (device fingerprinting) flow even if that implies more frequent invocation of the challenge-response flow. And so on.

Second, more specifically with regard to the flow that @ianbjacobs has suggested, it's important to be crystal clear on the roles and responsibilities of the various actors (this will also help us later when we perform a threat analysis). For instance, I'm not sure it's true that "the merchant needs to package up some data used for risk analysis by the issuer." For the "frictionless" flow, the issuer wants to gather detailed device fingerprinting data (not "some data"), but the merchant probably doesn't want to see or touch that data other than to pass it through end-to-end encrypted to the issuer. As far as I can see, the hidden iframe stuff is driven by a desire for consumer convenience above all else (e.g., above user privacy), and secondarily by a desire to not have the merchant directly involved in gathering the device fingerprinting data - if I'm not mistaken, the script is served up from an issuer URL, not a merchant URL.

I'm not sure how it would work if "the merchant provides a 3DS endpoint URL" and "the browser only displays payment apps that match on the endpoint URL". Would the 3DS endpoint be tied to a specific issuer (e.g., Chase) or brand (e.g., Visa)? If so, the merchant / PSP would need to run more than one 3DS endpoint, which is undesirable because of cost, implementation difficulty, etc. More likely is that the PSP would run one 3DS endpoint handling all issuers and card types, but pass information about the supported issuers/brands to the browser. When the user types in or loads a card number, the browser could perform matching to determine if the user has approved sharing device fingerprinting data with the issuer/brand; if so and the browser knows the issuer's/brand's public key, it would encrypt the data being requested (or some subset thereof) to that public key (or more likely to an ephemeral key derived from that public key - encryption details are still TBD).

Hidden iframe madness aside, the trust relationship is between the cardholder and the card issuer, so it seems to me that for identity validation purposes the cardholder's user agent needs to interact directly with the issuer's web origin [2], not the merchant's web site or the PSP's processing network or something else in the middle because the potential for attacks by untrusted actors is just too great.

Third, it would be helpful to understand the desires (requirements, if you will) of the issuers/brands with respect to identity and verification. For instance, is ID&V without a secure element on the device truly reliable from their perspective? If not, then some kind of interaction with a mobile device or, more broadly, an authenticator will be needed. We can all say we'd like a web-only flow, but if that doesn't meet issuer/brand requirements then it's a non-starter. Yet we might be able to retain most of the benefits of a web-only flow (which so far seems to be a second-class citizen in 3DS) by leveraging the Web Authentication API and the access it provides to authenticators of various kinds - which could include an authenticator app on the user's mobile device in proximity or communication with the browser on the user's larger-form computer. The "mobile-only" vs. "web-only" thinking evident in 3DS so far might cause us to miss some nuances and opportunities with respect to a broader range of authentication options (for which strong device fingerprinting might just be the hammer folks have close to hand)...

[1] http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf

[2] https://tools.ietf.org/html/rfc6454

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/3ds/issues/2#issuecomment-363228439