WebAuthn and Web Payments -- Transaction Confirmation, 3DS2, SRC, etc.

[js165]

There is an apparent desired convergence amongst WebAuthn, Web Payments, 3DS2, SRC. A non-trivial detail being a perceived need (on the part of some players) for transaction confirmation. This issue #1396 was initially submitted in the latter spirit (see original post, below).

@ianbjacobs has recently written a blog post providing an overview of this multi-faceted landscape that folks may find helpful: payments-and-authentication-driving-toward-a-whole-greater-than-parts.

Further below, @adrianhopebailie summarizes and links to his "WebAuthN + Payment Request = Payment AuthZ" proposal (which is part of the transaction confirmation (txconf) topic).

This issue is a suggested place for further webauthn-focused discussion along these topics.

---

ORIGINAL POST (this issue #1396):

Transaction Authorization provides a simple and effective method to implement the PSD2 Dynamic Linking requirement.
In the Browser case, Javascript injection attacks (as Adam Langley explained) are a problem for the relying party to know what the user really sees.
So I think it would be important to have Browsers implementing transaction authorization - rather than removing the extension.

We might even want to find a way to allow Browsers supporting Transaction Authorization even with authenticators that don’t have a display.
One idea would be to let the Browser include the transaction text in the “CollectedClientData” in the case the Authenticator doesn’t provide native support for txAuth.

With that the Browser would send the transaction text to the Authenticator if the authenticator support displaying it, and the browser would display the transaction if the authenticator doesn't support transaction confirmation, e.g. most security keys.

Originally posted by @rlin1 in #1386 (comment)

[equalsJeffH]

on 2020-04-01 call: discussed the general threat model of having browser display arbitrary strings supplied by RP. browsers generally skeptical of doing so. Bill Leddy (visa) explained the long history behind this overall request and that they'd use it if it existed. BillL to "champion" this issue.

[rlin1]

@equalsJeffH:
a) What exactly is the potential harm that could happen when displaying arbitrary strings? Could you give an example?
b) Would a "framing" be sufficient, e.g. Browser displays "The website acme.com asks you to confirm the following transaction: [transaction string as provided by RP] [[Reject]] [[Accept]]?

[rlin1]

For accessibility support, Browsers support screen readers. We need to ensure our proposal does not exclude the use of such technology.

[rlin1]

It might be worth to check how Android Protected Confirmation supports Screen Readers.

[adrianhopebailie]

It is not a generic TxConf solution but I've been iterating on a proposal to use a combination of the Web Payments APIs and WebAuthn to at least solve this for payment authorization:

https://github.com/w3c/webauthn-pay/blob/gh-pages/proposals/pr-webauthn-txconf.md

It's still light on detail but I would like to flesh this out in collaboration with WebAuthn folks if there is interest.

My proposal assumes that the RP is the entity that holds the account of the user (or a trusted partner thereof). i.e. In the card world this would be the issuer, in PSD2-land this might be a PISP or an ASPSP.

It also assumes that the RP has installed a Payment Handler (a Service Worker that can respond to Payment Requests) in the user's browser.

It's possible that we find a "lite" Payment Handler model whereby the RP simply registers during WebAuthn enrollment flow that the credential being created can be used to authorise payments.

The goal is that when the website invokes Payment Request API the user can select the RP as the Payment Handler and instead of the Payment Handler needing to render UI the browser displays the payment details to the user as part of a WebAuthn Transaction Confirmation screen.

In this case, the data (amount, currency, payee origin) displayed is well structured (i.e. not "arbitrary strings") so should alleviate this concern at least.

[rlin1]

Look into experience from Browser Notifications that RPs can register for.

[rlin1]

txConf could potentially be invoked directly by a Payment Handler (that has structured information about the payment).

[cyberphone]

There are drawbacks using a flow where you take the payment request directly to the Bank for attestation because then the Merchant must:

• Provide its receive account in the request
• Be able to trust arbitrary Bank signatures

https://cyberphone.github.io/doc/saturn/saturn-v3-presentation.pdf#page=2 shows an entirely different solution which (modulo encryption) is pretty much how EMV transactions are architected.

By decoupling authorizations from the actual payment system you also get away from having to deal with ISO 20022 etc in the PaymentHandler