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