<scribe> Scribe: Ian
https://github.com/w3c/3ds/wiki
Adam, Alyver: Want delightful 3DS experience for customers
[Ian hearing balance of security and end user experience is a priority]
https://github.com/w3c/3ds/wiki
Manash: Authentication is a key
enabler of payments
... approval rates in physical world at 96% but in digital
space only 83%
... fraud higher in digital space
Manash: in some markets, regulation requires 3DS (e.g., India; Europe + PSD2)
[We review Problem Statement https://github.com/w3c/3ds/wiki#problem-statement]
Manash: 3DS 2.x risk engine means less step-up than with 3DS 1.x
[We review flows https://github.com/w3c/3ds/wiki#flows]
Manash: 3DS flow is not currently part of PR API ... question of task force is to determine how to incorporate 3DS into PR API to make life easier for merchant, gain security, improve user experience, get scale
asolove: +1 to the goals
alyver: +1 to the goals
... The gating factor is of course adoption of PR API
Manash: We envisioned 2
flows
... one where the third party payment app is 3DS requestor; one
where the browser is the 3DS requestor
<marconi> question
chris: In these two flows, is it
assumed that the merchant is sending all transactions through
the 3DS flow?
... or does the merchant determine which transactions?
manash: At a high level we want
to incorporate it as an optional flow
... it's up to merchants to determine when to invoke it
... and we are likely to have to do prototypes
Ian: We are likely to want to cover different merchant states: able to accept 3ds, preference to accept 3ds, must do 3ds
olivier: What is the
justification of using 3DS?
... in the first flow that you outlined (third party payment
app is the requestor)
... the payment app is not in the domain of the merchant;
rather in the user/issuer domain
... if this payment app is provided by an issuer, why would the
issuer need to go through a 3DS protocol?
... it's their own server?
Manash: Good point. When a
merchant invokes PR API and says "I can accept tokens" they
don't know who the issuer will be.
... as a merchant, I am making a request but don't know which
wallet will provide credential.
... if I want 3DS flow I need to able to "opt in"
... how does a bank app (e.g., an issuer app) invoke 3ds
server...brianp can reply
... how would the flow change?
BrianP: It doesn't really. It's
up to each app to determine whether to invoke 3DS
... it's an ecosystem decision to determine when and if the
server is called
... it comes down to simplifying the interfaces into each of
those scenarios, and enabling the merchant to integrate in a
simpler fashion
... if the issuer is the issuer of the payment app, they decide
whether to call the server.
MikeDonovan: We just talked about what merchant "state" would look like in-app...it sounds like there needs to be work done in PR API as well....I wonder whether the 3DS work is the primary focus, or whether there are more states
Ian: Olivier, was your question answered?
Olivier: More or less...but to
get everyone on the same page, I would like a better
understanding of provisioning of the payment app
... who provisions it, how does it work?
Manash: Olivier, are you looking at how a card is provisioned in an app?
Olivier: We've (at Worldline)
done a proof of concept using card-in-browser
... we haven't seen anything yet with an interface between
browser and third party payment app
... it's need to understand how all this works
Manash: We have done multiple
prototypes in the last 6 months..where very payment apps work
in the PR API environment
... I can send links to some demos
See: https://github.com/w3c/payment-request-info/wiki/Introductions
Jalpesh: Manash and Brian, the AV
piece that you are referring to, are you thinking just Basic
Card or other payment methods?
... e.g., also when encrypted, or tokenized card payment?
... in which case - who does the AV?
... payment handler or browser doing the call?
Manash: Initial idea is for 3DS
flow to be an add-on that works across multiple payment
methods
... regarding who can invoke the 3ds requestor, the wiki
describes 2 flows
... whoever has the credentials should be able to be the
requestor
... in some cases the browser might do this (basic card); in
some cases the payment app might do this
... so the proposed architecture is more general than just
browser..enables third party payment app to be the
requestor
Jalpesh: That makes sense
... regarding tokenized card payment, how would that work?
Manash: As we do more digging
into the architecture, we should be able to answer it.
... question is how to use 3DS on top of tokenization
BrianP: 3DS 2.x designed to
handle tokenization
... each network will decide how to handle FPAN or token
... the idea is that as each network handles the data, the
results still apply (token or not)
... this is about authentication
... at that moment, 3DS 2.x can handle it across the
board
... but each network will have its own specifics
https://github.com/lyra-labs/poc-w3c-webpayments/wiki/3DSecure-and-PRAPI
Manash: next meeting let's
discuss deliverables.
... goal would be to have a high-level framework by the time of
the next WPWG FTF meeting
<Olivier_Maas> When is the next F2F meeting?
Manash: and also get volunteers to get proofs of concept
Ian: Next FTF meeting is still being decided; aiming for mid-April
Manash: Also, 3DS 2.x milestones are relevant for us
IJ: Key 3DS milestones?
BrianP: Right now target is
2018
... it's a work in progress
... I'll see what we can share from EMVCo side
https://github.com/w3c/3ds/wiki
https://github.com/w3c/3ds/issues
Proposed: 18 January
<Olivier_Maas> +1
<Gildas> +1
<alyver> +1
<marconi> +1
<dezell> +1
Manash: I will not be able to attend, but BrianP can represent MC
RESOLUTION: 18 January 11:00 ET
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/AdamS/asolove/ Present: Ian Laura Manash MattDetert Gildas Olivier Holger Jalpesh Kristina BrianPiel alyver dezell ChrisMarconi Ken MikeDonovan ClintonAllen asolove Tabitha JimmyWardrope Found Scribe: Ian Inferring ScribeNick: Ian Agenda: https://github.com/w3c/3ds/wiki/Agenda-20180111 WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]