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.
