<scribe> Scribe: Ian
Danyao Wang presentation of UX mockups
Danyao: 2 key user journeys for this pilot: enrollment, checkout
[Enrollment]
Danyao: We would like to enhance
3DS flow in a regular Web-based checkout experience
... We have a payment handler that the user can interact with
in a 1p context.
... the user is redirected to the issuing bank during the 3DS
flow, there is an OTP authentication (standard 3DS)
... the new bit happens after the user has authenticated via
OTP. The user has an option to enroll an authenticator (on
device)
... if user says "no" transaction end as usual.
... but if user says "yes", the user is prompted to touch the
authenticator
... ...note on pilot: scoped to MacOS only with TouchID
... the RP is the bank
... this is called the "in line enrollment" flow; we are
piggy-backing on the existing 3DS flow because we think users
are more likely to opt-in after the OTP authentication
Jonathan: Does this assume that the issuer operates a FIDO server?
Danyao: We are assuming the bank (or a representative) will operate a FIDO server. E.g., the ACS could do this.
Sameer: In the regular 3DS flow,
as soon as the user auth is done, the results goes back to the
merchant who shows a confirmation message
... given that there's a session open with the issuer's bank
here, how is that transition happening?
Danyao: We envision that the
issuer is communicating with the PSP that is hosting the (PH)
window
... we defer completion a few steps
... there is no risk that the payment would complete.
... but experimentation might suggest that we need to show
"confirmed!" earlier.
Sameer: How would this prompt be shown to the user?
Benjamin: We are having the
merchant 3DS inside a payment handler. Right now there is not a
great framework for that. The protocols are compatible, so we
are experimenting that way in the short term. There might be a
better integration that we can explore in the longer
term.
... ...we understand that the ACS can inject a screen
Sameer: That's the point I was trying to make...is the enrollment part of a WebAuthn flow or a 3DS flow?
Benjamin: Ideally there would be one more browser API
<tomasz_> q
JeffH: Part of Sameer's question is "who supplies the payment handler"?
Danyao: Merchant-supplied payment
handler during enrollment.
... ...maybe in the long term we don't need a payment handler,
just the ability to open a modal window
... but the merchant payment handler is not useful during
transaction time.
<tomasz_> q
<jeffh> tomaz: how would this be made universally available?
<AdrianHB> Tomasz: who will own the payment method?
<AdrianHB> Danyao: In the long term we may create a standardised payment method but for the experiment it will be a Stripe URL
<AdrianHB> [danyao showing checkout flow]
<AdrianHB> danyao: there is a lot going on behind the scenes which we'll cover in the sequence diagrams on Thurs
<AdrianHB> ... for the pilot the issuer will host another PH. In the long term we need to decide if we need the PH service worker at all
<AdrianHB> jonathan: how do you know that there is a key available
Danyao: After the user pushes
"verify & pay", the merchant would talk to issuer bank
using 3DS protocol
... the (modified 3DS server) would return a list of credential
IDs
... those credential IDs are given to the browser ,and the
browser would match (first one wins) from among those
provided
Jonathan: How does the issuer know you are back on the same device?
Danyao: The issuer doesn't need
to know (an assumption)
... our assumption is that the user doesn't need to know which
device.
... the issuer stores ALL the credential IDs stored with the
card
... the issuer sends them all back; it's the browser that picks
one it knows about
... There are two parts to interrogating the system....
... it's still not possible for the RP to silently interrogate
the authenticators
... in this case, once the list of credential IDs, the browser
will show UX; there is no silent yes/no answer
... ...so this is not a silent interrogation
Jonathan: I am hearing that the merchant, by interacting with browser, is ok with webauthn prompt
Danyao: If user cancels, behavior
is same if user cancels
... the browser falls back to vanilla 3DS flow
... same thing happens if there are no credential IDs
available
Sameer: Does the user give consent?
Danyao: We consider that the two
UIs (one from browser, one from authenticator).....we consider
that the user action on the browser UI is consent to go forward
with Web Authentication
... the second one is the authentication gesture
... no consent beyond those two anticipated
Sameer: It looks like in this
proposal, knowledge about authenticators comes from issuer
=> browser rather than the other way around
... if the 3DS method could have a component where it could
query what credentials are available in the browser, and match
what is supported by the ACS, then the Webauthn could be
used.
... that's a thought we had had
... the knowledge about WebAuthn credential has to precede
challenge req/resp
... that's something we may have to look at the sequence
diagram
Benjamin: I think one way to
think about this is a "light challenge" flow...this one would
not have a creq/cres
... our idea here is that the browser can generate a cryptogram
directly, which binds the details in secure hardware on the
customer side
... we should discuss later
... the ACS will always return a challenge URL, but they might
also return with the list of credential IDs to mean they would
be ok to use that flow
... because there is hardware backed secure
... they would have to declare in the ARES whether they are ok
with this alternate flow
acá tomas
Sameer: I think from an ACS POV,
using strong auth will be desirable
... but the question remains: what needs to change to the
standard 3DS flow?
... one of them is returning credential IDs
Danyao: I will send out deck after the meeting, along with 2 other documents that have more details on flows
4 August