W3C

3DS Task force of the WPWG

01 Feb 2018

Agenda

Attendees

Present
Ian, Gildas, AdamS, Anthonyvd, stpeter, MichaelHorne, MikeD, ChrisMarconi, Drew, Ken
Regrets
Manash
Chair
Ian
Scribe
Ian

Contents


<scribe> Scribe: Ian

Adam Solove review and diagrams

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

Adam: There are 3 parts to this. Some observations about 3DS that I think will be interesting to the browser folks.
... section 2 is about how PR API flow works
... section 3 is on differences / points of contention between the two that makes layering challenging (potentially)

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

Adam: Customer comes to site and starts typing in card number, etc.
... after typing first 6 digits, merchant can look up the card network.
... and which bank issued the card
... in my example it's a Chase Visa
... the merchant (or payment provider) loads the method URL ... it's an IFRAME URL chosen by the issuer
... chase sends the URL to the merchant, who embeds a hidden iframe in the page with this URL
... the designated script does some sleuthing to detect fraudulent behavior via the merchant page; sends data back to Chase
... meanwhile the customer has been typing the rest of the card number
... when the user is done, the merchant wraps up a ton of info about the transaction, sends is through the 3ds server through the network to the issuer
... at this point, based on data issuer collected and what merchant collected, issuer has a choice.
... they can conclude "not fraudulent" or "looks like fraud" or "new device" or "not sure"
... the issuer issues a challenge that further auth is required
... in this case, in the 3DS flow for the web, chase sends back another (iframe) URL to the merchant's page
... the merchant embeds the iframe (now visible) which loads content from chase's servers at a chase-controlled domain
... some form of challenge happens (not mandated by the spec)
... e.g., OTP entered into a chase-branded input form
... chase verifies the 6-digit OTP...and sends response through various parties to the merchant who can say "order complete"
... Any questions?

stpeter: That makes a lot of sense; thank you for the description.

Adam: A few things about the spec
... at each step, there are contractual trusted relationships with known counter-parties
... the merchant has a relationship with a provider...the whole flow on the backend is through known parties, and those parties have legal relationships with one another
... 3DS is generic but things can be layered on top
... the second thing I observe is that, because parties have relationships with one another, the spec is intended to deter parties OUTSIDE of those relationshiops
... the protocol is designed to stop external bad actors
... note that this is an authentication flow AFTER payment has been selected.

High level PR API flow

Adam: PR API is very different
... merchant creates a payment request object (with options and data in it)
... two rough categories of information: details about the non-payment info, and a list of accepted payment methods
... a payment method is a data model (request/response data)
... they hand that info to the browser, which displays intersection of accepted payment methods and registered user payment methods
... and any information that the merchant has requested (e.g., shipping address)
... when control handed to a payment handler, they open a new window (not related to merchant origin)
... how the user interacts with the payment handler is implementation dependent -- what the app does before it hands back the info is up to the app
... in particular it doesn't (through the protocol) interact with the merchant (though it might in the backend)

stpeter: So the payment handler could do 3DS requests....

adam: Will come to that in a moment
... the payment handler returns payload to the browser, which hands it back to the merchant which does what it wants
... the merchant doesn't know what app sent the data (for open payment methods)
... So EMVCo is about relationships from known parties; PR API is about arbitrary parties that may not have established trust.
... also, (2) browsers are acting on behalf of users and are concerned with topics like malicious sites and included iframes
... I initially thought that we would write a 3DS spec implemented by payment handlers, but now I don't think that will work.

a) Merchant needs to know the 3DS server

b) Seems unlikely merchant will hand over a lot of information

scribe: to an arbitrary payment handler, who would then talk to the 3DS server (when no trusted relationship in place)

IJ: Is it by definition that the merchant needs to know the 3DS server?

Adam: It's strongly implied. The business relationship between them is necessary. the transaction involves risks and costs and so there needs to be a business relationship; the 3DS server is taking risk (on behalf of merchant)
... it's hard to imagine in the ecosystem that this would happen without previous relationship established
... also, depending on who you are speaking with, different parties will have different offerings or requirements

anthonyvd_: Thanks for this overview. One question - when you talk about 3DS servers, I'd like to get an idea - who operates them? Stripe? Visa? Chase?

Adam: The 3DS server is in the requestor domain; it is acting on whoever is trying to get paid. So it would be operated by a payment service provider who has a business relationship with the merchant.
... there is also a difference between "who owns the server" and "who wrote the implementation

"

scribe: merchant is not completely but mostly unaware of the mechanics of the protocol.
... in Stripe's case, the merchant makes a Stripe-specific call...takes the data, massages it into 3DS format, and sends it on

stpeter: It seems that larger merchants might run this themselves.

Adam: I don't know.
... some merchants are large enough and do this
... but many large companies also work with PSPs to handle fraud, and many backend relationships

MikeD: In reference to the payment handler, when you say that the 3DS server might not accept a payload from an unknown payment handler, is that a technical restriction or business restriction?

Adam: When I read the spec, there are many parts of the spec where it's expected that 3rd party software will be involved (and it must be certified and tested per EMV specs)

MikeD: We (3DS protocol) punt
... the 3DS server can be implemented by multiple business entities
... and technically we kind of punt on the application and security models taking place at the end of the pipe
... we rely on the 3DS entity to ensure some security functionality...that is further being reinforced by PCI
... but basically we are punting there
... if the payment handler is a technical function, I'm not sure technically that "it would be a problem"
... from a business perspective there may be some concerns

Adam: If we put raw PAN in information for receipt by arbitrary user software, our security team would not be happy wiht that

MikeD: We might not either

IJ: IN passing, a design pattern - request filtering.

Adam: The harder part is that the spec as written requires who ever is implementing the authentication have access to the merchant page
... to put iframes in pages

<anthonyvd_> +1

Adam: I think browsers will not want to allow arbitrary parties to insert iframes in pages from other domains

how to resolve issues

Adam: There are some possibilities. There is a separate native flow enabled through the spec.
... while that was designed for native mobile apps, might also work for other types of apps
... there's a third party SDK specific to the platform ...it is embedded in the app and does the 3DS work
... I can imagine a world in which you install an app that can somehow register as a "3DS handler" that could implement the native auth solution
... the other possibility is that the 3DS authentication flow also allows an out-of-band auth
... the issuer uses an existing auth by issuer of customer
... so instead of having to do iframe and UI business, an out-of-band auth takes place

stpeter: Based on my read so far, what you are suggesting seems not unlikely.
... which the mobile flow, there's a registered app (e.g., from app store) that becomes a trusted application that has that channel back to the issuer (for example)
... that app fingerprints the device, and can be used for risk assessment
... for the browser flow, we don't have that kind of access
... as a result, any sort of fingering printing or auth of the user might go through a 3rd party authenticator that you have on your phone
... and there is some interaction between your device and the browser

IJ: Any WebAuthn experts here?

stpeter: I will speak with someone about that today

anthonyvd_: We are talking a lot about phones and 3rd party apps, but we also have platforms without third party native apps
... payment handlers won't necessarily require pre-installment to be available; chrome is working on just-in-time installation

adam: Another option - we could make a proposal for how it *could* work (in the EMVCo spec)
... There is a version of 3DS 2 that is deployed; but the volume of people who will use the spec is low..but whatever version is around when laws change in the EU, is going to be in effect then

IJ: Maybe mention in last section "new EMVCo option" in future spec

https://github.com/w3c/3ds/wiki/Agenda-20180201

Scope - do we insist on a browser-only solution?

Proposed: This task force should develop a web-only 3DS 2.x authentication flow

<anthonyvd_> +1

<asolove> +1

<stpeter> +1

<gildas> +1

stpeter: not sure we have all the right people in the room to make a final determination

ian: Agreed
... I'd like to postpone my action re: "scope to FTF" until we've dug in further

Ken: I think that this level of detail is important, but should we get a higher-level vision from browser vendors on this?
... I am hearing support from Google, not explicit statement from Webkit (based on Monday's call)

IJ: I think the Adam-style analysis will nourish that

next call

Adam: I can take an action to pick an approach and push it as far as I can and find the problems I discover

+1

IJ: Why is just-in-time install relevant?

Adam: Because the merchant could specify a 3DS server at the time

<scribe> ACTION: Adam to investigate the option where payment handler (e.g., just-in-time install) does stuff

Summary of Action Items

[NEW] ACTION: Adam to investigate the option where payment handler (e.g., just-in-time install) does stuff
 

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/02/01 20:40:54 $