I'd like to chime in to add - although passkeys can and do often sync, they don't always sync today. When a passkey doesn't sync, it is entirely identical to a BBK in terms of data being tracked/exposed - it's a unique global identifier - and it is protected via the same mechanisms as BBKs (actually, fewer mechanisms, since SPC requires the user to agree to a transaction confirmation dialog *and* interact with an authenticator device, whilst pure passkeys just require the latter).
This is not to say that BBKs don't carry tracking risk - they do carry some, especially when used with a passkey that does sync - but more to note that we are (apparently) happy with the level of controls for creation, access to, and management of non-syncing passkeys today, and in my personal opinion that same level should be fine for BBKs? Passkeys that don't sync today: - Chrome on MacOS, when using the Chrome profile authenticator instead of Google Password Manager or iCloud Keychain - Windows Hello (gives users the option whether to sync or not) - Remote authenticators (albeit you can use these across different devices, of course) - And *any* platform authenticator, if you are a user with only once device! (It doesn't matter if it syncs, if you only have one device) On Wed, 25 Jun 2025 at 15:06, Daniel Bratell <bratel...@gmail.com> wrote: > That sounds like a lot of work and unlikely to actually be done by anyone. > Is that ok? > > /Daniel > On 2025-06-25 20:01, Slobodan Pejic wrote: > > But clearing data, can the user reset or delete this key in an intuitive >> way? >> > The browser bound keys are associated with their respective passkeys, so > users would need to delete the respective passkey. On Android, Chrome will > delete browser bound keys on startup when the respective passkey is no > longer available: A user deleting their passkey will result in Chrome > deleting the respective browser bound key. On desktop, if a passkey is > being deleted through Chrome then the respective browser bound key is > deleted at the same time, additionally Chrome will delete browser bound > keys for passkeys that have not been used for 9 months to cover any > unexpected cases where a passkey may have been deleted outside of Chrome. > > Additionally, deleting the Chrome App on Android (or removing the profile > from disk on Desktop) removes the association from a browser bound key to > its passkey. The browser bound key would not be available (and a different > browser bound key would be created as needed when paying). > > On Wed, Jun 25, 2025 at 12:49 PM Daniel Bratell <bratel...@gmail.com> > wrote: > >> Thanks. I think that alleviates some my concerns but not fully. >> >> I guess it's unavoidable that any payment network can track users through >> the actual payments, just like Visa or Mastercard probably do for physical >> cards today, for good and bad. I assume we have to rely on government >> regulation rather than technical protections against that which is >> unsatisfying, but... unavoidable. >> >> But clearing data, can the user reset or delete this key in an intuitive >> way? >> >> /Daniel >> On 2025-06-25 18:33, Slobodan Pejic wrote: >> >> 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/CADY3MacnrT-4Ge2aFfv7LcQGGfCLiwsY_e7nWOQACRxZ9LC-Eg%40mail.gmail.com.
