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/CAMTwYu4y%2BgYDMpRgwGyrAuvb_ue%3DNOczw8ek0nju6u9geP%2Bf9g%40mail.gmail.com.
