Rick, thanks for taking a look. > >> 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. >> > Hmm, I disagree. Generally we're now in the habit of creating WPTs for > APIs which are backed by hardware by mocking them out in testing > situations, I don't think there's any reason that SPC should be different, > is there? For example WebUSB defines a whole testing API > <https://wicg.github.io/webusb/test/> for this purpose, but there are > other lighter weight options > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md#tests-that-require-testing-apis> > too. > In this case I'd imagine we might want to follow the pattern > <https://w3c.github.io/webauthn/#sctn-automation> used by WebAuthn which > is to define some webdriver commands. >
I can follow up quickly (likely before browser bound keys ship to stable) with option 3 which would allow other implementations to test against, but would still show Chrome as not supporting browser bound keys on wpt.fyi since those tests run on Linux. Broadly, there are 3 options for WPT tests: 1. Model the API of hardware crypto library in the specification, then provide a testing API allowing the test to implement the API. Currently the secure payment confirmation specification does not define a model of hardware (unlike WebAuthn), so a large spec change would be needed before the matching testing api could be implemented. 2. Allow a software implementation for browser bound keys when enabled via a WebDriver command. The secure payment confirmation would need to be amended with a mode (initiated via a new WebDriver command) where the browser always provides the software implementation. This would allow WPT tests to pass on platforms where they otherwise would not, particularly wpt.fyi would report that Chrome does support browser bound keys (though this would be inaccurate for Linux on which Chrome's tests run on). 3. Let WPT tests report (correctly) that Chrome does not support browser bound keys on Linux. wpt.fyi would show Chrome not supporting browser bound keys; however, other implementations could pass the WPT tests (if those implementation's WPT tests run on a platform with hardware support, or implement browser bound keys in software). No test specific APIs are needed, so no need to extends WebDriver or change the secure payment confirmation specification. On Wed, Jun 18, 2025 at 1:27 PM Reilly Grant <reil...@chromium.org> wrote: > Note the approach I took in WebUSB hasn't proven popular. I wouldn't > replicate it. WebAuthn defines WebDriver commands and that's the approach > we've been trying to take other APIs in as well such as Web Bluetooth and > Web Smart Card. > Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome > <https://www.google.com/chrome> > > > On Tue, Jun 17, 2025 at 1:20 PM Rick Byers <rby...@chromium.org> wrote: > >> This is exciting Slobo, thank you! I think this is really important to >> ship in order to bring back the promise of device-binding to SPC (which was >> broken when WebAuthn keys became synced a few years ago). It's unfortunate >> that no other engines are currently interested in SPC but I remain >> confident that there's a path to getting more interest if we can get to the >> point that payments are actually easier (eg. less annoying SMS two-factor >> authentications) for a non-trivial number of users due to this feature. >> >> I have just one concern around WPTs, inline. Otherwise this looks ready >> to ship to me. >> >> On Tue, Jun 10, 2025 at 2:47 PM Chromestatus < >> ad...@cr-status.appspotmail.com> wrote: >> >>> Contact emails slobo...@chromium.org, smcgr...@chromium.org, >>> rous...@chromium.org >>> >>> Explainer https://github.com/w3c/secure-payment-confirmation/issues/271 >>> >>> 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. >>> >> Hmm, I disagree. Generally we're now in the habit of creating WPTs for >> APIs which are backed by hardware by mocking them out in testing >> situations, I don't think there's any reason that SPC should be different, >> is there? For example WebUSB defines a whole testing API >> <https://wicg.github.io/webusb/test/> for this purpose, but there are >> other lighter weight options >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md#tests-that-require-testing-apis> >> too. In this case I'd imagine we might want to follow the pattern >> <https://w3c.github.io/webauthn/#sctn-automation> used by WebAuthn which >> is to define some webdriver commands. >> >> Could you take a look into this space and see how difficult it might be >> to do something like this? In this case we're not expecting any other >> implementations anytime soon so I personally would be OK with not blocking >> shipping on landing the tests, but I would want us to plan to add tests not >> too long after shipping. >> >>> 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/68487d9f.170a0220.bdf4.01e1.GAE%40google.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68487d9f.170a0220.bdf4.01e1.GAE%40google.com?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/CAFUtAY8Bh68hFm%2B5WJHFh029i%3DX19885FSUJH-DrU3JX%3DqLT8w%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8Bh68hFm%2B5WJHFh029i%3DX19885FSUJH-DrU3JX%3DqLT8w%40mail.gmail.com?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/CAMTwYu54f4pudqGnRDNfWKu8zMZx-3ZLp1rJ0wYwBLdqQRzS-g%40mail.gmail.com.
