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/CAEmk%3DMY3dbjrsN5N4cXBdBvt2Hcetv0vQp%2Begizan%3DH7gMV01A%40mail.gmail.com.
