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