On Thu, Jun 19, 2025 at 9:07 AM Slobodan Pejic <slobo...@chromium.org> wrote:
> 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. > This sounds right to me. It's true the feature isn't supported on linux, so failing on wpt.fyi Chrome Linux bots (and presumably passing on Edge Windows bots) is correct. I believe we run WPTs on Chrome Mac and Windows bots, so as long as those are passing in our infra then I'm happy. So LGTM1 with a plan to get these tests landed in the next month or two. Anything further to use virtual authenticators sounds like a nice-to-have to me, happy to leave up to your judgement. > > 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. >> > Makes sense, thanks for sharing Reilly! > 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/CAFUtAY-De1qSg6nrSMEfuAP%3DGVKoABJYSgpbwSAtA%3DQRfGGaTg%40mail.gmail.com.
