]> Microsoft

Maik.Riechert@microsoft.com

Microsoft

antdl@microsoft.com

Fraunhofer SIT

henk.birkholz@ietf.contact

Microsoft

Amaury.Chamayou@microsoft.com

DID X.509 This document defines the did:x509 decentralized identifier (DID) method, a flexible issuer identifier format for messages that transport or refer to X.509 certificates, including CBOR Object Signing and Encryption (COSE) messages using RFC 9360. The did:x509 identifier format implements a direct, resolvable binding between a certificate chain and a compact issuer string (DID string). It combines the fingerprint of a certification authority (CA) certificate in the chain with one or more predicates on the leaf certificate's subject name, subject alternative names, extended key usage, or Fulcio issuer. The identifier can be conveyed as an issuer value in a COSE Header CBOR Web Token (CWT) Claims map as defined in RFC 9597, in JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) messages, such as in the "iss" claim defined in RFC 7519, or through other protocol-specific mechanisms that associate the identifier with the certificate chain. The did:x509 method lets existing X.509 solutions and DID-based systems interoperate where a full transition to DIDs is not achievable or desired. This issuer identifier is convenient for references and policy evaluation, for example in the context of transparency ledgers. This Informational document is published as an Independent Submission to describe the method as implemented by Microsoft. It is neither a standard nor a product of the IETF. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction This document aims to define an interoperable and flexible issuer identifier format, based on decentralized identifiers (DIDs) , for messages that transport or refer to X.509 certificates (), including CBOR Object Signing and Encryption (COSE) messages using . The did:x509 identifier format implements a direct, resolvable binding between a certificate chain and a compact issuer string. It can be conveyed as an issuer value in a COSE Header CBOR Web Token (CWT) Claims map as defined in , in JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) messages, such as in the iss claim defined in , or through other protocol-specific mechanisms that associate the identifier with the certificate chain. The RWOT11 workshop outlined the need for hybrid solutions that combine X.509 certificates with DIDs (). The did:x509 method relies on X.509 chain validation and matches elements contained in the DID to certificate properties within the chain. The main difference from other DID methods is that did:x509 requires a certificate chain to be passed using a new DID resolution option (), x509chain, while resolving a DID. Including a certificate chain directly in configuration or in policy is often impractical. This is due to its size, and to the frequency at which some elements, particularly the leaf, are refreshed. Relying on a partial certificate chain (e.g., a root certificate and some intermediate certificates) is similarly unwieldy. While stable, the level of granularity afforded by a partial certificate chain may not be sufficient to distinguish several identities that are not equivalent for the purpose of policy. Combining authority pinning with certificate predicates is a precise and stable way of capturing identities as a constrained set of certificates. Their representation as compact and durable identifier strings enables the formulation of readable policy (e.g., "request.issuer == 'did:x509...'"), for example, in the Registration Policies of Transparency Services .

Interoperability Between X.509 and DIDs The did:x509 method lets existing X.509 solutions and DID-based systems interoperate without changes to either:

• The X.509 side is unchanged. Certification authorities, public or private, issue ordinary certificates, signers keep their keys, and did:x509 identifiers are created locally from certificate chains ().
• The evidence travels with the message. Resolution needs only the DID and the certificate chain that signed messages already carry, for example in the x5chain () or x5c () header parameters, so any resolver that accepts the chain derives the same DID Document, without a registry lookup ().
• X.509 keys work in DID-based protocols. The DID Document exposes the leaf certificate's public key as a verification method, with verification relationships that follow its key usage (), so these protocols need not handle certificates.
• X.509 trust is expressed as a DID. The certification authority (CA) fingerprint and the predicates let DID-based policies capture an X.509 identity rather than individual certificates.

A single signed message can therefore serve both kinds of relying party (). An X.509-only verifier validates the certificate chain with its trust store and ignores the issuer, while a DID-aware verifier resolves the issuer against the same chain and applies its DID-based policy. Neither needs the other's infrastructure.

One Signed Message for X.509 and DID Verifiers | Signer | +------+ +--------+ | | signed message with the certificate | chain and a did:x509 issuer | +------------+------------+ | | v v +---------------------+ +----------------------+ | X.509-only verifier | | DID-aware verifier | | validates the chain | | resolves the issuer | | with its trust | | against the chain, | | store | | applies DID policy | +---------------------+ +----------------------+ ]]>

Relationship to the did:x509 Method Specification The did:x509 method is registered in the W3C DID Methods registry (), whose entry points to the did:x509 Method Specification maintained in the microsoft/did-x509 repository (). This document is aligned with , and much of its text, including the ABNF, the Rego policy, and the DID resolution procedure, is adapted from it; the authors of are also authors of this document. The authors intend to keep this document and synchronized as both evolve. Microsoft has implemented did:x509 in a range of libraries and systems. Its internal and external signing services, such as Artifact Signing, derive did:x509 identifiers from their existing issuing CAs and extended key usages (EKUs), and use them as the issuer of the COSE envelopes they produce, which include Supply Chain Integrity, Transparency, and Trust (SCITT) Signed Statements . Relying parties' policies pin the accepted did:x509 issuers, together with subjects, to decide which Transparent Statements to accept, and for which purpose.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. In this document, the Concise Data Definition Language (CDDL) is used to describe the data formats, and ABNF (, ) to describe identifiers. This document uses the terms "DID", "DID URL", "DID Document", "DID subject", "DID resolution", "verification method", and "controller" as defined in , and the terms "certification path" and "trust anchor" as defined in . A "relying party" is an entity that relies on a resolved did:x509 identifier, for example, to authorize the signer of a message. Rego () is a declarative policy language. This document uses Rego, rather than pseudo-code, to define DID syntax validation and predicate validation for did:x509 identifiers, so that the logic is precise and unambiguous and can be evaluated automatically. The Rego code snippets provided in this document can be evaluated using any Rego v1 runtime, but there is no expectation that implementations use the Rego language. Per , line breaks may be present in the figures of this document to stay within the line-length limits of this document's format. Examples in this document abbreviate long base64url values, such as CA fingerprints, to their first and last two characters with two dots in between (for example, WE..jk) to avoid visual clutter otherwise caused by line size restrictions. Abbreviated values are not syntactically valid.

Identifier Syntax The DID method name is x509. A did:x509 DID starts with did:x509: and binds a CA fingerprint to one or more certificate predicates. The did:x509 ABNF below uses the syntax defined in , with case-sensitive string literals written as %s"..." per , and the core rules ALPHA, DIGIT, and HEXDIG from . contains the definitions for idchar and pct-encoded in Section 3.1.

ABNF Definition of Core did:x509 Syntax

The version value MUST be 0. ca-fingerprint-alg is one of sha256, sha384, or sha512. ca-fingerprint is a base64url-encoded digest of a non-leaf certificate in the certificate chain, that is, chain[i].fingerprint[ca-fingerprint-alg] with i > 0: either an intermediate or root CA certificate. In this document, chain refers to the certificate chain mapped to the JSON data model defined in . The :: separator introduces each predicate. Each predicate has a predicate-name and a predicate-specific predicate-value. The method-specific identifier has three parts:

1. A version number.
2. A certification authority fingerprint algorithm and value.
3. One or more predicates that match fields in the leaf certificate.

The DID subject is the logical identity selected by the CA fingerprint and sequence of predicates. It is not necessarily the X.509 subject name; subject is only one predicate type. did:x509 does not define any DID URL path or query semantics. A did:x509 DID URL MUST NOT include a path or query component. Fragment identifiers remain valid for identifying resources within a resolved DID Document, for example <DID>#0. Example: did:x509:0:sha256:WE..jk::subject:C:US:ST:Texas:L:Austin:O:Example In this example, the identifier pins to a certification authority using a SHA-256 certificate hash and uses the subject predicate to express criteria that a leaf certificate subject must fulfil. This identifier will match certificate chains with matching leaf certificate subject fields and a matching intermediate or root CA certificate. The following sections define the predicates and their predicate-specific syntax. The inputs to the resolution process are the DID string itself and the x509chain DID resolution option, which carries a comma-separated base64url-encoded X.509 certificate chain. To evaluate the reference Rego code shown below, the DID and certificate chain have to be passed to a Rego runtime as a JSON document: {"did": "<DID>", "chain": <CertificateChain>}, where did is the DID string and chain is the parsed representation of the certificate chain derived from the x509chain resolution option. Core Rego policy:

Core Rego Validation Rule 0 ca := [c | some i; i != 0; c := input.chain[i]] ca[_].fingerprint[ca_fingerprint_alg] == ca_fingerprint valid_predicates := [i | some i [name, value] := predicates[i] validate_predicate(name, value) ] count(valid_predicates) == count(predicates) } ]]>

The overall Rego policy is assembled by concatenating the core Rego policy with the Rego policy fragments in the following sections, each one defining a validate_predicate function.

Percent-Encoding Some of the predicates that are defined in subsequent sections require values to be percent-encoded. Percent-encoding is specified in . Characters are encoded as UTF-8 () before percent-encoding. All characters that are not in the allowed set defined below MUST be percent-encoded:

ABNF Definition of Characters That Do Not Need to Be Percent-Encoded

Note that most libraries implement percent-encoding in the context of URLs and do not encode ~ (%7E). Resolution fails if a percent-decoded value is not valid UTF-8.

"subject" Predicate

ABNF Definition of the "subject" Predicate

<key>:<value> are the subject name fields in chain[0].subject in any order. Key repetitions are not allowed. Values MUST be percent-encoded. Example: did:x509:0:sha256:WE..jk::subject:C:US:ST:Texas:L:Austin:O:Example Rego policy:

Rego Function Validating the "subject" Predicate = 1 object.subset(input.chain[0].subject, subject) == true } ]]>

"san" Predicate

ABNF Definition of the "san" Predicate

san-type is the subject alternative name (SAN) type and MUST be one of email, dns, or uri. Note that dn is not supported. san-value is the SAN value, percent-encoded. The pair [<san_type>, <san_value>] is one of the items in chain[0].extensions.san. Example: did:x509:0:sha256:WE..jk::san:email:bob%40example.com Rego policy:

Rego Function Validating the "san" Predicate

"eku" Predicate

ABNF Definition of the "eku" Predicate

eku is one of the OIDs within chain[0].extensions.eku. Example: did:x509:0:sha256:WE..jk::eku:1.3.6.1.4.1.311.10.3.13 Rego policy:

Rego Function Validating the "eku" Predicate

"fulcio-issuer" Predicate

ABNF Definition of the "fulcio-issuer" Predicate

fulcio-issuer is chain[0].extensions.fulcio_issuer, without leading https://, percent-encoded. The fulcio_issuer extension MUST be present on chain[0] when this predicate is used; resolution fails if it is absent. The extension MUST NOT be marked critical. Example: did:x509:0:sha256:WE..jk::fulcio-issuer:accounts.example.com::san:email:bob%40example.com Example 2: did:x509:0:sha256:WE..jk::fulcio-issuer:issuer.example.com::san:uri:https%3A%2F%2Fexample.com%2Focto-org%2Focto-automation%2Fworkflows%2Foidc.yml%40refs%2Fheads%2Fmain Rego policy:

Rego Function Validating the "fulcio-issuer" Predicate

DID Resolution Options This DID method introduces a new DID resolution option called x509chain: Name: x509chain Value type: string The value is constructed as follows:

1. Encode each certificate C that is part of the chain as the string b64url(DER(C)), where DER(C) is the DER encoding () of C and b64url is base64url encoding ().
2. Concatenate the resulting strings in order, separated by comma ",".

The chain is ordered leaf first and root or trust anchor last:

Structure of the x509chain Resolution Option Value

Each comma-separated item is the DER encoding of one complete X.509 certificate, not a public key, fingerprint, or DER encoding of the whole chain.

Verifiable Data Registry and Trust Model did:x509 does not define a persistent registry of DID Documents. Resolution uses the DID string and the x509chain resolution option (). Trust is established by validating the certificate chain, matching the CA fingerprint, and validating the predicates against the leaf certificate. Applications can add revocation, certificate transparency, signing time, or endorsement checks.

DID Document Resolving a did:x509 identifier produces a DID Document () with a JsonWebKey verification method derived from the leaf certificate public key. The DID Document is self-controlled: verification methods use the DID itself as controller. If the leaf certificate has the key usage bit for digitalSignature, or is missing the key usage extension, the DID Document includes authentication and assertionMethod. If the leaf certificate has the key usage bit for keyAgreement, or is missing the key usage extension, the DID Document includes keyAgreement. If the leaf certificate includes the key usage extension but has neither digitalSignature nor keyAgreement, resolution fails. The registered media type for a DID Document is application/did. Resolvers may also support application/did+ld+json or application/did+json for compatibility with DID Core 1.0 tooling. The media type is selected by the resolution request, not by the DID string. The JSON for Linking Data (JSON-LD) @context MUST define every term used. The example below uses the Controlled Identifiers v1 context https://www.w3.org/ns/cid/v1 (). This illustrates what a typical DID Document, describing the DID subject and the methods it can use to authenticate itself, can look like once resolved:

Example DID Document

CDDL for a JSON Data Model for X.509 Certificate Chains For predicate evaluation, the resolver maps the certificate chain to a limited JSON () data model. This model contains only the fields did:x509 matches on; it does not replace X.509 parsing or path validation. The model is a JSON array with at least two certificate objects. The leaf certificate is first, followed by issuer certificates, with the root or trust anchor last. The fingerprint member of a certificate object contains base64url-encoded () SHA-256, SHA-384, and SHA-512 () hashes of the DER-encoded certificate. The issuer and subject members contain the X.509 issuer and subject names, each represented as an object of name attributes. Name objects use the labels CN, L, ST, O, OU, C, and STREET for common attributes. Other attributes use dotted OID strings as keys. Repeated attributes are not supported. Values are converted to UTF-8 strings. The extensions member can contain the Extended Key Usage OIDs (), the Subject Alternative Name entries (), and the Fulcio issuer extension value ().

CDDL Definition of did:x509 JSON Data Model tstr } ; base64url-encoded data, see RFC 4648, Section 5 base64url = tstr ; ASN.1 Object Identifier ; Dotted string, for example "1.2.3" OID = tstr ; X.509 Subject Alternative Name ; Strings are converted to UTF-8 SAN = rfc822Name / DNSName / URI / DirectoryName rfc822Name = ["email", tstr] ; e.g., ["email", "user@example.com"] DNSName = ["dns", tstr] ; e.g., ["dns", "example.com"] URI = ["uri", tstr] ; e.g., ["uri", "https://example.com"] DirectoryName = ["dn", Name] ; e.g., ["dn", {CN: "Example"}] ]]>

Example certificate chain mapped to the JSON data model:

Example Certificate Chain in the did:x509 JSON Data Model

Method Operations

Create Creating a did:x509 identifier is a local operation. The DID MUST be constructed according to the syntax rules in this specification. No registration action is required, and no registry authorization is checked. When constructing a did:x509 identifier, determine what constitutes a logical identity within a given certification authority. Concretely, determine which certificate fields the authority uses to uniquely represent an identity. After that, choose one or more matching predicates that express such an identity as faithfully as possible. As an example, a certification authority may use email addresses as a way to separate identities and use the SAN extension to store the email address. In that case, the did:x509 identifier should be constructed using the san predicate, for example, did:x509:0:sha256:<ca-fingerprint>::san:email:bob%40example.com. In other cases, an authority may not include email addresses at all and instead rely on a specific set of subject fields to separate identities. In that case, the subject predicate should be used. In yet other cases, authorities may assign unique numbers or other types of stable identifiers to logical identities. Typically, this is done to have a stable reference even if a person changes their name or email address. In all cases, the goal is to craft a did:x509 identifier that is stable yet not too loose in its predicates. An example of a loose did:x509 identifier may be to use the subject predicate and only include the O field without location fields like country (C) or state/locality (ST). Whether a did:x509 identifier should pin to an intermediate CA instead of a root CA depends on whether there is value in distinguishing between them. Pinning to an intermediate CA typically means that the lifetime of the did:x509 identifier will be shorter, since intermediate CA certificates usually have a shorter validity period than root CA certificates.

Read / Resolve The Read operation is DID resolution. The operation takes as input a DID to resolve, together with the x509chain DID resolution option (). The DID resolver uses the DID, the certificate chain, and the process in to generate a DID Document. No caller authorization is required; authenticity is checked by certificate chain validation, CA fingerprint matching, and predicate validation.

Update This DID method does not support updating the DID Document, assuming a fixed certificate chain. There is no update authorization operation. However, the public key included in the DID Document varies depending on the certificate chain that was used as input to the DID resolution process. Typically, multiple chains, in particular leaf certificates, are valid for a given did:x509 identifier.

Deactivate This DID method does not support deactivating the DID. There is no deactivation authorization operation. However, if the certification authority revokes all certificates for the matching DID, or they expire, and does not issue new certificates matching the same DID, then this can be considered equivalent to deactivation of the DID. There is no technical guarantee in this case and the certification authority can revert its decision.

DID Resolution If the DID to resolve is given as a DID URL, its fragment, if any, is removed first, and <DID> below refers to the result. Resolution fails if the DID URL has a path or query component. The following steps MUST be used to generate a corresponding DID Document:

1. Decode the x509chain resolution option value into individual certificates by splitting the string on "," and base64url-decoding each resulting string. The result is a list of DER-encoded certificates that can be loaded in standard libraries. Fail if the list contains fewer than two certificates.
2. Check whether the list of certificates forms a valid certificate chain using certification path validation procedures () with the last certificate in the chain as trust anchor. Implementations MUST perform certification path validation. Additionally, fail if any certificate in the chain contains a critical extension that is neither (a) one of the extensions represented in the JSON data model (eku, san), nor (b) one of the following standard extensions: basicConstraints, keyUsage, nameConstraints, policyConstraints, policyMappings, certificatePolicies, inhibitAnyPolicy. The fulcio_issuer extension is deliberately not on that list. Fulcio does not mark it critical; for example, a dump of a Fulcio-issued certificate () shows its critical field as BOOL ABSENT. Issuers MUST NOT mark it critical: it is an unrecognized extension for the purposes of certification path validation, so marking it critical may cause the chain to be rejected. Instead of using the current time as specified in when validating the chain, applications may choose a context-relevant point in time. For example, applications handling signed documents may choose to use the signing time instead, which might come from a CWT iat claim () or JWT iat claim (). Such a claim is not trusted time by itself and needs to be integrity protected and accepted by application policy.
3. If required by the application, check whether any certificate in the chain is revoked using certificate revocation lists (CRLs) , the Online Certificate Status Protocol (OCSP) , or other mechanisms.
4. Apply any further application-specific checks, for example disallowing insecure certificate signature algorithms.
5. Map the certificate chain to the JSON data model ().
6. Check whether the DID is valid against the certificate chain in the JSON data model according to the Rego policy or equivalent rules defined in this document.
7. Extract the public key of the first certificate in the chain.
8. Convert the public key to a JSON Web Key (JWK) .
9. Create the following partial DID Document: ", "verificationMethod": [{ "id": "#0", "type": "JsonWebKey", "controller": "", "publicKeyJwk": { "kty": "" } }] } ]]>
10. If the first certificate in the chain has the key usage bit position for digitalSignature set or is missing the key usage extension, add the following to the DID Document: #0"], "assertionMethod": ["#0"] } ]]>
11. If the first certificate in the chain has the key usage bit position for keyAgreement set or is missing the key usage extension, add the following to the DID Document: #0"] } ]]>
12. If the first certificate in the chain includes the key usage extension but has neither digitalSignature nor keyAgreement set as key usage bits, fail.
13. Return the complete DID Document.

Implementation Status (Boilerplate as per :) This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". The information in this section was last updated in September 2026.

Microsoft The implementations below are the ones that Microsoft publishes as open source. Microsoft also has internal implementations, which are not listed here. For all of them, the organization is Microsoft and the contact is the authors of this document.

did-x509

Link:

Description:

The repository of the upstream specification (), with a Python reference resolver and the test vectors ().

Coverage:

DID resolution as specified in this document, including certification path validation, all four predicates, and DID Document creation.

Maturity:

Reference implementation; no tagged releases.

Licensing:

MIT

didx509cpp

Link:

Description:

A header-only C++ library that resolves did:x509 identifiers against PEM-encoded certificate chains and returns the DID Document.

Coverage:

All four predicates and certification path validation with OpenSSL. Certificate validity periods can optionally be ignored.

Maturity:

Released; latest release 0.99.0 (June 2026).

Licensing:

MIT

Used by:

CCF and scitt-ccf-ledger.

didx509go

Link:

Description:

A Go library that resolves did:x509 identifiers against certificate chains.

Coverage:

All four predicates and certification path validation.

Maturity:

Tagged versions; latest v0.0.3 (February 2024).

Licensing:

MIT

Used by:

cosesign1go and hcsshim.

cosesign1go

Link:

Description:

A Go library and command-line tool (sign1util) for COSE_Sign1 documents. It creates did:x509 identifiers from a certificate chain, and checks that the did:x509 issuer of a document matches the certificate chain that signed it.

Coverage:

Creation, and resolution using didx509go.

Maturity:

Released; latest release v1.7.0 (September 2026).

Licensing:

MIT

Used by:

hcsshim and the Azure CLI confcom extension.

CoseSignTool

Link:

Description:

A C# command-line tool and set of libraries for signing and validating COSE_Sign1 messages. When signing with a certificate, it derives a did:x509 issuer for the CWT Claims from the certificate chain.

Coverage:

Creation, with the "subject" predicate by default, or with the "eku" predicate when the leaf certificate has a Microsoft-specific EKU.

Maturity:

Released; latest release v1.8.1 (September 2026).

Licensing:

MIT

scitt-ccf-ledger

Link:

Description:

A SCITT Transparency Service application built on CCF. It registers signed statements whose CWT issuer is a did:x509 identifier, resolving the identifier against the statement's certificate chain, and its Registration Policies can match on the issuer. Its Python command-line tool creates signed statements with did:x509 issuers.

Coverage:

Creation, and resolution using didx509cpp.

Maturity:

Released; latest release 0.20.1 (September 2026).

Licensing:

MIT

CCF

Link:

Description:

The Confidential Consortium Framework. It resolves the did:x509 issuers of COSE-signed endorsements, such as utility VM endorsements for confidential containers, against their certificate chains.

Coverage:

Resolution using didx509cpp.

Maturity:

Released; latest release 7.0.17 (September 2026).

Licensing:

Apache-2.0

hcsshim

Link:

Description:

The Host Compute Service shim. Its security policy enforcement for confidential containers checks that the did:x509 issuer of a signed policy fragment matches the fragment's certificate chain.

Coverage:

Resolution using cosesign1go and didx509go.

Maturity:

Released; latest release v0.14.1 (April 2026).

Licensing:

MIT

Azure CLI confcom Extension

Link:

Description:

An extension, in the src/confcom directory, that generates security policies for confidential containers. The policies name the did:x509 issuers of trusted policy fragments, and the extension signs fragments with the sign1util tool from cosesign1go.

Coverage:

Use of did:x509 identifiers as the issuers of signed policy fragments, relying on cosesign1go.

Maturity:

Released; latest release 2.2.0 (September 2026).

Licensing:

MIT

Nuts Foundation The Nuts Foundation maintains open-source software for exchanging healthcare data in the Netherlands. For all of the implementations below, both the organization and the contact are the Nuts Foundation ().

nuts-node

Link:

Description:

The reference implementation of the Nuts specification, a decentralized identity network based on W3C Verifiable Credentials and DIDs. It has its own did:x509 resolver, and its DID Documents for did:x509 identifiers include the certificate chain.

Coverage:

Resolution, except for the "eku" predicate. It also supports a "san" predicate with the otherName type, which this document does not define.

Maturity:

Released; latest release v6.2.13 (September 2026).

Licensing:

GPL-3.0

go-didx509-toolkit

Link:

Description:

A Go toolkit and command-line tool that creates did:x509 identifiers from certificate chains, and issues X509Credential Verifiable Credentials with them. It follows the did:x509 specification published by the Trust Over IP Foundation, extended with a "san" predicate for the otherName type, which certificates from the Dutch healthcare UZI register require.

Coverage:

Creation, including the otherName extension.

Maturity:

Released; latest release v1.3.0 (April 2026).

Licensing:

GPL-3.0

uzi-did-x509-issuer-java

Link:

Description:

A Java library that issues UziServerCertificateCredentials, which are Verifiable Credentials for server certificates from the Dutch healthcare UZI register, with a did:x509 issuer.

Coverage:

Creation.

Maturity:

No tagged releases.

Licensing:

MIT

Security Considerations

Identifier Ambiguity This DID method maps characteristics of X.509 certificate chains to identifiers. It allows a single identifier to map to multiple certificate chains, giving the identifier stability across the expiry of individual chains. However, if the predicates used in the identifier are chosen too loosely, the identifier may match too wide a set of certificate chains. This may have security implications as it may authorize an identity for actions it was not meant to be authorized for. To mitigate this issue, the certification authority should publish its expected usage of certificate fields and indicate which ones constitute a unique identity, versus any additional fields that may be of an informational nature. This will help users create an appropriate did:x509 identifier as well as consumers of signed content to decide whether it is appropriate to trust a given did:x509 identifier.

X.509 Trust Stores Resolution validates the supplied certificate chain with the last certificate in x509chain as the path-validation trust anchor. This checks the chain and DID predicates, but does not decide whether the CA or DID is acceptable to a relying party. Relying parties make that trust decision by policy, for example through a CA trust store, an allowlist of DIDs or CA fingerprints, or other application-specific rules.

Use of Identifier Contents While it is acceptable to use a did:x509 identifier as an opaque handle to implement a relying-party policy, implementers MUST NOT parse or interpret individual components of the identifier string for authorization decisions unless the identifier has been resolved against a verified certificate chain. Specifically, extracting and relying upon subject names, organizational information, or other embedded values directly from the identifier string, without performing full resolution and chain validation, is insecure. An attacker could craft a syntactically valid did:x509 identifier containing arbitrary values that do not correspond to any legitimate certificate chain. Only after successful resolution, which includes verification of the CA fingerprint against the provided chain and validation of all predicates, can the identifier be considered authentic. Systems that bypass this resolution process and instead parse identifier components directly are vulnerable to impersonation and privilege escalation attacks.

Privacy Considerations The did:x509 identifier can contain certificate subject names, subject alternative names, extended key usage values, Fulcio issuer values, and a certification authority fingerprint. These values can reveal personal names, email addresses, domain names, organizational affiliations, credential issuers, or other identifying information. DID creators should choose predicates that are specific enough for relying-party policy but disclose no more certificate attributes than necessary. The x509chain resolution option carries the certificate chain used as resolution evidence. Certificates can contain additional metadata beyond the predicates encoded in the DID, including subject attributes, SAN entries, validity periods, certificate policies, and extension values. Resolvers and verifiers should treat certificate chains as potentially identifying data, avoid unnecessary logging or redistribution, and apply data minimization when retaining resolution inputs or outputs. Stable did:x509 identifiers can enable correlation across transactions, transparency logs, ledgers, and verifiable credentials (). If unlinkability is required, relying parties should avoid reusing the same did:x509 identifier across contexts, and issuers should prefer predicates based on role- or service-specific identifiers rather than human-identifying certificate fields.

IANA Considerations This document has no IANA actions. The did:x509 method is registered in the W3C DID Methods registry (), as described in .

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] National Institute of Standards and Technology ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. ITU-T Open Policy Agent n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. Microsoft Microsoft Sigstore n.d. Sigstore Microsoft This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Test Vectors The machine-readable certificate chains, DIDs, expected resolution outcomes, and expected DID Documents are maintained in . The file is an array of independent input/output test cases. Each input embeds its certificate chain as an array of unpadded base64url-encoded DER certificates in leaf-first order. Each output contains either the expected DID Document or an expected error pattern. Certificate validity periods are not checked by these vectors.