DigitalCredential.userAgentAllowsProtocol()

Syntax

// Digital Credentials (FedID WG draft) — normative form
// Static method on the DigitalCredential interface:
const allowed = DigitalCredential.userAgentAllowsProtocol(protocol);

// protocol is a DOMString identifier, e.g.:
//   "openid4vp-v1-unsigned" | "openid4vp-v1-signed" |
//   "openid4vp-v1-multisigned" | "org-iso-mdoc"     (presentation)
//   "openid4vci-v1"                                 (issuance)

Inputs

One argument: a DOMString protocol identifier. The current specification defines these presentation protocols: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, and org-iso-mdoc; and this issuance protocol: openid4vci-v1. Each WebIDL enumeration is a closed set in a given specification revision, although later revisions can add values.

Outputs

A boolean: true if the user agent allows the named protocol for digital credential issuance or presentation. Verifiers use it to determine which protocols a browser allows before making an API call — so an application can pick a mutually supported protocol rather than failing mid-request.

Errors

Unknown protocol identifier → false, never an exception. The spec is explicit: calling with an unknown identifier safely returns false without throwing — which is what makes the method safe as a forward-compatible support probe when new identifiers appear.

Undefined interface → ReferenceError. On a browser where DigitalCredential is not defined at all, calling the method throws a ReferenceError — so the typeof DigitalCredential !== "undefined" guard is required before using it.

Context

Receiver: the DigitalCredential interface object itself — this is a static method, so no credential instance is needed.

Availability: Chrome 141 and Safari 26 per BCD. Chrome 151's arbitrary-protocol deprecation trial uses chrome://flags/#enable-experimental-web-platform-features; DigitalCredentialsProtocolFilter is the separate Finch/Blink runtime token (status experimental at trunk). Removal is targeted for Chrome 160.

Permissions: no permission prompt attaches to the check itself; the API family integrates with Permissions Policy and the credentials user-permission model per the draft.

Lifecycle

A synchronous query — no promise or event. The allowed set can change across browser major versions as specification revisions and implementations evolve, so treat the answer as a point-in-time capability read. Pair it with the deprecation timeline: arbitrary identifiers outside the normative registry are deprecated from 151 and targeted for removal at 160, so the durable pattern is a registered identifier plus this check.

Examples

// The two-step gate (spec's own pattern):
if (typeof DigitalCredential !== "undefined") {
  // The API is supported — now check the protocol:
  if (DigitalCredential.userAgentAllowsProtocol("openid4vp-v1-signed")) {
    // DC API supported. Proceed with issuance or presentation.
  }
}

// Forward-compat: an identifier this browser doesn't know yet
// returns false — it does not throw:
console.log(DigitalCredential.userAgentAllowsProtocol("future-protocol")); // false

Compatibility

Vendor signals per the ChromeStatus API feature record.

Security and privacy

The result is deliberately a coarse browser capability bit. The user agent must not vary it based on hardware availability, installed or configured software and credential managers, stored credentials, or user configuration and preferences; doing so could fingerprint or silently reveal user behavior. The draft says it should vary only by user-agent major version and indicate whether the browser can distribute that protocol's requests to an underlying platform or provider. It does not prove that the OS, a wallet, or a credential is available.