Hello Daniel,

The browser bound public key is only returned on enrollment and payment
authentication which require the user to provide a pin or fingerprint to
the underlying authenticator (as opposed to the browser bound key being
available on a silent API call). Additionally, different browser bound keys
are created per different passkeys. The Secure Payment Confirmation spec
has two sections regarding the topic of tracking vectors: Credential ID(s)
as a tracking vector
<https://w3c.github.io/secure-payment-confirmation/#sctn-privacy-credential-id-tracking-vector>
, Browser Bound Key as a tracking vector
<https://w3c.github.io/secure-payment-confirmation/#sctn-privacy-browser-bound-key-tracking-vector>
.


On Wed, Jun 25, 2025 at 11:54 AM Daniel Bratell <bratel...@gmail.com> wrote:

> 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
>>>
>>>
>>> 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
>>>
>>> Design docs
>>> 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/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
>>>
>>> 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) 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) 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.
>>>
>>>
>>> DevTrial instructions 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
>>>
>>> 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
>>>
>>> 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
>>>
>>> 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
>>>
>>>
>>> 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/CAMTwYu4Yg2fSk08zCkv5X5pW-Ur9XC%3DUiZm2bVREQdeieW9x5w%40mail.gmail.com.

Reply via email to