LGTM2 On Mon, Mar 23, 2026 at 2:47 PM Alex Russell <[email protected]> wrote:
> Thanks for doing that, Darwin. LGTM1 > > Some feedback on the Explainer to consider for future efforts: > > - it's great to see the considered alternatives; thank you! > - Explainers are "speaking design docs"; that is, part of their job is to > explain to developers, not just browser engineers, what the value of a > feature and the tradeoffs in the design space. As a result, we heavily > prefer to see designs described in JS (particularly example code) rather > than IDL. If you have to keep the IDL (e.g., because there isn't a spec > draft yet in which to deposit it), an appendix is a good place for it. > - In the privacy considerations section, I don't see a discussion of user > activation. Perhaps worth adding? > > Best, > > Alex > > On Thursday, March 19, 2026 at 7:14:36 AM UTC-7 Darwin Yang wrote: > >> FYI I decided to write the explainer and linked it in the feature. Here >> is a link to it as well: >> https://github.com/w3c/secure-payment-confirmation/blob/main/explainer-capabilities.md >> . >> >> On Mon, Mar 16, 2026 at 3:10 PM Darwin Yang <[email protected]> >> wrote: >> >>> The API Proposal linked as the explainer >>> <https://github.com/w3c/secure-payment-confirmation/issues/290#issuecomment-3806454419> >>> includes >>> background on the problem, the value of solving it, and alternative APIs >>> that were considered. Was there something specific that you were looking >>> for in a separate explainer that wouldn't just paraphrase the API proposal? >>> >>> On Mon, Mar 16, 2026 at 2:51 PM Alex Russell <[email protected]> >>> wrote: >>> >>>> The API (as I understand it from the comment that's linked in lieu of >>>> an Explainer) is gated by a Promise, so that gives us a chance to retrofit >>>> with other checks in the future. >>>> >>>> I'd be happier with an FYI to the TAG if there were a real Explainer >>>> that describes the value of the problem being solved and the alternatives >>>> that were considered. Is it possible to get one of those? >>>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Wednesday, March 11, 2026 at 9:02:38 AM UTC-7 Darwin Yang wrote: >>>> >>>>> Given that this is a new capability we're shipping first, why isn't a >>>>>> TAG review applicable? >>>>> >>>>> Looking at the Webauthn GetClientCapabilities API >>>>> <https://chromestatus.com/feature/5128205875544064?gate=5206408640069632> >>>>> which >>>>> is similar to this, they were able to FYI their TAG review >>>>> <https://github.com/w3ctag/design-reviews/issues/1016>. If I were to >>>>> get one, I was wondering if I could do the same. >>>>> >>>>> On Wed, Mar 11, 2026 at 10:17 AM Darwin Yang <[email protected]> >>>>> wrote: >>>>> >>>>>> Just to confirm, access to this API is gated behind a user-initiated >>>>>>> flow? That is, we don't create any additional fingerprinting risk until >>>>>>> such time as the user is attempting a transaction? >>>>>> >>>>>> No, it is not gated behind a user-initiated flow but as mentioned in >>>>>> the privacy review, the TPM detection as a fingerprinting vector is >>>>>> already >>>>>> possible without this ne API. >>>>>> >>>>>> Given that this is a new capability we're shipping first, why isn't a >>>>>>> TAG review applicable? >>>>>> >>>>>> Although this is a new API, the ability to get this information (BBK >>>>>> availability) is not new and can be obtained through the SPC payment >>>>>> request show method. This would be similar to the SPC availability >>>>>> API <https://chromestatus.com/feature/5165040614768640>. >>>>>> >>>>>> On Wed, Mar 11, 2026 at 1:59 AM Yoav Weiss (@Shopify) < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 10, 2026 at 3:23 PM Chromestatus < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> *Contact emails* >>>>>>>> [email protected] >>>>>>>> >>>>>>>> *Explainer* >>>>>>>> >>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/290#issuecomment-3806454419 >>>>>>>> >>>>>>>> *Specification* >>>>>>>> >>>>>>>> https://w3c.github.io/secure-payment-confirmation/#sctn-secure-payment-confirmation-capabilities >>>>>>>> >>>>>>>> *Design docs* >>>>>>>> >>>>>>>> https://www.w3.org/wbs/83744/spc-mvp-2025/results >>>>>>>> >>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/290#issuecomment-3806454419 >>>>>>>> https://www.w3.org/2026/01/29-wpwg-minutes.html#3919 >>>>>>>> https://www.w3.org/2026/02/26-wpwg-minutes.html#bbkdetect >>>>>>>> >>>>>>>> *Summary* >>>>>>>> Adds a new static method to the Payment Request that allows web >>>>>>>> developers to get the capabilities of the browser's implementation of >>>>>>>> Secure Payment Confirmation. This helps web developers to easily know >>>>>>>> what >>>>>>>> capabilities are available for Secure Payment Confirmation so they can >>>>>>>> decide whether or not they want to use Secure Payment Confirmation with >>>>>>>> those capabilities. >>>>>>>> >>>>>>>> *Blink component* >>>>>>>> Blink>Payments >>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPayments%22> >>>>>>>> >>>>>>>> *Web Feature ID* >>>>>>>> secure-payment-confirmation >>>>>>>> <https://webstatus.dev/features/secure-payment-confirmation> >>>>>>>> >>>>>>>> *Motivation* >>>>>>>> This feature allows web developers to check for which capabilities >>>>>>>> are supported in the browser's implementation of Secure Payment >>>>>>>> Confirmation. Web developers want an easy way to check whether hardware >>>>>>>> browser bound keys are available with the Secure Payment Confirmation >>>>>>>> API >>>>>>>> and only use the API if if they are available. Without this method, web >>>>>>>> developers would need to initiate the Secure Payment Confirmation flow >>>>>>>> and >>>>>>>> force users to go through the dialog and authenticate just to ignore >>>>>>>> the >>>>>>>> data returned if it did not contain the browser bound key (in cases >>>>>>>> where >>>>>>>> browser bound keys are not available). >>>>>>>> >>>>>>>> *Initial public proposal* >>>>>>>> >>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/290#issuecomment-3806454419 >>>>>>>> >>>>>>>> *Search tags* >>>>>>>> spc <http:///features#tags:spc>, bbk <http:///features#tags:bbk> >>>>>>>> >>>>>>>> *TAG review* >>>>>>>> *No information provided* >>>>>>> >>>>>>> >>>>>>> *Given that this is a new capability we're shipping first, why isn't >>>>>>> a TAG review applicable?* >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *TAG review status* >>>>>>>> Not applicable >>>>>>>> >>>>>>>> *Risks* >>>>>>>> >>>>>>>> >>>>>>>> *Interoperability and Compatibility* >>>>>>>> The GetSecurePaymentConfirmationCapabilities method is new and the >>>>>>>> only risk is if other browser do not implement it. >>>>>>>> >>>>>>>> *Gecko*: No signal ( >>>>>>>> https://github.com/mozilla/standards-positions/issues/570) Firefox >>>>>>>> haven't implemented SPC yet so this new method is not relevant. >>>>>>>> >>>>>>>> *WebKit*: No signal ( >>>>>>>> https://github.com/WebKit/standards-positions/issues/30) Safari >>>>>>>> haven't implemented SPC yet so this new method is not relevant. >>>>>>>> >>>>>>>> *Web developers*: Positive ( >>>>>>>> https://www.w3.org/2026/01/29-wpwg-minutes.html#3919) Discussed >>>>>>>> the GetSecurePaymentConfirmationCapabilities method during the WPWG >>>>>>>> when >>>>>>>> proposing a solution to Browser Bound Key Feature Detection and did not >>>>>>>> receive any comments opposed to this feature. >>>>>>>> >>>>>>>> *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? >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> >>>>>>>> *Debuggability* >>>>>>>> Web developers should be able to inspect the output of the new >>>>>>>> method 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 >>>>>>>> The GetSecurePaymentConfirmationCapabilities method will only be >>>>>>>> added to platforms that support Secure Payment Confirmation which are >>>>>>>> currently only Android, macOS, and Windows. >>>>>>>> >>>>>>>> *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 are in development. We can only test if the >>>>>>>> method is available and can be called as user agents have the ability >>>>>>>> to >>>>>>>> omit capabilities (for privacy reasons). >>>>>>>> >>>>>>>> *Flag name on about://flags* >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Finch feature name* >>>>>>>> SecurePaymentConfirmationCapabilities >>>>>>>> >>>>>>>> *Rollout plan* >>>>>>>> Will ship enabled for all users >>>>>>>> >>>>>>>> *Requires code in //chrome?* >>>>>>>> False >>>>>>>> >>>>>>>> *Tracking bug* >>>>>>>> https://crbug.com/484043990 >>>>>>>> >>>>>>>> *Launch bug* >>>>>>>> https://launch.corp.google.com/launch/4448199 >>>>>>>> >>>>>>>> *Measurement* >>>>>>>> A new GetSecurePaymentConfirmationCapabilities UseCounter will be >>>>>>>> created and used. >>>>>>>> >>>>>>>> *Availability expectation* >>>>>>>> The GetSecurePaymentConfirmationCapabilities method will only be >>>>>>>> available in Chromium browsers for the foreseeable future. >>>>>>>> >>>>>>>> *Estimated milestones* >>>>>>>> Shipping on desktop 147 >>>>>>>> Shipping on Android 147 >>>>>>>> >>>>>>>> *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). >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>>> >>>>>>>> https://chromestatus.com/feature/4727235745546240?gate=4769560794365952 >>>>>>>> >>>>>>>> *Links to previous Intent discussions* >>>>>>>> Intent to Prototype: >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69a0a6a7.050a0220.3c921b.02ae.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 [email protected]. >>>>>>>> To view this discussion visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69b02941.710a0220.50957.0104.GAE%40google.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69b02941.710a0220.50957.0104.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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/79711c2d-5f0d-44c3-a506-21cfbe11bba3n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/79711c2d-5f0d-44c3-a506-21cfbe11bba3n%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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_LHrp_F8Lik19Etq7_6%2B6gvzdxe9Lh2877qo39xoGSVA%40mail.gmail.com.
