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

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. 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.


-- 
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-364155574