---> https://w3c.github.io/3ds/index.html
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
q
IJ: I am hearing from asolove two levels we could investigate:
- merchant specifies exact handler
handlers
- 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
<Ken> +q
https://tools.ietf.org/html/draft-mandyam-eat-00
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
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)