Web Payments Working Group

Today's agenda

hello everyone - Ian is unwell today. We will be meeting on zoom.

<benoit> (on IRC, bit can't join the call quite yet)

<Luis_Nacha> call in number says meeting has not started yet

AdrianHB: Introductions

Danyao: presents UX mockups

Danyao: and sequence diagrams

Gerhard: This can be a payment handler from anyone, right? Not just the PSP

Danyao: Correct

<Luis_Nacha> Will non card based payments, like ACH, be an option?

Danyao: Issuer can chec using "isUserVerifyingPlaformAuthenticatorAvailable" method
... [Shows do you want to enrol modal]
... Assuming user consents, there's a new API (with three options - working with Stripe to determine)
... Issuer will submit information to allow credentials to be created

Tomasz__: Is that method to check for the authenticator already available?

Danyao: Yes

Tomasz__: Can it be called silently?

Danyao: Yes, it can

JeffH: Yes

Danyao continues to walkthrough sequence diagram (creation on credential)

Tomasz__: Can you explain which context payment instrument will be set?

Danyao: Today, everything is modelled around Payment Handler. Here, this credential is associated in a global sense - it's more analagous to a WebAuthn credential
... Options include:
... 1) Extend Credential Management API (new subclass of PublicKeyCredential)
... 2) Tie it to an issuer/ASPSP payment handler

Tomasz__: Can you tell more about the name and icon?

Danyao: It's used in the checkout flow

Tomasz__: Where does the challenge originate from?

danyao: great question. Here the Issuer is the Relying Party, who provides the challenge. The Browser passes the challenge to the FIDO component

Tomasz__: What's the outcome of this process

Danyao: A PublicKey Credential and some meta data associated with it ?

Tomasz__: How does this benefit the merchant? What do they receive?

Danyao: Remember that merchant started off with a vanilla 3DS authentication. The extra data is for the issuer

AdrianHB: It's the issuer making the decision to do this enrolment

<clinton> where can the sequence diagram be reviewed offline?

AdrianHB: and the incentive is that subsequent transactions are streamlined

<Luis_Nacha> So an instrument is a payment method which can be card, credit push (ACH) and potentially other funding options?

Gerhard: From an issuer perspective, we may have already created a credential, for example on boarding

<stpeter> of course, the browser and issuer or network could also collaborate on pre-enrollment of the user, before the user is in the midst of a checkout flow

Gerhard: it would be create to link to these special credentials

<stpeter> IOW, +1 to Gerhard

Danyao: Christian Brand made the same point. What if there are multiple instruments? What would issuers prefer?

Gerhard: It's the human that's important
... it would be good to link a list of instruments
... we need a tight binding

danyao: I think the linking needs to be non-silent for users from a security and privacy perspective

gerhard: agreed

Chris_D: I dispute that drop off isn't an issue - if something went wrong during the webauthn enrolment, the user might well close the browser window, and so the authorisation (and the CAVV) might not happen
... hopefully the trial would be able to prove or disprove this

AdrianHB: I wonder if the enrolment experience can be made asynchronous

danyao: this is a good point. We were wondering if we should communicate back to the merchant - you have just told us why

<mhofman> Couldn't the secure modal communicate back the result of the authorization through regular service worker messaging ?

<stpeter> clinton: https://drive.google.com/file/d/1wFHG9gsG7JO58YP8yhj-seX_ypGBeOMQ/view

<AdrianHB> @mhofman: that's what I'm suggesting +1

<stpeter> clinton: and https://drive.google.com/file/d/1rrX5roNwSPGwgiH17i61kl2rZhKdeFZx/view for checkout

danyao: goes to subsequent transaction flows
... instrument selection is unchanged
... we are using here the AReq message to check for credential

and returned by ARes

danyao: the ACS can return all the credentialIDs associated with a payment method
... it's up to the browser to match to device
... if no platform authenticator is available, the flow should fallback to previous behaviour
... open question: What happens if there's no matching credential. Preferred option: return "authentication failed" but we're following up on alternatives
... so we avoid empty UI

<clinton> +q

Tomasz__: one possible solution, there's the hasEnrolledInstrument method. This could be called to see if the credential is enrolled

danyao: we can definitely use hEI, but we need to be very careful about fingerprinting risk

clinton: at a very high level, the pink boxes are new?

danyao: yes

clinton: I am thinking with my EMV hat on

danyao: for the pilot, Stripe are playing the role of the issuer
... now the new UI

[danyao shows UI]

[describes Web Payment Cryptogram]

danyao: the network data is used to create entropy for the challenge
... the browser creates the challenge
... this should also allow us to meet the dynamic linking challenge

Tomasz__: This is very interesting
... especially the binding in the crytogram
... How does the browser know the merchant domain?

Danyao: Browser will look at origin in the top frame

Tomasz__: Would you also send the payment data to the ACS?

Danyao: Yes

<AdrianHB> Assumption is that PSP invokes PR from inside embedded iframe (as they do today) so both origins (merchant and PSP) are known

Tomasz__: How do we avoid replay attack?

JeffH: On the ARes response, that should have a nonce, which could be included.
... Tomasz__ is right

Danyao: we had assumed that the issuer provided orderID is unique

Tomasz__: we need to extend the 3DS specification

Clinton: I will raise this. It's an interesting direction to take

<AdrianHB> we should also explore using existing ARes fields to carry this data (assuming it is opaque to all but the RP)

danyao: the sequence diagram is still changing
... there is a question about whether the browser is responsible for handling the failure window

[danyao continues with flow]

Tomasz__: How do you see the "Submit PublicKey Credentials call" working ?
... So this would be like a CReq?
... But CReq is currently constructed differently

<AdrianHB> +1 ( it may be closer to the app flow)

Gerhard: Who is going to validate the merchant domain?
... the ACS can't do that

danyao: the merchant or the PSP validates this

gerhard: it would be better if the total was in the network data. Better segregation

<Zakim> Chris_D, you wanted to ask about user experience for user without webauthN and also on trust model

Chris_D: I think the PReq would also work in this flow (which is the point of 3DS2).
... this is a low friction, not a no friction solution
... Is there a trust issue? the point of the authentication is to authenticate the shopper to the issuer. The issue is dependent on the browser to protect the key. If there was a vulnerability in the browser, then the Issuer would be liable for the disputed transaction
... this new approach requires the issuer to trust the browser

<Luis_Nacha> great call and thank you Danyao!

danyao: the credential is protected by the FIDO implementation. It's up to EMVCo/Issuers to decide

next meeting: August 6th