LGTM3 On Wednesday, March 25, 2026 at 4:08:44 PM UTC+1 Rick Byers wrote:
> 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/97687d69-4bc6-47cf-a04c-504132cbe9b5n%40chromium.org.
