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/CAGben6nyyeysOYY3RUTbi%2BnbdGbTP90nJb8qS%3DGw%3Dk8jjcv4Jw%40mail.gmail.com.
