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

On 2025-06-25 17:03, Vladimir Levin wrote:
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>.

--
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/c24df9a6-220c-40b9-b7c5-ba733c045b78%40gmail.com.

Reply via email to