Some high-level issues to discuss about 3ds HOT 12 OPEN

@asolove-stripe Right, so we agree there's a gap here. Now we just need to fill it. :-)

Part of the worry is that although merchant sites can get into PCI trouble (however, I don't see device authentication data mentioned in PCI DSS v3.2), we also hear with some frequency that we have to make deployment a no-brainer for them because they're not always tech savvy (and thus we have to wonder if they have good security control over or even insight into what scripts they allow to run on their sites for lead gen, marketing, advertising, etc. - and what those scripts are really doing).

Your mention of conversion rate is key, since that seems to be the main reason why 3DS 1.0 failed in the marketplace...

from 3ds.

Some thoughts (based on your helpful analysis):

• The merchant needs to package up some data used for risk analysis by the issuer.
  (At least this is my guess if merchants want to leverage the risk analysis part of 3DS.)
• The merchant does not want to share that data with arbitrary parties.
• The merchant does not want that data to be tampered with.

Would this flow work?

• The merchant (or their PSP) creates the required data package, encrypts and signs it.
  Call this "MerchData".
• The merchant provides a 3DS endpoint URL and the MerchData to PR API.
• The browser only displays payment apps that match on the endpoint URL. (I'm not sure yet
  whether that makes sense.)
• When the user selects a payment instrument (e.g., Visa card from Chase), the payment
  app initiates the 3DS protocol calling the 3DS endpoint and sending it the relevant data.
• The payment app receives necessary information from the 3DS server (issuer URL)
  and displays the issuer's authentication window. (Not yet sure whether this works with
  Web security.)
• After authentication (when required), the payment app returns the AV in the response data.

Presumably this would still require changes to 3DS. But I am curious whether this addresses some
of the trust issues raised.
Ian

from 3ds.

@ianbjacobs what you describe seems like the most promising path to me. I think the endpoint URL selection is necessary.

And so for this flow the two big questions are:

1. can we load the method url or do something else to get fingerprinting info to the issuer?
2. can the payment sheet load the issuer challenge URL in a 3ds2-spec-compliant way? and given that this isn't a "payment handler" specifically, what is the kind of thing that knows how to load this URL? (Is it baked into the browser? A third-party script url running in a payment handler-like environment?)

Maybe a tertiary question at the intersection of this spec and the token spec is how merchants can communicate requests for special properties like recurring billing, flexible amounts, in a way that works with different PSPs but is somewhat generic wrt the official browser specs.

from 3ds.

[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

from 3ds.

@asolove-stripe said:

We can't obviously push complexity to payment handlers because merchants cannot simply work with any handler that registers for that generic 3DS method. Nor can they hand over all the data involved to an unknown middleman that speaks to the 3DS server for them.

I don't entirely agree with this.

There are two sources of data, the merchant and the handler (on behalf of the user). The merchant supplies information about the context and the handler provides the user's payment instrument details.

3DS through PRAPI requires that the handler effectively perform step 3 in your first diagram on behalf of the merchant.

To mitigate the concern about passing data to an unknown middleman I suggest we consider @ianbjacobs suggestion and use encryption.

Option 1

1. The merchant provides a gateway URL and a blob of encrypted data in the Payment Request.
2. The payment handler submits this data along with the card details to the provided URL and if the issuer requests a step-up it renders the content of the returned URL in an iframe just as the merchant website would have done in flow 1 step 4.

Option 2

1. The merchant submits the tx details (without card details) to the gateway and gets back a URL to include in the PR.
2. The merchant provides the gateway URL in the Payment Request.
3. The payment handler submits the card details to the provided URL and if the issuer requests a step-up it renders the content of the returned URL in an iframe just as the merchant website would have done in flow 1 step 4.

Pros:

• There is a good chance the handler is provided by the issuer so step up auth is less likely

Cons

• Can the handler trust the URL from the merchant? Is there a way to be sure that the card details are not being submitted to a malicious URL?

Is this negative even an issue given that this is no different to the user submitting their card details to the merchant directly. At least in this case the handler can have a blacklist of origins that it won't trust or be even more conservative and use a whitelist.

from 3ds.

@adrianhopebailie I very much like the idea of an issuer's payment handler including a whitelist of origins from which it will accept fingerprinting requests (after all, the cardholder presumably trusts the issuer but not necessarily the merchant).

from 3ds.

Lots of good discussion here, thanks all! Some thoughts and reactions:

@ianbjacobs said:

The merchant needs to package up some data used for risk analysis by the issuer.
@stpeter said:
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

Peter is right that for the current web flow, this fingerprinting is done from an issuer-owned script. It uses standard DOM methods to gather fingerprint info. The Native SDK, also occasionally referenced in this conversation, is designed to send anything an issuer might want since there is no desirable way to load an issuer-owned script into a native app to gather the info. If we want to comply with the spec as-written, it's worth considering whether 3DS handler scripts would want to embed the native SDK to avoid the iframe shenanigans. But I think we'll either have the security problem of loading unknown javascript like the web flow or the privacy problem of the native SDK sending every possible piece of data like the native flow.

@stpeter said:

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.

The spec as written does not make clear whether opting out of the method url is an allowed choice (by the merchant or by the user). We at Stripe have been asking about this and it seems like some networks are currently requiring the method url to do 3DS at all, even if the merchant or user wants to go through the challenge flow. Other networks are not. We'd probably need to lobby to add the user choice here.

@stpeter said:

Would the 3DS endpoint be tied to a specific issuer (e.g., Chase) or brand (e.g., Visa)?

I assume it would be one endpoint per "3DS server" from the 3DS spec, which in practice probably means one endpoint per PSP or integrator used by merchants. That endpoint then has access to the 3DS system to talk to the right card network's Directory Server, which routes the request to the right issuer.

@stpeter said:

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?

This gets into two interesting issues.

First, remember that getting any kind of fingerprint data is a huge step up from the current situation, where issuers just get a card number/cvv and an amount and have to decide whether to authorize that transaction. Using 3DS1 and some other methods, over the past few years the networks have started to support "risk-based authentication" (meaning the issuer gets more data about the transaction, merchant and customer, and then can challenge when desired) and have already seen large decreases in fraud while only challenging a small percentage of transactions. So for them, getting this data is already a huge improvement and they appear to be less concerned about exact forms of technical authentication.

Second, this borders out of the realm of trying to implement the current or some slightly-changed version of the spec and into a broader question of what would be the right technical way to authenticate web payments if we were building from scratch. I think that's a great question, but one that's probably worth taking up in a different venue. For better or worse, the card networks are huge and have thousands of individual issuers who have to implement a spec for it to be any use, so trying to reach out and design a good technical solution is tricky. I do think a lot of this conversation would be good to take up in the context of other payment methods like mobile wallets that are now gaining in popularity but are small and technical enough that they would be open to designing a new API for this.

@adrianhopebailie said:

3DS through PRAPI requires that the handler effectively perform step 3 in your first diagram on behalf of the merchant.

I think the 3DS handling, however it is managed, is probably not a payment handler. It's some kind of add-on that can work together with any kind of payment method that returns credit card info (basic_card, tokenized_card, the google pay url, etc.)

Option 1

In this case, how does the device fingerprinting information get sent? If it's part of the data packaged up by the merchant, then we probably need to send all the data required by the native SDK since I don't see a way to run the issuer content in the handler.

There is a good chance the handler is provided by the issuer so step up auth is less likely

Hmm, this seems unlikely to me. It's not the issuer's role and the chance of getting every issuing bank to implement this are unlikely unless we can get it in the EMVCo spec. In general the spec uses the networks' Directory Server to mediate all merchant -> issuer interactions, except for those URLs that have to be loaded directly into the customer's browser.

I would picture the handler provided by some third-party, possibly a PSP or someone interested in 3DS adoption like a big ecommerce company, and it would probably need to be audited by EMVCo. But this returns us to the question of how, within the handler environment, to give the issuer access to fingerprint in the way they desire.

from 3ds.

@stpeter said:

I very much like the idea of an issuer's payment handler including a whitelist of origins from which it will accept fingerprinting requests (after all, the cardholder presumably trusts the issuer but not necessarily the merchant).

I'm not sure how this would work. Part of the way card networks work is that there aren't bilateral relationships between every issuer and merchant. Instead, they have contractual relationships and use the card network as a central way to interact with other actors. In practice, the list of merchant websites that an issuer accepts from is the list of every company that is allowed to issue charges in the Visa/AmEx/MasterCard network. The issuer doesn't have any control over this, except training their fraud models to issue challenges more frequently on certain origins or business types.

from 3ds.

Thanks for further discussion @asolove-stripe. Here's what I'm struggling with....

The last mile is the browser. Even if my issuer thinks I'm automatically signed up with 3DS 2.0 and there are contractual relationships in place among all the "server-side" parties (brand, issuer, PSP, merchant, etc.), my browser doesn't know that. All it knows is that it's receiving a device authentication (fingerprinting) request from a particular web origin. From a permissions and privacy perspective, how does the user agent know it's OK to run that script? IMHO the glue here might be the user's installation of a payment handler associated with the issuer and the inclusion in that payment handler of a whitelist of origins that are allowed to engage in device authentication. If we don't establish some sort of trust model, then any arbitrary web origin could gather way too much information about the user's device, location, settings, etc. - and that's not a desirable outcome given the prevalence of malefactors on the web.

Am I missing something obvious in the picture we've painted so far...?

from 3ds.

@stpeter I don't think you've missed anything, that is definitely one of the core challenges that I see.

From the EMVCo side, I think their expectation is that you trust the merchant site because 1) you're there and letting it run arbitrary third-party javascript it loads anyways and 2) the merchant could get in PCI trouble or kicked off the card networks if they're doing something shady and get caught. As a result, they assume the merchant loading issuer code in the customer's browser is fine.

From a browser perspective, it makes sense that that isn't fine. I think issuers running some kind of handler would be a great solution from the permissions standpoint. But I am not optimistic that we could make it happen in EMVCo without some kind of leverage, like a great PRAPI 3DS user flow that is supported by lots of browsers and going to make the conversion rate much better for merchants and issuers. And I find it hard to imagine how this would run with the network model where some of these request flows go through the 3ds server and DS, rather than directly from the user agent to the issuer. It seems like we might need to expose all of the 3ds2 details in the browser if we're going to drive the experience from the browser but also let the 3ds server play its role.

from 3ds.

@asolove-stripe I don't share your opinion on the likelihood of issuers providing the payment handler.

In my experience that is exactly what they want to do, either directly or via some co-branded application like MasterPass. The experience of logging into my bank's online banking website and having a SW installed that henceforth is able to handle 3DS transactions for me seamlessly is very appealing. I also think issuers have the advantage that a user is far more likely to install a handler from their bank to handle card transactions using the card issued from that same bank that anything else.

Market predictions aside, as I see it the goal should be that instead of the merchant needing to do the "fingerprinting" on behalf of the issuer, the payment handler does it. This makes much more sense because they are trusted by the user. For me this is one of the main goals of this whole project, make things simpler for the merchant and give control back to the user.

A handler that is running in a SW context in the browser (leveraging the Payment Handler API) has pretty much the same capabilities as a script being run in the merchant's Window context. In fact, it has the advantage of being able to access APIs that may require user permissions (like geolocation) and getting that permission once and then being able to re-use it multiple times in future.

In the app context (e.g. an Android app) the handler can run the SDK you have talked about.

My expectation is that for a payment handler to advertise that it supports the 3DS2.0 payment method
it must be capable of returning this contextual data to the merchant in the PaymentResponse.

The merchant and acquirer have no need to understand this data (or do they, maybe part of it?) so I would expect it can be encrypted in such a way that it can only be decrypted by the issuer?

What this would establish is an ecosystem where anyone can publish payment handlers capable of supporting 3DS2.0 but ultimately the gatekeepers are the issuers (which I believe is the desire of EMVCo?).

If an issuer receives data from a handler it doesn't recognize or trust then it will decline the transaction or request a step up auth.

EMVCo could go a step further and maintain a whitelist of handlers and host a payment-method manifest for 3DS2.0 too

from 3ds.

I'd go a step further and say that EMVCo should make this the recommended way of doing 3DS2.0.

The first thing a merchant (or their PSP) should do is use canMakePayment to determine if the use can do a 3DS2.0 payment using an approved handler and if so avoid trying to embed issuer scripts etc into the page at all.

I think that in time you will find that it will get harder and harder for a website to insert JS from another origin as users will actively block this. There are increasing incidents of third-party JS being malicious even when served from trusted source (see recent crypto-currency mining scripts in JS based Google ads).

In the case of a PSP you have a user on X merchant origin, already running script from Y PSP origin that then wants to inject more script from Z issuer origin. As a user I am thinking that's just too many degrees of separation for me.

from 3ds.