3DS Task Force

22 Mar 2018



ChrisDee, Ian, Kristina, WaelIbrahim, stpeter, asolove, Jimmy, Mattsaxon, Gildas, ManishDeliwala, MattS, Chris, Dee, (Worldpay), BrianPiel, LauraTownsend, Alyver, Ken, MikeDonovan


Singapore meeting (and who leads)

Agenda of this call

FTF agenda in Singapore




Ken: Still have more questions than answers so far

<Matt_S> is there a reference to this proposal that Ken mentions?

<Matt_S> e.g a URL?

no specific proposal

Ken: I am requesting additional support to move discussion forward.

Ian: There is - (1) wiki mission statement (2) issues list (3) some musings from me... https://github.com/w3c/3ds/wiki/request_params

<stpeter> Matt_S: There is a document at https://github.com/w3c/3ds/wiki and the GitHub issues have good discussion, see https://github.com/w3c/3ds/issues/2 and https://github.com/w3c/3ds/issues/1

Ken: Although Mastercard has put forward a business case, and Amex gets it, but it may be necessary to do more (e.g., to make the case to browser vendors)

mattS: Thanks for bringing me up to speed, Ken

asolove: I volunteer to do some prep work on a new flow option
... I have seen some white papers from networks in the past couple of weeks around "delegated authentication"
... normally, to meet the SCA requirements, we have assumed that the issuer would own the auth
... but delegated authentication creates an option where the merchant does the auth
... use case: when you use a card on a site that you visit frequently, you are challenged via the issuer
... but, if the 3DS comes back successful, then the merchant can (if they want), in the future,
... the merchant can send a charge without doing 3DS for this customer
... the merchant promises that it has log in method that meets SCA requirements and therefore I request that you process without doing the full challenge
... so the subsequent challenges are between merchant and user
... I think this puts us in a world where WebAuthN can solve issues for merchants

Wael: In the first usage, the user went through a full 3DS flow
... but the second visit might be a fraudster

asolove: There are 2 aspects to this (1) financial
... the merchant may not get a liability shift in this case

(2) to meet SCA requirements, the auth that the merchant does of the customer needs to be as strong as the initial 3DS flow

scribe: that implies 2 factors
... perhaps login + fido key or OTP
... and under PSD2 one factor must not be static (it must be transaction specific)
... it's a high bar for a merchant, but for many it will be do-able
... and if the browser has a way to do this, this standard would help a LOT of merchants do this

Wael: Why would the merchant choose to forego 3DS and accept liability? What's the benefit to the merchant?

asolove: I think merchants are suspicious of the 3DS challenges (though we expect them to be better with 3DS 2)
... you can imagine that if you are a big merchant you might say "I can auth biometrically using my native app; we have this capability, so I'd rather not load 3rd party content that I don't control"

brian: It's more complicated than is being described. Issuers ultimately have to assess the risk on each transaction
... unless an issuer has the means to understand the transaction, they can ultimately decline
... it's more than simply an auth occurred, info about context for that transaction is necessary
... 3DS 2 real-time risk assessment is how this is addressed

<Matt_S> The same is true for the acquirer, they may need to escalate to needing full SCA even if issuer doesn't and merchant doesn't

Brian: I agree we need to look holistically at authentication at a high level
... I think the conversation needs to be high level requirements and see how it fits with 3DS

(Ian agrees)

Brian: There are specifications but there are programs on top of the standards; that adds more complexity

stpeter: I agree there is a lot of complexity here...but still worth exploring Adam's suggestion and seeing what gaps there might be
... one thing that is attractive about this approach is that, as Ian noted, the Web AuthN specification (which provides strong multifactor) has moved to Candidate Recommendation
... we are expecting to ship in Firefox
... that gives strong auth of device and user
... there will be also information about the transaction...I think Adam should explore his idea as something that is "more web native"; worth exploring and then discussing

asolove: I think it is worth writing it up.

stpeter: I volunteer to help

MikeD: Amex also has some flow ideas that we are writing down
... I think we're open to discussion about data elements that we need the issuer to get
... and the question is whether comes from the merchant or consumer
... we are also aligned with keeping PR API as convenient as possible for the merchant
... as we get into the flows and data elements, then we will ahve a better sense of which API would be impacted
... generally speaking Amex is supportive of Web Auth work

asolove: I'd like to explore every direction, so if you need me to have a look at your flow, I'm happy to do so.

Ken: We are working on flows, as MikeD indicated. Will keep you posted on progress.

Gildas's flows => https://github.com/lyra-labs/poc-w3c-webpayments/wiki/3DSecure-and-PRAPI

Gildas: We have a lot of discussions in Europe right now about liability under PSD2 around strong auth (issuer? acquirer?)
... we need to understand who can realize exemptions

IJ: Gildas, could you write down issues in time for the FTF meeting?

Gildas: I will see what I can do

Q. Value proposition for networks, merchants, PSPs, issuers, browsers, and users.


IJ: Regarding value proposition, we need to get to the next level

MikeD: I think we are still organizing at a higher level of what we want to present into the group in terms of data elements, flows, and authentication

IJ: But what is the advantage of doing this?

MIkeD: Agree we need to write down thoughts on scale.

asolove: I've not made progress on this part, but can commit to do so before Singapore.
... can start an issue on GitHub to gather thoughts
... and do a first draft

MikeD: We think browsers can help us under PSD2
... e.g., auto populate and scale faster

<scribe> ACTION: Adam to draft some thoughts on value proposition and start a GitHub issue to collect ideas

5 April

Next meeting

Summary of Action Items

[NEW] ACTION: Adam to draft some thoughts on value proposition and start a GitHub issue to collect ideas

Summary of Resolutions

[End of minutes]

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