<scribe> Scribe: Ian
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.
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
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
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
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