I am curious about this as a vector for privacy intrusion. There is
probably something I have missed so feel free to explain what I am missing.
These browser bound keys are per design locked to a specific device.
Doesn't that mean that it allows a bad actor to keep track of a user's
devices, or even keep track of users, like some kind of very special
cookie? The explainer talks about this being used in an
embedded/cross-origin environment which means that avoiding tracking is
even more important.
How about clearing the data, will this be deleted if a deletes "cookies"
or "browsing data"?
The explainer says that a full privacy analysis should be done, but that
is from last spring so maybe it has been done?
/Daniel
On 2025-06-25 17:03, Vladimir Levin wrote:
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>.
--
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/c24df9a6-220c-40b9-b7c5-ba733c045b78%40gmail.com.
