3DS Task Force

08 Aug 2018



asolove, Ken, Ian, stpeter, Jonathan, MikeHorne, Gildas, JimmyWardrope


---> https://w3c.github.io/3ds/index.html

Next steps for "3-D Secure 2 with Payment Request API"

Ian: I plan to add merchant data to the request dictionary tomorrow
... and will notify when that's done

Jonathan: Are you considering use case of payment handler or browser also?

IJ: Both

Jonathan: Should the specs refer to one another?

Ian: I think that makes sense (e.g., link ECI to 3DS)
... if people want to merge work into one spec and/or one task force, then let me know. I don't feel strongly.

[Ken on a bit of background]

Jonathan: if merchants want to leverage a secure payment method, we should have a proposal for them that leverages both
... tokenization and consumer auth
... I don't have a strong opinion on how to structure the task force

IJ: Reasons to keep together - the bundle is interesting

Jonathan: Indeed, a single story for merchants would be compelling.

IJ: Reasons to keep apart - pieces are implemented by different people, or pieces may be reused in different contexts

Ken: Yes, I agree that teeing up to merchants is a good topic
... but I lean to keeping them separate as spec
... and one reason might be if we need to come back to EMVCo with new use cases

MikeHorne: +1
... I think it's logistically easier to split them.

Jonathan: If the goal is to identify gaps and report to EMVCo and work with them, then yes.
... but once we try to have a story with a new secure payment method, we should have a track to combine them somehow

Ken: +1

<scribe> ACTION: Action asolove to review the 3ds spec.

asolove: I think it will be hard to make progress without better understanding of who will implement this
... important topics about onboarding for example
... and these issues affect the data model
... e.g., whether it's a PSP or whether it's the browser or the networks
... in particular, for the question about "what data is required from the merchant"
... there's a big difference between a company that does onboarding outside this flow
... versus a world where, say, the browser is implementing or some decoupled third party is implementing
... where the data requirements are bigger if onboarding is not handled in the spec

IJ: It would be great to touch on the onboarding topic in your review of the spec

asolove: I will do that.
... more specifically:

a) Does the payment handler have a backend integration?

b) Or do they not?

<asolove> ++, that's a better explanation

IJ: Specifically -if backend integrations exist, less data is needed up front
... but if the merchant doesn't know the payment handler in advance, I don't know how you distinguish a light v. heavier payment method up front

asolove: There may also be GDPR issues - sending data to parties who are unknown up front

Jonathan: Yes

asolove: Should any handler be able to handle 3DS, or should this be a call to specific 3DS handlers.

IJ: We could take that filtering approach, and then lighten up the data model

asolove: Like others here, I would like the browsers to implement this direclty
... in general, I think there would be privacy and other concerns with a generic payment method that can be implemented by anybody.

IJ: Please let's document assumptions about registration in the ecosystem, e.g., merchant is registered AND payment handler is registered (that is, to do 3DS)

asolove: merchant may not need to have relationship in advance, but the payment handler may need to be certified in advance
... not sure how to enforce that technically.
... it's more of a concern than with Basic Card to send more data to the payment handler
... we could think about the pre-existing exchanged keys flow


IJ: I am hearing from asolove two levels we could investigate:

- merchant specifies exact handler


- more flexibility, but with some enforcement of registered handlers (e.g., with enforcement by the browser)

asolove: the 3ds server needs to be certified; but the payment handler may not need to be ...it just needs to talk to a certified 3ds server
... Prior to PR API, merchants have a contractual relationship to a 3ds server
... in PR API world, merchant says "I want 3DS2" and then anybody can distribute a payment handler ... so we need a way to determine (through relationships) that there's a real 3ds server in the background
... The merchant wants to know something about who they will eventually talk to, and the reverse is also true - the 3ds server takes on some liability for data they send through the system
... so it feels like some knowledge of the parties (e.g., through key exchange) is necessary since there are actual costs

IJ: Sounds interesting to have browsers white list payment handlers as 3ds certified
... but challenge is getting merchant identity reliably through pipes
... You could use origin and browser could encrypt data that is decrypted by the 3ds server who knows the brower's public keys

asolove: Nice world, but I don't think origin will suffice
... merchant IDs are different across systems

IJ: Maybe you send pairs back - origin + merchantID

asolove: That's how Apple Pay works

<Ken> +1

Organizing 3DS discussion at TPAC

<Ken> +q


IJ: For me there are two topics:

a) Spec progress

b) User confidence signaling with Web Auth WG

asolove: In the future, 3ds may be necessary. Browsers might say "basic card is not enough; I may do 3ds on my own as part of implementing basic card"

(IJ notes that that use case justifies keeping the 3ds Spec separate from tokenization. :)

Ken: PSD2 is not the only case

Next meeting

22 August

(we will continue to talk about TPAC)

IJ: At TPAC it would be good to surface things for browser vendors to consider. For example

a) whitelist of 3ds-certified payment handlers (part of matching)

b) Whether they need to encrypt data that goes to 3ds servers (e.g., origin + merchant-provided ID)

Summary of Action Items

[NEW] ACTION: Action asolove to review the 3ds spec.

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/08/08 16:43:24 $