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/CAGben6kHdSsa%3DFKtwRPogrg_Z5mg-Q3Yb72jtv3qFLD%2BZ-4p2w%40mail.gmail.com.
