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/3a0e6d3e-2300-4f08-b417-ae6d39a74651n%40chromium.org.
