Adam: We had several flows we
considered...
... arbitrary handler scenario would not likely work with 3DS
spec as written
... another scenario is where the merchant side implements the
payment handler, and represents the communications that would
already be in place today
... that approach is do-able, but the question is "why do it
that way"?
... if the merchant knows about the payment handler, why go
through PR API at all instead of JS in the page?
... it's not clear to me that having the full power of payment
request API and arbitrary paymnent handlers would work, or
merchant-based apps would not add much value
IJ: did you think about what modest changes might enable the arbitrary payment app scenario?
adamsolove: If the payment app
comes from the issuer (and the payment app does the flow) that
is a workable
... the tricky part is a couple-fold:
- the merchant doesn't know in advance that they need it to be the chase payment handler
scribe: they don't know in
advance what card the user will enter
... the merchant could accept getting back a card and an auth
if the payment handler is "the right one" but not clear how to
specify that
stpeter: That makes sense.
... the merchant wants to handle any card that comes up...so it
makes sense for the acquirer to do the work.
... one topic that came up in the tokenization calll..there's a
separate cryptogram for 3ds
... we don't want a 3ds payment handler, we want 3ds on top of
the payment handler that gets invoked
... from a user perspective, I want a payment handler
associated with the card I have in hand
(IJ wondering if we need an auth() step between show() and close())
stpeter: We have a technology at
w3c for authentication (WebAuthN)
... 3DS is doing that in a different way..if we go down
WebAuthN, that's a different approach
... suppose I'm a regular shopper at a merchant... the merchant
could register an authenticator on my device (E.g., smart
phone)...I could authenticate with the merchant since I am a
frequent shopper there.
... then essentially staples does some sort of authentication,
but that information is then passable on the backend
... I'm not sure how that factors in and doesn't help us with
first time use at a new merchant
alyver: Regarding 3DS using tokens..won't that be a problem (e.g., for ApplePay) ....since data slots are already being used?
stpeter: We may need 2 cryptogram fields; that came up in the call the other data
https://github.com/w3c/3ds/issues/3
Rahul: This is a good issue to
track
... we are looking at combining the cryptogram that comes from
the token with the cryptogram we have from 3DS-2 and giving a
combined cryptogram in the response. That's one idea we
have
https://github.com/w3c/3ds/wiki/request_params
MikeD: It sounds to me like you
are talking about orchestration...whether we get a host-based
token and cryptogram...or
... your talking about some simple request from the merchant,
and a second flow
... for getting a cryptogram
[IJ: Yes, WebAuthN does that, I think]
MikeD: EMVCo is working on an
orchestration spec
... there's more to come here with a close tie to 3DS
... I would be a little worried about taking the payment flows
off the merchant site for this
... if we need a second flow to help with this, that's
something we are also thinking about on our side
Rahul: Going back to the
information sharing that may be needed (from the
merchant)
... I think the key goals for 3DS 2 is risk-based
authentication
... that's using data that the merchant has
... solving for the info imbalance between merchant and
issuer
... either that could be proactively sent from the
handler,
... or the app could have a hook to get the data..
stpeter: I have two questions ...
I would like to hear more about what EMVCo defines as
orchestration
... the other is that my understanding of 3DS 2.0 is that
network or issuer needs the auth information
... the auth is not between the merchant and cardholder
... let's say we go down a path where the merchant requests
user verification on behalf of the issuer or network
... what does that look like from a user interaction standpoint
and a fraud responsibility standpoint
MikeHorne: We've been thinking
about this more...it might be possible technically where the
browser or third party app is the requestor, but each scheme
might need additional data such as merchant id
... whether that information is sensitive is one thing
... another issue is tampering
... when the areq hits the directory server, it does some
checks to make sure that the merchant has been enrolled in the
program
... if the 3ds requestor id is given to the browser we want to
make sure that the merchant behind the browser is legit
https://github.com/w3c/webpayments-crypto/wiki/Signatures
IJ: Where does added confidence comes from with signatures?
Peter: presumably the key comes
from a certificate authority the network finds acceptable
... whether that's an architecture we want is another story
IJ: Does it make sense for business reasons to have payment apps talking to their own 3dS servers?
MikeD: What's happening on the
ecommerce side is that we are being asked to do multiple types
of services we haven't done previously
... there is not a lot of secondary data that requires
confidentiality
... we have had debates relative to privacy and those points
are well-taken
... the baseline is an integrity service for non-PII non-track2
core PAN data
... that's where we landed...personally I don't see a problem
with the payment handler providing certain types of data.
stpeter: That is helpful
... from a privacy perspective we could have some conversations
about whether the device information did a lot of PII but
that's a separate topic
... I think that one of the challenges we have in this space is
that we don't know what the users will do
... we can speculate that it would be great for the user to
have a payment app, but if users don't have those things, that
model that we find attractive won't take off
(IJ: I wrote it down this way: "The way 3-D Secure 2 is deployed today (on the merchant side) is that the user has no software installation obligation. There will be challenges in getting user adoption of payment handlers. That challenge might go down in the case of browser-as-payment-handler."
MikeD: 3DS 2 is designed to reduce user friction
======
1. Theoretical benefits of moving the authentication to the user side
2. Network and issuer buy-in to that model
3. Test it to see if it creates a better UX
scribe: including data model
https://github.com/w3c/3ds/wiki
IJ: Built into #2 is getting consensus from the EMV side that this approach is compatible with the 3dS vision
stpeter: Fraud prevention is an
important priority ...
... what we are trying to do is make it happen in a way that is
both appropriate in the web architecture
... e.g., using web auth
... I can talk to our user research folks to see how we can fit
this discussion into their schedule
... we need to figure out whether cardholders are going to go
through some of these flows
... what will step-ups look like?
... will people do them? U2F and U2A are becoming more
common...can we build that into existing apps or password
managers?
... we need to figure out how to leverage some of the work
already happening.
... can some of the web auth happen happen in more of a
frictionless way? That's another interesting topic to follow up
with them about
MikeD: From an Amex perspective
we'd be open to that.
... we are working with FIDO
... we'd be open to that sort of thing in web-centric
environment
... it's not just about security, it's about interop,
functionality capabilities, and compliance
... e.g., what gives us confidence in security levels of
authentication?
... it's conceivable to modify 3DS protocol to add data fields
(e.g., that identify different stakeholders)
... there's openness to explore that type of effort
... needs openness on the browser side as well regarding
integration of both types of work
stpeter: Great to hear. The
browsers are new here, and you've done a lot of work on this
for many years
... the browser is a new entrant to the conversations...we also
care about functionality, interop, security....compliance is
new to us as well
... I think there is definitely an opportunity here to work on
solutions that will be adopted
MikeD: I think the power of this
effort is to deal with that acceptance
... we recognize that there are potential benefits and
efficiencies that are possible.
==> https://github.com/w3c/3ds/wiki
https://github.com/w3c/3ds/wiki/request_params
IJ: Any volunteers to work on code / flows with Singapore presentation in mind?
Rahul: Mastercard is continuing
its commitment to the work; we are looking to backfill a
position
... Brian Piel is going to have a more prominent role in this
task force
asolove: I volunteer for
discussion on this
... we represent several merchants interested in this and could
help in prototyping
22 March