https://github.com/w3c/3ds/wiki
https://github.com/w3c/3ds/wiki/Agenda-20180118
IJ: Anybody read it & have concerns?
<alyver> I have read. No concerns from me and I think it is worthwhile mission for this task force to pursue.
Ken: I read it but I'm not the
subject matter expert; Mike Donovan read it
... some other colleagues will be reading it and so far no
issues.
Gildas: One question for discussion - are we just planning to look at auth just in 3ds or more generally?
https://www.w3.org/TR/webauthn/
IJ: that's w3c's general purpose auth effort
<alyver> https://github.com/w3c/3ds/wiki#what-is-the-relationship-to-w3c-web-authentication
What is the relationship to W3C Web Authentication?
https://github.com/lyra-labs/poc-w3c-webpayments/wiki/3DSecure-and-PRAPI
Gildas: Look at the last 2
diagrams
... the last diagram in particular is the "minimal" one
... my biggest concerns having done the flow diagram is how to
do authentication for card-in-browser
... there are specifics for each scheme
... how to integrate authentication in the browser? how to
integrate the SDKs?
https://github.com/lyra-labs/poc-w3c-webpayments/wiki/3DSecure-and-PRAPI#fully-generic-proposal
[Gildas describes the diagram]
Gildas: Payment handler needs to
make a decision about whether to authenticate
... so there is an authentication server decision
... why is it "optional"?
... it may be necessary to interact with the ACS/DS
server
... when authentication is required, payment handler prompts
the user
... the authentication interaction is not shown in the digram
since internal
... for 3ds 2.0 we need to collect information
... the 3ds server gives you libraries to collect
information.
... I think an issue is how to integrate pre-authentication.
And how does the payment handler interact with the
authentication server.
Ian: We noted out of scope:
A protocol for payment handlers to communicate with a DS or ACS.
IJ: What is the challenge of the browser stored card?
Gildas: Interaction with ACS may
differ by scheme.
... for basic card it will be more complex for interactions
with different schemes.
IJ: Third party payment apps can also support basic card.
Gildas: What's interesting to me
is that more than one payment handler can share implementation
of authentication provider
... how can they share the communication between their payment
handler implementations?
Thomas: I think the answer is
that communications involve the same data; there are standard
window sizes that 3DS servers would open up to display the ACS
web page within a screen
... this could enable interop between different brands
Gildas: In france, in case of auth with cb network, there is network-specific information that needs to be added
IJ: Gildas, could you illustrate this / write down data for a future card?
Gildas: Ok, I will try to illustrate this
<anthonyvd> +1 diagram was useful
IJ: I would like to move diagram to the 3DS wiki
https://github.com/w3c/3ds/wiki#deliverables
IJ: Who wants to help drive this definition (e.g., with experimentation)
Michael: I volunteer
<alyver> Will meet internally with the current team experimenting on PRAPI and get back to you.
IJ: Who is interested in implementing?
<Ken> 1+ for AXP to express interest in prototyping
anthonyvd: It's a lot of friction
to implement specific things like this in the browser,
especially where SDKs are involved.
... so this feels to me like a payment handler feature rather
than browser.
... I do agree the browser would have a role regarding
filtering
... but I think that communicating with the authentication
server will be more costly
stpeter: I will need to dig in more.
asolove: Although the flow
diagrams are helpful, they don't yet capture all the
complexity. I don't think it will be possible to implement 3DS
fully with a payment handler.
... I think that the 3DS method URL is something that the
authorizer will send back; you need to create a frame in the
page; that will not be something that the payment handler will
do
... some things are going to require access to the page
Gildas: Are we talking about
integrating 3DS 2.x or 3DS 1.0 also?
... for 3DS 2.0 there are other ways to integrate than
frames
... I suggest we focus on 3DS 2
asolove: Even on 3DS 2, you have
2 options - web integration is invisible iframe
... from the issuer (for fingerprinting)
... but the other option is native integration (which requires
SDK)
... it won't be implementable just as a payment handler
<anthonyvd> +1 to list of challenges that require stuff outside Payment Handler capabilities
<scribe> ACTION: asolove to write down some considerations like this
stpeter: I need to look into this more, but if functionality needs to be in web content v. in the browser chrome, that might be a security concern.
<Zakim> anthonyvd, you wanted to talk about genericity
anthonyvd: +1 to Peter. If the
browser has to do something specific to 3DS ... an approach
would be to specify some more general capability (e.g., about
authentication)
... that will make our lives easier as implementers.
IJ: First label for me for Adam's
issues would be "what can't we move to the user side?"
... Any other implementer volunteers?
<scribe> ACTION: Ian to coordinate with people who volunteered to help experiment to get a sense of expectations before FTF meeting
asolove: I am curious how much progress you want to make now while the 3DS 2 spec is not completely done
<asolove> +1
Brian: Version 2.0 is the version
going live this year. That one won't change. There will be
yearly releases.
... agree with Ian that feedback can be useful for the EMVCo
group
IJ: What makes the most sense as
a scope of activities for this TF for the first 3 months?
... e.g., proof of concept?
... architectural discussion to ensure no obstacles?
Ken: I suggest we review the
value proposition for web payments
... notably for browser vendor consumption
... regarding Ian's question about priority for the first 3
months of this task force,
... another option is to continue to focus on building support
for the work of the task force
https://github.com/w3c/3ds/wiki
<scribe> ACTION: Ken to work with Amex colleagues to build value proposition story especially wrt browsers
<Ken> 1+ for call in 2 weeks
<anthonyvd> +1
<asolove> +1
Proposal 1 February
<OlivierMaas> +1
RESOLUTION: 1 February next call 11:00 ET
<asolove> thanks!
