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.

@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]]?

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

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

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.

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

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

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

note that there is discussion of @adrianhopebailie's proposal (see above) over in w3c/webauthn-pay#1

Guys, please note most important things for transaction authorization from the perspective of financial institutions like banks, paymenet organisations etc.

In order to make authorization of financial transaction attractive for those instutions and provide better security than SMS/authenticator or bank app where you approve transactions out-of-band the main channel (in which you initiate transaction) you need:

• present the user details of that transaction
• ensure that attacker (assume man-in-the-browser or malware with admin rights on users side) is not able to alter the details, overwrite it, hide it (to present own information), proxy it to the user etc.
• ensure you cannot bypass requirement to be in possesion of the token (so that this can be considered (also) as possesion factor in terms of PSD2)

Are any of those (real threats) taken into consideration and we have means to ensure that it is at least much harder than attacking end customers for example with malware on their mobile devices listening to SMS codes to bypass second factor used to authorize transactions?

I think that is a requirement if we want to make the adoption wide.

The original approach (https://www.w3.org/TR/webauthn/#sctn-simple-txauth-extension):
a) allowed the RP to provide any transactionText (having the expectation it would include something like "Transfer $1000 from account 987654321 to account 123456789".
b) expected the authenticator to display that transactionText and
c) only generate the resulting signed assertion (including the hash of the transactionText) if the user (i) agreed to the transaction and (ii) could provide the gesture (e.g. use correct finger to touch the sensor). The hash of the transactionText is included in an extension that is added/controlled by the authenticator.

The new idea, would also allow some privileged software to display the transactionText - expecting that the the assertion would allow the RP (=verifier) to understand whether the Authenticator displayed it (hash of transactionText included in extension) or the privileged software did (e.g. add hash of transaction Text to collectedClientData or to the same extension but setting a specific flag that privileged software displayed it).

With this approach we would extend the reach as FIDO authenticators without a display could be used as well.
The use of authenticators with display is still possible and even allows scalable security (e.g. using TrustedUI as it is done by Android Protected confirmation).
However, on today's mobile devices, malicious apps cannot easily "infect" other apps or the browser.
Both approaches protect against JS code injection, e.g. through infected ads or ad providers or otherwise altered contents that was loaded via one of the typically many external script sources that are included in web pages.

So at this stage, I think the security aspect is under control. The challenge seem to be
the prevention of miuse via user confusion, by providing misleading transaction Text that is presented in a trustworthly looking browser chrome or on the secure authenticator display.

The original approach (https://www.w3.org/TR/webauthn/#sctn-simple-txauth-extension):
a) allowed the RP to provide any transactionText (having the expectation it would include something like "Transfer $1000 from account 987654321 to account 123456789".
b) expected the authenticator to display that transactionText and
c) only generate the resulting signed assertion (including the hash of the transactionText) if the user (i) agreed to the transaction and (ii) could provide the gesture (e.g. use correct finger to touch the sensor). The hash of the transactionText is included in an extension that is added/controlled by the authenticator.

The new idea, would also allow some privileged software to display the transactionText - expecting that the the assertion would allow the RP (=verifier) to understand whether the Authenticator displayed it (hash of transactionText included in extension) or the privileged software did (e.g. add hash of transaction Text to collectedClientData or to the same extension but setting a specific flag that privileged software displayed it).

With this approach we would extend the reach as FIDO authenticators without a display could be used as well.
The use of authenticators with display is still possible and even allows scalable security (e.g. using TrustedUI as it is done by Android Protected confirmation).
However, on today's mobile devices, malicious apps cannot easily "infect" other apps or the browser.
Both approaches protect against JS code injection, e.g. through infected ads or ad providers or otherwise altered contents that was loaded via one of the typically many external script sources that are included in web pages.

What about threats:

• that would manipulate OS/browser memory to alter the transactionText presented to the user (already exploited in the wild) ?
• that would try to manipulate which prompt containing transcationText is on top (if opening multiple is possible)
• other means on OS api level security mechanisms preventing tricking the user to authorize different transaction that he thinks he authorizes

The above explanation is not enough, i have no knowledge of any security considerations, tests (if any of those have been performed and documentations is available - please let me know). IMHO this is a minimum for financial market to consider this when we speak about authorization of transactions.

@mattimac If the OS or Browser is corrupted all bets are off. This however, is a generic computing issue.

A bigger problem is that there is no such thing as "trusted Web code" which makes WebAuthn less useful for payments than native apps. A payment request would preferably be a strictly formatted JSON message like

  {
    "payee": "Acme Shop",
    "amount": "145.00",
    "currency": "USD"
  }

which is the thing you sign ("authorize"), but the message be would rendered in a user-oriented way. This requires some kind of trusted UI. That payment handlers can't be shared like cards in Apple Pay is another limitation.

This Google-originated presentation
https://www.w3.org/2020/02/3p-creds-20200219.pdf#page=5
indicates that WebAuthn for payments has a long way to go. There is no such thing as "Your PISP" because you are usually not supposed to have a relation with PISPs.

To be fair this is a difficulty in the PISP concept in itself which is why I have proposed in Open Banking contexts that PISPs should stick to processing (by the user) already authorized requests. I.e. become "backend" services vouching for Merchants (and charging them for fees), which is a since ages back established concept, both technically and commercially.

There is no such thing as "Your PISP" because you are usually not supposed to have a relation with PISPs.

I think you are misunderstanding the use case here. In this context the PISP does have a relationship with the user and provides them with a wallet (e.g. Google Pay) but the wallet initiates payments from a custodial account at a bank or other account provider.

A bigger problem is that there is no such thing as "trusted Web code" which makes WebAuthn less useful for payments than native apps.

This is not a problem. The UI displayed to the user is rendered by the client platform (i.e. trusted UI). The data that is signed is the same data displayed to the user. It doesn't matter if the code that invokes this process or handles the output is trusted.

There is no such thing as "Your PISP" because you are usually not supposed to have a relation with PISPs.

I think you are misunderstanding the use case here. In this context the PISP does have a relationship with the user and provides them with a wallet (e.g. Google Pay) but the wallet initiates payments from a custodial account at a bank or other account provider.

I'm not misunderstanding the use case, I only consider it highly unlikely. pre-PSD2 solutions like Card-on-File (CoF) wallets or "secure payment pages" were logical but this one is not because there is no added value anywhere, only added complexity.

A bigger problem is that there is no such thing as "trusted Web code" which makes WebAuthn less useful for payments than native apps.

This is not a problem. The UI displayed to the user is rendered by the client platform (i.e. trusted UI). The data that is signed is the same data displayed to the user. It doesn't matter if the code that invokes this process or handles the output is trusted.

This is the point, how secure is that on client's OS? How is it secured on OS api level? As long as that is not properly secured is not attractive in terms of risks analysis and cannot compete with out-of-band authorization (different channel).

This is the point, how secure is that on client's OS? How is it secured on OS api level? As long as that is not properly secured is not attractive in terms of risks analysis and cannot compete with out-of-band authorization (different channel).

You are right, it is probably impossible to prove that a system is secure. Does that mean that transaction confirmation is useless? Not really, there is literally tons of documented data breach use cases and they show that real-world issues using mobile phone based SW stem from other weaknesses such as:

• servers exposing sensitive data on the Internet
• password phishing
• social engineering
• poor protocols

However, using OOB authorization is still a viable option and is practiced by many banks but is usually only applied in the case a transaction request looks "suspicious". That is, combining the best of two worlds.

More reading: https://cyberphone.github.io/doc/saturn/saturn-v3-presentation.pdf#page=13

From the start of the FIDO Alliance, the working assumption has been that if the OS is compromised then everything else is potentially in trouble but we need to address the parts that we can address. It is like complete awareness of my own ignorance and fallability would prevent me from getting out of bed in the morning, but I managed it again today.

The scalability of the attack (compromised OS) is a consideration for the relying party (and auditors) along with other data when making a decision about the value of the confirmation.

I don't think anyone expects Tx Conf to be bullet proof at the outset, but doing the most good for the most people in the near term is a good goal. Then improving the security of the entire approach in a monotonically nondecreasing manner over time will continue the progress.

I'm not misunderstanding the use case, I only consider it highly unlikely

You will have to tell that to Google who are providing exactly this in India and have millions of users.

I'm not misunderstanding the use case, I only consider it highly unlikely

You will have to tell that to Google who are providing exactly this in India and have millions of users.

I guess you are referring to UPI and Aadhaar? It would be interesting to know a bit more about "who is doing what and with whom and why".

This overall topic is being addressed by the Secure Payment Confirmation (SPC) work over in the W3C Web Payments WG. Any resulting WebAuthn-specific implications ought to be noted by filing new issues.