W3C

3DS Task Force

11 Jan 2018

Agenda

Attendees

Present
Ian Jacobs (W3C), Laura Townsend (MAG), Manash Bhattacharjee (Mastercard), MattDetert (MAG), Gildas Le Louarn (Lyra Networks), Olivier Maas (Worldline), Holger Kunkat (Mastercard), Jalpesh Chitalia (Visa), Kristina Smyth (Discover), Brian Piel (Mastercard), Andre Lyver (Shopify), David Ezell (NACS), Chris Marconi (Capital One), Ken Mealey (Amex), Mike Donovan (Amex), Clinton Allen (Amex), Adam Solove (Stripe), Tabitha Odom (Amex), Thomas Bethke (Amex) Jimmy Wardrope (Amex)
Chair
Ian
Scribe
Ian

Contents


<scribe> Scribe: Ian

https://github.com/w3c/3ds/wiki

Introductions

Adam, Alyver: Want delightful 3DS experience for customers

[Ian hearing balance of security and end user experience is a priority]

Mission walk-through

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

Logistics

https://github.com/w3c/3ds/

https://github.com/w3c/3ds/wiki

https://github.com/w3c/3ds/issues

Next meeting

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

Summary of Action Items

Summary of Resolutions

  1. 18 January 11:00 ET
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/01/11 17:25:06 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]