Intent to Ship: Secure Payment Confirmation: Browser Bound Keys

135 views
Skip to first unread message

Chromestatus

unread,
Jun 10, 2025, 6:47:10 PM (8 days ago) Jun 10
to blin...@chromium.org, rou...@chromium.org, slob...@chromium.org, smcg...@chromium.org

Contact emails

slob...@chromium.org, smcg...@chromium.org, rou...@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

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?

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.

Rick Byers

unread,
Jun 17, 2025, 8:20:28 PM (2 days ago) Jun 17
to Chromestatus, blin...@chromium.org, rou...@chromium.org, slob...@chromium.org, smcg...@chromium.org
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.

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 for this purpose, but there are other lighter weight options too. In this case I'd imagine we might want to follow the pattern 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. 
--
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+...@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.

Reilly Grant

unread,
Jun 18, 2025, 5:27:58 PM (11 hours ago) Jun 18
to Rick Byers, Chromestatus, blin...@chromium.org, rou...@chromium.org, slob...@chromium.org, smcg...@chromium.org
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 | rei...@chromium.org | Google Chrome


To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8Bh68hFm%2B5WJHFh029i%3DX19885FSUJH-DrU3JX%3DqLT8w%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages