Summary

  • draft-birkholz-did-x509-03 resolves an identifier by validating a supplied leaf-first certificate chain with its last certificate as the path-validation anchor, then matching a non-leaf fingerprint and predicates over the leaf.
  • That algorithmic anchor is not automatically an anchor the relying party trusts. Acceptance still belongs to a local trust store, allowlist or application policy; received certificate material must not silently rewrite that policy.
  • Resolution, relying-party trust, message-signature verification, purpose authorization, commit and external outcome require separate receipts. Revision 03 is an Informational Independent-Submission Internet-Draft, not an RFC or IETF standard.

The resolver returned success. It had decoded the identifier, reconstructed the supplied chain, validated the signatures from the leaf to the certificate at the end, found the named CA fingerprint and matched every predicate. It then derived a DID document containing the leaf public key.

Nothing in that sequence established that the relying party trusted the certificate at the end of the chain.

This is the quiet but consequential boundary in revision 03 of did:x509, dated 30 September 2026. The method makes an X.509 identity portable without a persistent DID-document registry. Its compact identifier binds a non-leaf certificate fingerprint to constraints on a leaf certificate. A resolver receives the certificate chain as evidence and deterministically reconstructs verification material. The mechanism is useful precisely because it can be deterministic. It becomes dangerous when that determinism is allowed to impersonate institutional trust.

An identifier that names a rule, not one certificate

The core form begins did:x509:0, followed by a fingerprint algorithm and fingerprint, then one or more predicates. The draft permits SHA-256, SHA-384 and SHA-512. The fingerprint is calculated over a non-leaf certificate in the chain: an intermediate CA or the root-like certificate used as the resolution anchor. The predicates constrain fields in the leaf.

Those predicates are more expressive than a bare subject string. A subject predicate checks whether selected name attributes form a subset of the leaf subject. A san predicate selects one email, DNS or URI subject-alternative-name value. An eku predicate requires an Extended Key Usage object identifier. A fulcio-issuer predicate matches the leaf's Fulcio issuer extension after restoring its https:// prefix; the extension must be present and noncritical.

The result is intentionally capable of surviving leaf-certificate rotation. The same DID may resolve through more than one valid leaf chain so long as the non-leaf fingerprint and all predicates continue to match. Stability is purchased by describing a class of acceptable certificates rather than pinning one leaf.

That trade has a control surface. A loose subset predicate can describe a larger class than the issuer intended. subject:C:US may be syntactically precise and institutionally useless. Matching a permitted EKU says that an OID appears in the certificate; it does not say that a particular relying party authorized this signer to approve this deployment, register this artifact or spend this resource. Predicate design is an identity-selection policy, not an application mandate.

The chain brings its own algorithmic anchor

Resolution takes an x509chain option containing complete DER certificates encoded in base64url and separated by commas. The order is leaf first, then intermediates, with the final certificate treated as the trust anchor for the path-validation run. Fewer than two certificates must fail.

The resolver performs certification-path validation under RFC 5280. It checks the chain under the selected validation time, certificate policies and constraints, names, key uses, critical extensions, algorithms and signatures. It separately verifies that the DID fingerprint matches a non-leaf certificate and that every predicate matches the leaf. If those checks pass, it derives a JWK from the leaf public key and builds the DID document.

Calling the final certificate a “trust anchor” is correct inside the path-validation algorithm and incomplete outside it. RFC 5280 treats trust-anchor information as an input chosen under policy. In did:x509 resolution, the final supplied certificate provides that input for the deterministic relationship test. The relying party must still decide whether that CA, fingerprint or DID is acceptable in its own context.

RFC 9360 makes the adjacent COSE rule explicit: certificate chains received with a message must not silently alter the application's configured trust anchors. Transported evidence can help build and validate a path. It cannot appoint its own sovereign.

The distinction can be recorded compactly:

Receipt What it can establish What remains open
DID parse The version, algorithm, fingerprint and predicates are well formed Whether any legitimate chain satisfies them
Supplied-chain validation The leaf chains to the last supplied certificate under stated inputs Whether that certificate is locally trusted
Fingerprint and predicate match The chain belongs to the class described by the DID Whether the class is narrow enough for the action
Local trust decision This relying party accepts the anchor or DID for this context Whether the actual message signature is valid
Signature verification The covered bytes verify under the resolved key Whether the signer may perform this operation
Purpose authorization A named actor may perform a named operation over a named resource Whether the operation committed and had its claimed effect

A single field such as resolved=true cannot honestly stand in for the table.

Direct parsing creates an unsigned identity oracle

The identifier is readable enough to tempt shortcuts. An application can split the string, extract an organization, DNS name or email-shaped predicate, and use that value before resolution. Revision 03 warns against this approach. Identifier components are untrusted until they have been checked against a valid chain.

Anyone can compose a syntactically valid string containing impressive subject attributes. The string alone proves no issuer signed them and no leaf certificate contains them. An authorization system that grants a role from the visible predicate has converted public syntax into a self-assertion channel.

The safe sequence is less convenient and more legible: preserve the exact DID bytes; obtain the exact chain; perform path validation; match the fingerprint and every predicate; apply the relying party's trust policy; verify the message signature and its covered bytes; then evaluate the requested purpose. Each transition produces its own evidence or its own explicit unknown.

Time and revocation are policy inputs, not decorations

Path validation needs a time. The draft permits current time or a context-relevant point such as signing time. That choice can change the result when a leaf has expired since an artifact was signed. A JWT or CWT iat value is not a trustworthy clock merely because it exists. RFC 7519 and RFC 8392 define issued-at claims, but the application still has to verify integrity and decide whether the claim is acceptable for the validation context.

Revocation is likewise conditional. If the application requires it, the draft points to CRLs, OCSP or another mechanism. An application may add certificate-transparency evidence, endorsement checks or an algorithm-deny policy. These choices must travel with the result. “The chain validated” without validation time, revocation posture and algorithm policy is not a reproducible claim.

The relevant lesson from RFC 9597 and the newer transparency-receipt work in RFC 9943 is broader than any one token format: evidence objects require explicit verification context. Merely carrying a certificate or receipt does not define the authority that consumes it.

Stable identity does not provide an update governor

The method does not publish a DID document to a registry. Creation is local; resolution uses the DID plus the supplied chain. That removes one mutable registry dependency, but it also means did:x509 defines no DID-document update operation and no update authorization. There is no deactivation operation or deactivation authorization either.

Certificate expiry or revocation can make all presently known matching chains unusable. That can resemble deactivation. It is not an irreversible method-level act: a CA capable of issuing another matching leaf can restore resolvability. Leaders evaluating the method therefore need to ask who controls the CA, which predicates survive reissuance, how relying parties learn policy changes and what evidence marks the end of an identity's legitimate life.

One DID mapping to several leaf chains can be operationally valuable. It can also yield different public keys depending on the supplied evidence. A verifier must retain the actual chain and resolved verification method used for the message, not only the stable DID string.

Running code is evidence with boundaries

Revision 03 says the method is implemented by Microsoft and lists other open-source implementations and uses in signing, SCITT, CCF and confidential-container tooling. The Microsoft repository overview, its specification and test vectors are valuable implementation evidence. The draft also records a Nuts Foundation implementation whose documented eku and otherName SAN coverage differs from revision 03.

That difference is more informative than an adoption count. It identifies the exact place where two implementations may disagree about which certificate belongs to an identifier. The draft's implementation-status boilerplate is appropriately modest: entries are contributor-supplied, are not IETF endorsement and are not a complete feature catalogue.

Revision history matters as well. Revision 02 carried a Standards Track intention. Revision 03 changes the intended status to Informational and substantially expands the trust model, operations, resolution, privacy and implementation discussion. The Datatracker record and history show an individual Independent Submission, not a working-group consensus document. The I-D announcement establishes publication, not standardization.

The wider W3C DID Core model explains DID documents and verification relationships; the DID Specification Registries records method and property namespaces. Neither changes the evidence posture of this particular draft.

The resolution ledger

For each decision, retain the exact identifier and method version; percent-decoded predicate bytes; every DER certificate in supplied order; a hash of the evidence package; path-building and path-validation result; chosen validation time; algorithm, name, policy, constraint and key-use decisions; revocation and transparency posture; matched non-leaf fingerprint; result for every predicate; locally selected trust-store or allowlist rule and its version; resulting DID document and leaf JWK; actual signed object and covered bytes; signature result; purpose-specific authorization rule; requested operation and resource; commit identifier; and

externally observed outcome.

Record absences rather than converting them into success. Use local_anchor_acceptance=not_evaluated when resolution ran without application trust. Use revocation=not_required_by_policy rather than good when no check was made. Use purpose_authorization=pending when the signature passed but the action has not been approved.

Lu Heng's Minimum Initial Specification supports precisely this narrow common layer: standardize the syntax and deterministic verification receipt while keeping future local decisions visible. Running-Code Primacy asks whether implementations and effect traces agree, not whether an identifier looks elegant. The Policy Mirror reveals the trust store as the real allocator of permission. Reality Layers prevents the string, certificate, policy judgment, signature, authorization and outcome from collapsing into one symbolic verdict.

Sources