Intent to Ship: Secure Payment Confirmation: Browser Bound Keys

[Chromestatus]

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]

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]

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.

[Slobodan Pejic]

Rick, thanks for taking a look.

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.

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. 

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.

[Rick Byers]

On Thu, Jun 19, 2025 at 9:07 AM Slobodan Pejic <slob...@chromium.org> wrote:

Rick, thanks for taking a look.

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.

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. 

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 <rei...@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! 

[Vladimir Levin]

On Tuesday, June 10, 2025 at 2:47:10 PM UTC-4 Chromestatus wrote:

Contact emails slob...@chromium.org, smcg...@chromium.org, rou...@chromium.org

Explainer https://github.com/w3c/secure-payment-confirmation/issues/271

In the explainer you mention the following:

> It is worth noting that this proposal is in some ways re-inventing the wheel of what already exists and/or will exist in WebAuthn. In particular, it means that we have to be careful to avoid all the traps/problems with signatures that WebAuthn already has solved (e.g., challenges to avoid replay attacks, choice of signing algorithms, quantum-proofing, etc). Where possible, we should look to write the spec relying on WebAuthn concepts, even if the actual key creation and storage does not use WebAuthn authenticators.

I don't follow WebAuthn progress closely, so the questions I have may be naive, but bear with with me.

1. How *do* you avoid replay attacks in this case? If a device is uniquely identified by a key that is only challenged by 2FA (like SMS) on the first try, what prevents a person-in-the-middle from learning this key and using it later?

2. There is some discussion to switching to a device bound key if WebAuthn supports that. Is the possibility of shared devices considered an acceptable risk? Specifically, SMS 2FA is "your phone number" which can be reasonably thought as your and yours alone, but a device like a desktop is commonly shared device (e.g. library computer). Or is the device key something that changes based on login or some other criteria?

Thanks!

Vlad

[Slobodan Pejic]

Hi Vladimir,

Thanks for the questions:

 

1. How *do* you avoid replay attacks in this case? If a device is uniquely identified by a key that is only challenged by 2FA (like SMS) on the first try, what prevents a person-in-the-middle from learning this key and using it later?

 

The clientDataJSON contains a challenge field: WebAuthn passes clientDataJSON (or rather a hash of the clientDataJSON) to the authenticator for signing. The browser bound key also signs the clientDataJSON containing the challenge. On another transaction a person-in-the-middle does not have access to the browser bound private key needed to sign over the challenge. The relying party can protect against replay attacks by providing a random challenge, checking the challenge matches, and verifying the signature.

2. There is some discussion to switching to a device bound key if WebAuthn supports that. Is the possibility of shared devices considered an acceptable risk? Specifically, SMS 2FA is "your phone number" which can be reasonably thought as your and yours alone, but a device like a desktop is commonly shared device (e.g. library computer). Or is the device key something that changes based on login or some other criteria?

Browser bound keys are associated to the tuple (a passkey, a browser instance, a device) in the Chrome profile, so a separate os login would produce a different browser bound key for the same passkey, and different browser bound keys would be provided for different passkeys in the same profile. If someone is at a library computer, they first need access to the passkey before the matching browser bound key. Secure Payment Confirmation requires userVerification (see SPC spec) when invoking WebAuthn (e.g., on Android enter the lock screen pin/fingerprint, on MacOS provide your fingerprint), so the user must be present to use an existing passkey before the browser bound key would be used to sign the transaction. A different passkey would yield a different browser bound key; however, even if an attacker managed to use a browser bound key on the same library computer with an attacker controlled passkey, then relying parties can detect the mismatch (on top of not recognizing the attacker's passkey).

To be clear, if WebAuthn introduces a form of device-binding, Chrome will continue to provide browser bound keys (i.e., there is no code or spec to switch browser bound key provider to WebAuthn). When or if WebAuthn supports device binding we would re-evaluate the need/requirements for browser bound keys in the web payments working group.

[Vladimir Levin]

That makes sense, thank you for the answers.

LGTM2

[Daniel Bratell]

I am curious about this as a vector for privacy intrusion. There is probably something I have missed so feel free to explain what I am missing.

These browser bound keys are per design locked to a specific device. Doesn't that mean that it allows a bad actor to keep track of a user's devices, or even keep track of users, like some kind of very special cookie? The explainer talks about this being used in an embedded/cross-origin environment which means that avoiding tracking is even more important.

How about clearing the data, will this be deleted if a deletes "cookies" or "browsing data"?

The explainer says that a full privacy analysis should be done, but that is from last spring so maybe it has been done?

/Daniel

--

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/065caa09-a757-44d2-ae7c-507d50d6c12bn%40chromium.org.

[Slobodan Pejic]

Hello Daniel,

The browser bound public key is only returned on enrollment and payment authentication which require the user to provide a pin or fingerprint to the underlying authenticator (as opposed to the browser bound key being available on a silent API call). Additionally, different browser bound keys are created per different passkeys. The Secure Payment Confirmation spec has two sections regarding the topic of tracking vectors: Credential ID(s) as a tracking vector, Browser Bound Key as a tracking vector.

[Daniel Bratell]

Thanks. I think that alleviates some my concerns but not fully.

I guess it's unavoidable that any payment network can track users through the actual payments, just like Visa or Mastercard probably do for physical cards today, for good and bad. I assume we have to rely on government regulation rather than technical protections against that which is unsatisfying, but... unavoidable.

But clearing data, can the user reset or delete this key in an intuitive way?

/Daniel

[Slobodan Pejic]

But clearing data, can the user reset or delete this key in an intuitive way?

The browser bound keys are associated with their respective passkeys, so users would need to delete the respective passkey. On Android, Chrome will delete browser bound keys on startup when the respective passkey is no longer available: A user deleting their passkey will result in Chrome deleting the respective browser bound key. On desktop, if a passkey is being deleted through Chrome then the respective browser bound key is deleted at the same time, additionally Chrome will delete browser bound keys for passkeys that have not been used for 9 months to cover any unexpected cases where a passkey may have been deleted outside of Chrome.

Additionally, deleting the Chrome App on Android (or removing the profile from disk on Desktop) removes the association from a browser bound key to its passkey. The browser bound key would not be available (and a different browser bound key would be created as needed when paying).

[Daniel Bratell]

That sounds like a lot of work and unlikely to actually be done by anyone. Is that ok?

/Daniel

[Stephen Mcgruer]

I'd like to chime in to add - although passkeys can and do often sync, they don't always sync today. When a passkey doesn't sync, it is entirely identical to a BBK in terms of data being tracked/exposed - it's a unique global identifier - and it is protected via the same mechanisms as BBKs (actually, fewer mechanisms, since SPC requires the user to agree to a transaction confirmation dialog and interact with an authenticator device, whilst pure passkeys just require the latter).

This is not to say that BBKs don't carry tracking risk - they do carry some, especially when used with a passkey that does sync - but more to note that we are (apparently) happy with the level of controls for creation, access to, and management of non-syncing passkeys today, and in my personal opinion that same level should be fine for BBKs?

Passkeys that don't sync today:

• Chrome on MacOS, when using the Chrome profile authenticator instead of Google Password Manager or iCloud Keychain
• Windows Hello (gives users the option whether to sync or not)
• Remote authenticators (albeit you can use these across different devices, of course)
• And any platform authenticator, if you are a user with only once device! (It doesn't matter if it syncs, if you only have one device)

[Daniel Bratell]

Ok. I'm not sure who "we" are in all that, but I note what you say about this not opening up any new problems. No more questions from me.

/Daniel

[Stephen Mcgruer]

Thanks Daniel!

>  I'm not sure who "we" are in all that,

Very fair, apologies about the ambiguous communication 😅. In general I meant 'we the Chromium community, who were/are happy to ship WebAuthn with a similar tracking risk'. I am sure that the community consists of people who are both more and less ok with that risk, and also acknowledge that just because we've done it before doesn't automatically mean it's fine here.

And thank you for bringing up these points - they are very important to consider and I appreciate it!

[Yoav Weiss (@Shopify)]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.