LGTM3 On Thursday, June 26, 2025 at 4:44:15 PM UTC+2 Stephen McGruer wrote:
> 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/59a48296-299a-482e-b58f-acbc9fc9e696n%40chromium.org.
