We review slides from Danyao.
Danyao: This is a real group
effort; thanks to Benjamin and AdrianHB!
... We've boiled down the problem statement to using WebAuthn
as a drop-in enhancement for 3DS on the Web.
Benefits:
- Lower friction compared to step-up challenge mechanisms
- Growing support of built-in authenticators
- Phishing resistance will improve security
- Will make it easier to bring tokenized payments to the web
IJ: Why?
Gerhard: Tokens will be stored on
the server
... you need a key pair to use the token
... effectively the mechanism is;
* I give you a token
(e.g., to Netflix)
* And there's a cryptogram to prove not a replay or MITM attack. The TSP issues the key pair
* During the the transaction, the key pair can be used to sign the token
(Ian wants to return later to the token question)
Gerhard: Delegated auth is
another topic of interest.
... I think there are opportunities to use the same concept of
cryptograms here
Danyao: For now we make some assumptions for simplicity:
* User has private key in FIDO authenticator
* Issuing bank has that public key
* Credential (ID) is bound to a particular instrument. The browser maintains the mapping between the credential id and a payment instrument abstraction.
Danyao: In our initial experiment
we are still using a form.
... user pushes "pay" button
... browser UI shows up and asks if user wants to pay money to
the payee using a particular instrument.
... browser doesn't store PAN
... ID known to the browser has an associated displayable
string
... when user hits "confirm", then the platform UX prompts the
user to authenticate.
... in the background, browser invokes WebAuthn API to get the
assertion, which passes to the PSP, which passes it to the
issuer to confirm this corresponds to enrolled user
Gerhard: I think that the auth screen also needs to show the origin of the party requesting authentication (of the RP)
Danyao: That's possible.
... Note that WebAuthn change...PSP can request credential.
This is NOT the Dirk Balfanz proposal which binds each
credential to a specific origin.
... the proposal here is that ANY third party could ask for it
ONLY IF asked via PR API.
[Enrollment]
Gerhard: I like it. Some things to consider:
- Can you do registration just before payment? It allows you to bind it at that time
- There is already a potential challenge...BOA could do it during checkout. They can also render the display
- If you want to do it up front, remember that you need a phase to "link and activate"
scribe: the bank might be able to do registration in the 3DS flow as well.
Danyao: We want the user to not have to prove themselves to the bank twice.
Gerhard: Look into "Activation
during shopping" ....you can't do it in 3DS2 so you need to
take that into account
... if the merchant indicates flag in 3DS to "please register
the guy" that would allow the installation of the payment
handler
<scribe> ACTION: Gerhard to add an issue re merchant preference to the SRC issues list https://github.com/w3c/src/issues
Next meeting: 21 July
Danyao: Then let's talk to WSPIG on 23 July