Thanks Daniel! > I'm not sure who "we" are in all that,
Very fair, apologies about the ambiguous communication 😅. In general I meant 'we the Chromium community, who were/are happy to ship WebAuthn with a similar tracking risk'. I am sure that the community consists of people who are both more and less ok with that risk, and also acknowledge that just because we've done it before doesn't *automatically* mean it's fine here. And thank you for bringing up these points - they are very important to consider and I appreciate it! On Thu, 26 Jun 2025 at 04:17, Daniel Bratell <bratel...@gmail.com> wrote: > Ok. I'm not sure who "we" are in all that, but I note what you say about > this not opening up any new problems. No more questions from me. > > /Daniel > On 2025-06-25 22:00, Stephen Mcgruer wrote: > > 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/CADY3MafzrA2r6KUgFC3vsDw7u2s%2BWoLVYXPdsFA-ZxBrpwvg0w%40mail.gmail.com.
