The protocol member and enumerations

Syntax

// Digital Credentials (FedID WG draft) — normative IDL
dictionary DigitalCredentialGetRequest {
  required DOMString protocol;
  required object data;
};

dictionary DigitalCredentialCreateRequest {
  required DOMString protocol;
  required object data;
};

enum DigitalCredentialPresentationProtocol {
  "openid4vp-v1-unsigned",
  "openid4vp-v1-signed",
  "openid4vp-v1-multisigned",
  "org-iso-mdoc"
};

enum DigitalCredentialIssuanceProtocol {
  "openid4vci-v1"
};

typedef (DigitalCredentialPresentationProtocol or
         DigitalCredentialIssuanceProtocol) DigitalCredentialProtocol;

[Exposed=Window, SecureContext]
interface DigitalCredential : Credential {
  readonly attribute DigitalCredentialProtocol protocol;
  // Other members omitted here.
};

Inputs

On a request, protocol is already a required DOMString — a presentation protocol identifier for get requests or an issuance protocol identifier for create requests. Chrome's deprecation does not make this member newly required: it phases out arbitrary values outside the specification's protocol registry, beginning with the Chrome 151 developer trial and targeting removal in Chrome 160.

Outputs

On the returned DigitalCredential, the protocol attribute echoes the presentation protocol that was used to request the credential, or the issuance protocol that was used to issue it — so the caller can tell which protocol actually serviced the exchange.

Errors

If a required protocol dictionary member is absent, WebIDL conversion throws a TypeError before the API operation runs. That is separate from protocol filtering. During request validation, a request is skipped when its protocol cannot be converted to a registered DigitalCredentialProtocol value or when the user agent does not allow that value. Pre-check with userAgentAllowsProtocol(), which returns false for unknown or disallowed identifiers without throwing. The specification does not assign a protocol-specific exception to the skipped request itself.

Context

Where it lives: the request dictionaries handed to navigator.credentials.get()/create() via the digital option, and the DigitalCredential object those calls resolve to.

Availability: the member and enumerations are 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 (experimental). Removal is targeted for Chrome 160.

Lifecycle

The request member is fixed in the request dictionary, and the resulting credential exposes a readonly protocol attribute; neither has events. Each WebIDL enumeration is closed in the current specification revision. Later revisions may add values, so use userAgentAllowsProtocol() rather than assuming that today's closed set is permanent.

Examples

// A compliant presentation request: explicit protocol + data.
const cred = await navigator.credentials.get({
  digital: {
    requests: [{
      protocol: "openid4vp-v1-signed",   // required and in the registry
      data: { /* protocol-specific request payload */ },
    }],
  },
});

// The credential echoes the protocol that serviced it:
console.log(cred.protocol); // "openid4vp-v1-signed"

Compatibility

Vendor signals per the ChromeStatus API feature record.

Security and privacy

Naming the protocol is itself part of the security model: explicit protocols let the browser apply the right presentation/issuance rules instead of guessing. The draft's Security Considerations (§10 — threat model, mitigations, cross-device security) and Privacy Considerations (§11 — including presentation-protocol topics such as selective disclosure, unlinkable presentations, and verifier authentication) cover what each protocol choice implies.