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.