https://www.w3.org/TR/webauthn/
https://github.com/w3c/3ds/wiki
https://github.com/w3c/3ds/wiki/Meetings
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.
https://github.com/w3c/3ds/wiki
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
Next meeting