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.
