That makes sense, thank you for the answers.
LGTM2
On Wednesday, June 25, 2025 at 9:42:19 AM UTC-4 Slobodan
Pejic wrote:
Hi Vladimir,
Thanks for the questions:
1. How *do* you avoid replay attacks in this case?
If a device is uniquely identified by a key that is
only challenged by 2FA (like SMS) on the first try,
what prevents a person-in-the-middle from learning
this key and using it later?
The clientDataJSON
<https://www.w3.org/TR/webauthn-2/#dom-authenticatorresponse-clientdatajson>
contains
a challenge
<https://www.w3.org/TR/webauthn-2/#dom-collectedclientdata-challenge> field:
WebAuthn
passes clientDataJSON (or rather a hash of the
clientDataJSON) to the authenticator for signing. The
browser bound key also signs the clientDataJSON
containing the challenge. On another transaction a
person-in-the-middle does not have access to the browser
bound private key needed to sign over the challenge. The
relying party can protect against replay attacks by
providing a random challenge, checking the challenge
matches, and verifying the signature.
2. There is some discussion to switching to a device
bound key if WebAuthn supports that. Is the
possibility of shared devices considered an
acceptable risk? Specifically, SMS 2FA is "your
phone number" which can be reasonably thought as
your and yours alone, but a device like a desktop is
commonly shared device (e.g. library computer). Or
is the device key something that changes based on
login or some other criteria?
Browser bound keys are associated to the tuple (a
passkey, a browser instance, a device) in the Chrome
profile, so a separate os login would produce a
different browser bound key for the same passkey, and
different browser bound keys would be provided for
different passkeys in the same profile. If someone is at
a library computer, they first need access to the
passkey before the matching browser bound key. Secure
Payment Confirmation requires userVerification
<https://w3c.github.io/webauthn/#dom-publickeycredentialrequestoptions-userverification>
(see
SPC spec
<https://w3c.github.io/secure-payment-confirmation/#sctn-steps-to-respond-to-a-payment-request>)
when
invoking WebAuthn (e.g., on Android enter the lock
screen pin/fingerprint, on MacOS provide your
fingerprint), so the user must be present to use an
existing passkey before the browser bound key would be
used to sign the transaction. A different passkey would
yield a different browser bound key; however, even if an
attacker managed to use a browser bound key on the same
library computer with an attacker controlled passkey,
then relying parties can detect the mismatch (on top of
not recognizing the attacker's passkey).
To be clear, if WebAuthn introduces a form of
device-binding, Chrome will continue to provide browser
bound keys (i.e., there is no code or spec to switch
browser bound key provider to WebAuthn). When or if
WebAuthn supports device binding we would re-evaluate
the need/requirements for browser bound keys in the web
payments working group.
On Tue, Jun 24, 2025 at 9:55 PM Vladimir Levin
<vmp...@chromium.org> wrote:
On Tuesday, June 10, 2025 at 2:47:10 PM UTC-4
Chromestatus wrote:
Contact emails slobo...@chromium.org,
smcgr...@chromium.org, rous...@chromium.org
Explainer
https://github.com/w3c/secure-payment-confirmation/issues/271
<https://github.com/w3c/secure-payment-confirmation/issues/271>
In the explainer you mention the following:
> It is worth noting that this proposal is in some
ways re-inventing the wheel of what already exists
and/or will exist in WebAuthn. In particular, it
means that we have to be careful to avoid all the
traps/problems with signatures that WebAuthn already
has solved (e.g., challenges to avoid replay
attacks, choice of signing algorithms,
quantum-proofing, etc). Where possible, we should
look to write the spec relying on WebAuthn concepts,
even if the actual key creation and storage does not
use WebAuthn authenticators.
I don't follow WebAuthn progress closely, so the
questions I have may be naive, but bear with with me.
1. How *do* you avoid replay attacks in this case?
If a device is uniquely identified by a key that is
only challenged by 2FA (like SMS) on the first try,
what prevents a person-in-the-middle from learning
this key and using it later?
2. There is some discussion to switching to a device
bound key if WebAuthn supports that. Is the
possibility of shared devices considered an
acceptable risk? Specifically, SMS 2FA is "your
phone number" which can be reasonably thought as
your and yours alone, but a device like a desktop is
commonly shared device (e.g. library computer). Or
is the device key something that changes based on
login or some other criteria?
Thanks!
Vlad
Specification
https://w3c.github.io/secure-payment-confirmation/#sctn-browser-bound-key-store
<https://w3c.github.io/secure-payment-confirmation/#sctn-browser-bound-key-store>
Design docs
https://github.com/w3c/secure-payment-confirmation/issues/271
<https://github.com/w3c/secure-payment-confirmation/issues/271>
https://github.com/w3c/secure-payment-confirmation/pull/286
<https://github.com/w3c/secure-payment-confirmation/pull/286>
https://github.com/w3c/secure-payment-confirmation/pull/296
<https://github.com/w3c/secure-payment-confirmation/pull/296>
Summary
Adds an additional cryptographic signature over
Secure Payment Confirmation assertions and
credential creation. The corresponding private
key is not synced across devices. This helps web
developers meet requirements for device binding
for payment transactions.
Blink component Blink>Payments
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPayments%22>
TAG review
https://github.com/w3ctag/design-reviews/issues/1097
<https://github.com/w3ctag/design-reviews/issues/1097>
TAG review status Pending
Risks
Interoperability and Compatibility
Browser bound keys are an additive feature for
Secure Payment Confirmation, the risk is that
other browser do not implement it.
/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/570
<https://github.com/mozilla/standards-positions/issues/570>)
Firefox have never finalized their view on SPC,
so we updated the original SPC issue with a note
on this additional capability.
/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/30
<https://github.com/WebKit/standards-positions/issues/30>)
Safari have never finalized their view on SPC,
so we updated the original SPC issue with a note
on this additional capability.
/Web developers/: No signals
/Other signals/:
WebView application risks
Does this intent deprecate or change behavior of
existing APIs, such that it has potentially high
risk for Android WebView-based applications?
Debuggability
Web developers should be able to inspect the new
signature output which is defined in WebIDL,
thus no changes are needed in devtools.
Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, ChromeOS,
Android, and Android WebView)? No
Browser bound keys add to Secure Payment
Confirmation which is supported only on Android,
Windows, and Mac.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No
Web platform tests depend on the availability of
a software implementation. Whether software
implementation of BBK would be permitted is an
open issue:
https://github.com/w3c/secure-payment-confirmation/issues/288
<https://github.com/w3c/secure-payment-confirmation/issues/288>.
DevTrial instructions
https://docs.google.com/document/d/1Wgx8MQG4GsdPErGPya7iMCbhw5NiSrLrNIoDPq2_P2s/edit?usp=sharing
<https://docs.google.com/document/d/1Wgx8MQG4GsdPErGPya7iMCbhw5NiSrLrNIoDPq2_P2s/edit?usp=sharing>
Flag name on about://flags
enable-secure-payment-confirmation-browser-bound-key
Finch feature name
SecurePaymentConfirmationBrowserBoundKeys
Rollout plan Will ship enabled for all users
Requires code in //chrome? False
Tracking bug
https://issues.chromium.org/issues/377278827
<https://issues.chromium.org/issues/377278827>
Measurement Browser bound keys are an additive
to Secure Payment Confirmation: The Secure
Payment Confirmation UseCounter will be used.
Availability expectation Secure Payment
Confirmation (and Browser Bound Keys) are only
in Chromium browsers for the foreseeable future.
Non-OSS dependencies
Does the feature depend on any code or APIs
outside the Chromium open source repository and
its open-source dependencies to function?
No
Sample links
https://rsolomakhin.github.io/pr/spc-sync
<https://rsolomakhin.github.io/pr/spc-sync>
Estimated milestones Shipping on Android 139
DevTrial on Android 135
Anticipated spec changes
Open questions about a feature may be a source
of future web compat or interop issues. Please
list open issues (e.g. links to known github
issues in the project for the feature
specification) whose resolution may introduce
web compat/interop risk (e.g., changing to
naming or structure of the API in a
non-backward-compatible way).
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5106102997614592?gate=5080941065928704
<https://chromestatus.com/feature/5106102997614592?gate=5080941065928704>
Links to previous Intent discussions Intent to
Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68093084.170a0220.15e62e.01e5.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68093084.170a0220.15e62e.01e5.GAE%40google.com>
This intent message was generated by Chrome
Platform Status <https://chromestatus.com>.
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/065caa09-a757-44d2-ae7c-507d50d6c12bn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/065caa09-a757-44d2-ae7c-507d50d6c12bn%40chromium.org?utm_medium=email&utm_source=footer>.
