Add isProtocolSupportedByClient static method

[timcappalli]

Based on discussion at the 2025-04-11 hybrid meeting and in #200, this issue proposes the creation of a new static method called isProtocolSupportedByClient, which takes a protocol identifier string as input, and returns a promise that resolves with a boolean.

This only represents whether the client (e.g. browser) understand the request enough to pass it southbound to the platform. It does NOT represent whether a credential provider/wallet is available and can support the protocol.

partial interface DigitalCredential {
  static Promise<boolean> isProtocolSupportedByClient(DOMString protocol);
};

As an aside, as I said in the F2F, I think we will regret the ergonomics of this (vs a more general getClientCapabilities() method) long term, just as we did with WebAuthn 6+ years later, but I'd like to get this moving forward as this is important for developers.

[MasterKale]

Is it only one-at-a-time for "user privacy" reasons? I see in #168 (comment) that "boolean testing is often preferred to providing a set for privacy reasons," but hypothetical use of the proposed method, like this...

const supportsOid4vp = await isProtocolSupportedByClient('openid4vp');
const supportsFooProtocol = await isProtocolSupportedByClient('fooproto');

...seems equivalent to a method "getClientSupportedProtocols()"/getClientCapabilities()/etc... that returns ['openid4vp', 'fooproto'].

Will isProtocolSupportedByClient(...) introduce some kind of mechanism to prevent enumeration that will make this worthwhile to define now as a stop-gap till we eventually decide it's time to add these into getClientCapabilities()?

I understand the need to enable developers to understand when a specific profile is supported or not, but whatever method we define for this will stick around for a long time. We have a chance to do something better right out the gate because, to your point, we've learned this lesson the hard way during the evolution of WebAuthn into passkeys...

[MasterKale]

Thinking about this method's API, what about something like this instead?

const supported = await DigitalCredential.getClientSupportedProtocols();

if (supported.includes('openid4vp')) {
  // Call DC API w/OID4VP
} else if (supported.includes('fooproto')) {
  // Call DC API w/FooProto
} else {
  throw new Error("Verifier website only implemented the above protocols");
}

It's a simple list to query for, and a developer adding support for a new protocol can come back in and add an if else for that new protocol, without having to touch the call to DigitalCredential.getClientSupportedProtocols() 🤔

Edit: Connecting a couple of threads, back in January @kdenhartog mentioned it might not be degrading privacy to offer a list of values:

This makes sense and doesn't present a large concern to me. It's effectively just a browser fingerprint then rather than App install fingerprint, but someone can look at the UA if that's what they want. In which case, this isn't somehow degrading privacy.

And it seems in line with what @marcoscaceres and other Editors discussed earlier that month:

Editor's discussed what "it" means:

• the browser knows about it (does necessarily support it)
• does not mean any wallet support it or any wallet.

So, DigitalCredential.knownProtocols might be more appropriate as a name.

Edit: Nevermind to this idea, it wouldn't make it easy for any platform to signal that it supports all protocols because it'd require the platform to maintain a list of all the possible protocols. That's not really feasible...

[hlflanagan]

Discussed on 2025-04-30 Series B call https://github.com/w3c-fedid/meetings/blob/main/2025/2025-04-30-DCAPI-B-notes.md