Joint Task Force WebAuthn/WPWG

21 Jul 2020



Ian Jacobs (W3C), Matthew Lockyer (FISERV), Benjamin Tidor (Stripe), Danyao Wang (Google), Ken Buchanan (Google), Erhard Brand (Entersekt), Tomasz Blachowicz (Mastercard), Mathieu Hofman (Stripe), Jonathan Grossar (Mastercard), Jeff Hodges (Google), Sameer Tare (Mastercard), James Evans-Rong (FISERV), Adrian Hope-Bailie (Coil)
Jon Fontana


<scribe> Scribe: Ian

UX Mockups

Danyao Wang presentation of UX mockups

Danyao: 2 key user journeys for this pilot: enrollment, checkout


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

Next call

4 August

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/07/21 16:31:59 $