That makes sense, thank you for the answers.
LGTM2
On Wednesday, June 25, 2025 at 9:42:19 AM UTC-4
Slobodan Pejic wrote:
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
<https://www.w3.org/TR/webauthn-2/#dom-authenticatorresponse-clientdatajson>
contains
a challenge
<https://www.w3.org/TR/webauthn-2/#dom-collectedclientdata-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
<https://w3c.github.io/webauthn/#dom-publickeycredentialrequestoptions-userverification>
(see
SPC spec
<https://w3c.github.io/secure-payment-confirmation/#sctn-steps-to-respond-to-a-payment-request>)
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.
On Tue, Jun 24, 2025 at 9:55 PM Vladimir Levin
<vmp...@chromium.org> wrote:
On Tuesday, June 10, 2025 at 2:47:10 PM UTC-4
Chromestatus wrote:
Contact emails slobo...@chromium.org,
smcgr...@chromium.org, rous...@chromium.org
Explainer
https://github.com/w3c/secure-payment-confirmation/issues/271
<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
Specification
https://w3c.github.io/secure-payment-confirmation/#sctn-browser-bound-key-store
<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/issues/271>
https://github.com/w3c/secure-payment-confirmation/pull/286
<https://github.com/w3c/secure-payment-confirmation/pull/286>
https://github.com/w3c/secure-payment-confirmation/pull/296
<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
<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
<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
<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
<https://github.com/w3c/secure-payment-confirmation/issues/288>.
DevTrial instructions
https://docs.google.com/document/d/1Wgx8MQG4GsdPErGPya7iMCbhw5NiSrLrNIoDPq2_P2s/edit?usp=sharing
<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
<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
<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
<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
<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/065caa09-a757-44d2-ae7c-507d50d6c12bn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/065caa09-a757-44d2-ae7c-507d50d6c12bn%40chromium.org?utm_medium=email&utm_source=footer>.
