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)
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)