Hey all, please see #168 ... I proposed a different way of doing this there that is, IMO, more developer friendly and avoid the "support" question... that the browser recognizes the protocol string does not imply "support" for it.

I suggest we refactor this pull request to align more fully with #168

Is this intended to only reveal information on what the browser version supports passing through and specifically not to reveal any details of what wallets are available, what the user has configured, what credentials they have, whether they have another device that supports credentials, etc.? (I know I raise this question every time it comes up, but we haven't written down the answer, so I keep asking.)

If so, we should add normative requirements that indicate that.

Is this intended to only reveal information on what the browser version supports passing through and specifically not to reveal any details of what wallets are available, what the user has configured, what credentials they have, whether they have another device that supports credentials, etc.? (I know I raise this question every time it comes up, but we haven't written down the answer, so I keep asking.)

If so, we should add normative requirements that indicate that.

Essentially: "can you pass a request with this protocol to the next component"

There is no possible way for it to reveal any details about wallets or credentials. It just returns a boolean given a protocol identifier.

Browsers could modify the response based on some knowledge of wallet availability or configuration. I think we should just specify that the UA shouldn't use that kind of knowledge for a customized value, they should only describe browser-level support without user/device/app/wallet configuration detail.

Browsers could modify the response based on some knowledge of wallet availability or configuration

Not sure I follow. The browser is the only party handling this request and response.

As in, a browser vendor trying to implement this section could try to use their knowledge of system/app/wallet/user-configuration properties to modify the return value, and I think this API should tell the browser vendor implementer not to do that.

Gotcha. I'm not sure how we write something like that given each browser has their own method of determining what the response should be. Do you have some suggested text?

I can try to propose something (tomorrow, likely) that would set some SHOULD NOT/MUST NOT conditions to try to capture what I think is the agreement.

2025-05-28 call: make it static and come up with a better name (something similar to canRequestForProtocolReachWallets())

I believe I've found some guidance on how to determine when to define a method as asynchronous vs synchronous. The W3C's Web Platform Design Principles suggest to me that it's best to go with async by default:

https://www.w3.org/TR/design-principles/#async-by-default

Due to current limitations, some specific areas of the web platform lack asynchronous support. Therefore having support for synchronous methods in addition to asynchronous methods can be beneficial for usability. Consider these cases an exception, and have a clear path for deprecation of the synchronous methods as web platform capabilities evolve.

We should probably take this into account as we continue to discuss the shape of this method.

cc @marcoscaceres on this ⬆️

Since this method isn't intended to invoke user permission or a detailed request to another resource (in fact, I believe we are specifically prohibiting that, because it's just supposed to be a browser support check, not a check of available resources), I think it makes more sense to stay synchronous:
https://www.w3.org/TR/design-principles/#synchronous

Discussed on DC API Series B call, 25 June 2025

Sent a PR to add this to WebKit WebKit/WebKit#47283

Thanks for preparing the tests, @timcappalli!