W3C

3DS Task Force

05 Apr 2018

Agenda

Attendees

Present
Ian, Adam, gildas, Kristina, Laura, Ken, BrianPiel
Regrets
Chair
Ian
Scribe
Ian

Contents


Agenda

Value Proposition text

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

Adam: I think we are making progress

IJ: Do merchants care about compliance or is it more issuers?

Ken: +1 to amending that...there are compliance obligations for multiple parties in the ecosystem (not just issuers)
... e.g., PSD2 Europe

IJ: I wasn't sure whether compliance was the top point for merchants...

Brian: There's another aspect of this which is about the reality of approval rates
... if there's not enough information in the transaction, issuers may not be confident in approving a transaction
... it's not just about risk models, it's increasing approval rates based on getting sufficient information...everyone benefits from that.

Ken: +1. The other thing I included was the Verizon data security report; I think that report has a lot of credibilty
... fraud is accelerating and so there are compelling reasons for merchants to look at that

asolove: Just to speak to that question from the merchant side...one of the challenges is the different classes of merchants
... some merchants may have entire teams devoted to meeting PSD2 requirements
... other merchants might be happy about strong auth to increase approvals and for evidence during disputes
... still other merchants might not be following PSD2 and be taking a wait-and-see stance
... for those merchants, it's more the issuers or PSPs telling them they need to do this now before decline rates go up
... so this is more a stick than a carrot

Ken: We see that, too

asolove: One thing that PSPs are trying to do is educate customers about decline or dispute rates they might not yet track
... so PSPs might be able to show merchants actual dollar losses
... due to not performing the challenges

Laura: I agree with what people have said so far. Issue with 3DS is how it will enable merchants to achieve the goals; jury is still out
... would need to validate that.

IJ: Who does GDPR mostly affect? Merchants? PSPs? Both?

asolove: I think this is similar to the PSD2 situation
... large companies will be audited and they are directly interested; they will also check that their suppliers comply
... there are also many smaller companies that may be aware of this but are not yet doing much about it
... in this case, the PSP will impose something to ensure their own compliance, and may partially fulfill what the merchant needs to do

gildas: When we were discussing with merchants GDPR compliance, they are asking how they can identify the different fields sent to the different parties
... for example with 3DS2, the specification indicates that a lot of information about a phone is send to the SDK...this may create issues for merchants who don't want to transmit information about their customer's locations
... I think the 3DS 2 spec may not be specific enough
... so transparency is going to be important for merchants and customers

IJ: Maybe we need a GDPR and the web workshop

Ken: let's document this concern; we can take the question back to EMVCo
... What I understood Gildas to say is that there's a lack of clarity about how to handle GDPR in the context of 3DS

Gildas: Yes. In addition, merchants want to know exactly what information is sent to which 3DS roles

IJ: I plan to reread Ken's draft
... the default would be to share that in Singapore

(Ian hopes Laura will review the text)

Ken: Agree with the observations about different interests for different-sized merchants
... could we also think about how we could come up with different sized implementations of what we are trying to do here
... for example, would PSPs take up more of what needs to be done? browsers?
... it might be a carrot that moving to the user side reduces merchant cost

asolove: Current expectation is that PSPs will pick up more of the responsibility
... especially for small or medium merchants
... for shopify or woo commerce changes are at the platform level
... big companies can productize more easily, and gain control over user experience and auth
... it would be interesting for the browser to own with the actual authentication piece (through U2F and FIDO)

<asolove> +1, would love to see that flow

IJ: One thought is an auth() method in between show() and complete(). Could be used to harmonize the UX of authentication for a variety of flows (3DS or other)
... might be usefully generic to get more browser interest

Brian: What you describe is how 3DS operates today where there is decisioning in the middle; it's more of a client-based scenario where the browser provides a consistent UX for the merchant

------

0) No impact of adding strong auth to PR API or payment apps

1) Minimal data from merchant through PR API to enable SCA

2) Change PR API to better support SCA

3) Do something else

IJ: I imagine we will do things multiple ways

Brian: I think "3DS as a client" view
... the payment handling part is mostly on the backend, with multiple ways to initiate.
... mostly I'm thinking about this as adding a layer to what exists

https://lists.w3.org/Archives/Public/public-payments-wg/2018Apr/0010.html

Strong auth prototyping

IJ: In discussion with OBIE
... see Gildas' invitation

Next meeting

- Singapore

scribe: after that 26 April call

<gildas> +1 for remote participation

IJ: I will send WebEx to the list

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/04/05 15:57:12 $