Version: Draft v1.0

Authors: Alex Tweeddale, Jesse Carter, Markus Sabadello, Scott Perry, Drummond Reed, Tim Bouma

Table of Contents:

Abstract

This specification defines a standardized method for bridging distinct types of Verifiable Identifiers (VIDs)—including X.509 certificates, Decentralized Identifiers (DIDs), and Domain Name System (DNS) records. Bridging is achieved through two complementary mechanisms:

• A Cryptographic Bridge, established through shared control of a common public/private key pair across identifiers, enabling cryptographic verification of ownership.

• A Non-Cryptographic Bridge, established through explicit mutual references, where identifiers directly point to one another, providing clear and verifiable bi-directional linkage.

Together, these bridges allow a VID to become portable across different identifier ecosystems, enabling users and relying parties to carry over the semantic context and trust characteristics inherent in one identifier type into another. Implementers can verify this cross-ecosystem binding by validating both referential integrity and cryptographic control, significantly enhancing assurance in the identity assertions provided by VIDs.

This specification provides concrete guidance and standardized methods for bridging DIDs, DNS domains, and X.509 certificates, ensuring interoperability, practicality, and consistent implementation across VID systems.

1. Introduction

As digital identity systems continue to diversify, the ability to interoperate across different identifier ecosystems has become increasingly important. Each system—whether DNS, X.509, or Decentralized Identifiers (DIDs)—offers unique benefits in terms of governance, cryptographic assurance, and operational context. However, these ecosystems have traditionally remained siloed, limiting the ability to reuse or transfer trust across them.

This specification addresses that challenge by defining standardized methods for bridging Verifiable Identifier (VID) types, using two complementary mechanisms: Cryptographic Bridges and Non-Cryptographic Bridges. Together, these mechanisms allow verifiers to confirm—through both referential integrity and cryptographic proof—that two or more VIDs are controlled by the same entity.

Bridging enables a VID to become portable across ecosystems, allowing it to carry forward the contextual and semantic trust from one system into another. For example, an X.509 certificate may be issued under the governance of a Certificate Authority and contain organization-specific metadata, while a DNS record might provide global recognizability and resolvability, and a DID may offer fine-grained control and programmable identity features. When these are linked securely, the resulting identifier ecosystem offers both broad interoperability and strong assurance.

This specification provides guidance for implementers and identifier controllers on how to establish these bridges using existing standards. The goal is not to replace any individual VID system, but to make them work cohesively—enabling trust to flow across boundaries while respecting the distinct roles and properties of each identifier type.

For example, an organization may choose to bind:

• A DID, hosting cryptographic verification methods and service endpoints;

• A DNSSEC-protected domain, referencing the DID via URI records and cryptographically linking to certificate material via TLSA;

• And an X.509 certificate containing domain identity and governance-linked attributes such as an LEI, signed by a trusted CA.

By linking these identifiers with integrity and intent, a high degree of assurance can be achieved—enabling both human and machine agents to verify identity across systems with confidence.

1.1 Conformance

In addition to sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words MAY, MUST, MUST NOT, OPTIONAL, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Terminology

• Decentralized Identifier (DID): As defined in [DID-CORE].

• DID controller: As defined in [DID-CORE].

• DID document: As defined in [DID-CORE].

• DID URL: As defined in [DID-CORE].

• DID URL Dereferencing: As defined in [DID-CORE].

• X.509 Certificate: As defined in [Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (RFC 5280)].

• DNS Domain Name: A globally unique and hierarchical identifier assigned through the Domain Name System (DNS), as defined in [RFC 1035]. Domain names are commonly used to reference network endpoints and are resolvable to IP addresses.

• DNSSEC: DNS Security Extensions, a suite of specifications for securing information provided by the Domain Name System through cryptographic signatures, as defined in [RFC 4033].

• TLSA Record: A DNS record type used by the DANE protocol to associate a domain name with a specific TLS certificate or public key, as defined in [RFC 6698].

• DANE (DNS-Based Authentication of Named Entities): A protocol that allows X.509 certificates or public keys to be bound to domain names using DNSSEC-protected TLSA records, defined in [RFC 6698].

• Legal Entity Identifier (LEI): A globally unique identifier for legal persons, defined in the ISO 17442 standard and administered by the Global Legal Entity Identifier Foundation (GLEIF). LEIs may be embedded in X.509 certificates or published in DNS using [RFC 9108].

• Legal Person Identifier (LPID): A general term referring to any standardized identifier assigned to a legally recognized entity. This includes, but is not limited to, LEIs, VAT numbers, company registration numbers, and other government-issued organizational identifiers.

• Verification Method: As defined in [DID-CORE], a data structure contained within a DID Document that describes a mechanism for proving control of a DID, typically through a public key or similar cryptographic material.

• Cryptographic Bridge: A linkage between two or more identifiers based on the shared control of cryptographic key material. This bridge enables verifiers to confirm that the same entity controls each identifier.

• Non-Cryptographic Bridge: A linkage between identifiers based on explicit metadata or references (e.g., a DID embedded in an X.509 certificate), which can be independently verified but does not rely on cryptographic key equivalence.

• High Assurance Verifiable Identifier (HAVID): A Verifiable Identifier that is linked to one or more other identifiers through both cryptographic and non-cryptographic bridges, allowing for strong, cross-system assurance of identity control and integrity.

3. Architecture Overview

This specification defines a generalizable architecture for establishing high-assurance linkages between Verifiable Identifier (VID) types that originate from different trust and governance ecosystems. The architecture is based on two complementary bridging mechanisms:

• Cryptographic Bridges — These establish proof of shared control by demonstrating that two or more identifiers are bound to the same public–private key material, or to cryptographically related keys.

• Non-Cryptographic Bridges — These create explicit, machine-readable references between identifiers using metadata fields or protocol-specific records (e.g., a DID Document referencing a DNS domain, or a DNS URI record pointing to a DID).

Together, these mechanisms provide layered assurance:

• Cryptographic bridges confirm that control of identifiers is held by the same entity.

• Non-cryptographic bridges allow for discoverability and semantic linkage, reinforcing intent and contextual association.

This dual-bridge architecture allows identifiers to be correlated across heterogeneous ecosystems (such as DNS, X.509, and DIDs) in a way that is verifiable, portable, and consistent—without requiring centralized coordination or convergence of trust models.

Open

Figure 1: Architecture overview of DID, X.509 and DNS bridges

This architecture is not prescriptive about which identifier is authoritative or primary. Instead, it provides a framework for enabling trust to flow between systems, regardless of which identifier type initiates the resolution.

4. Generalizing the Bridging Pattern

The bridging pattern defined in this specification is broadly applicable to any identity ecosystem in which identifiers exist under different trust frameworks but need to be linked in a verifiable, interoperable, and high-assurance way.

At its core, the bridging model is based on three key principles:

1. Cryptographic Control
   The entity (or controller) must be able to prove control over multiple identifiers by demonstrating possession of the same cryptographic key material—or verifiably linked key material—across different VID types.

2. Explicit Referential Linking
   Each identifier should explicitly reference the others through metadata or records stored within its respective system (e.g., DNS records, X.509 extensions, DID Document fields).

3. Verifiability with Minimal Assumptions
   Verifiers should be able to confirm both the cryptographic and non-cryptographic linkages without requiring new or external trust assumptions beyond those native to each identifier system.

This model allows bridging between diverse VID types—such as DIDs, X.509 certificates, and DNS records—while preserving the integrity and trust guarantees specific to each ecosystem. It offers a generalizable, extensible foundation for building interoperability across domains.

4.1 Context and Role of Each Bridge Type

Each bridging mechanism plays a complementary role in establishing trust across identifiers:

4.1.1 Cryptographic Bridge

Purpose:
To establish verifiable control over a shared key pair (or provably related key pairs) across multiple VID systems.

Mechanism:
The same cryptographic key is reused—or a provable link between key pairs is established—to sign assertions, metadata, or artifacts in multiple identifier contexts (e.g., DID Documents, DNS TLSA records, X.509 certificates).

Implementation Considerations:

• The private key material must remain secure and never be exposed across lower-assurance environments.

• Key rotation policies must be carefully coordinated across systems to maintain valid linkages.

• Algorithms and key formats must be compatible or translatable across ecosystems (e.g., JWK, DER, PEM).

4.1.2 Non-Cryptographic Bridge

Purpose:
To provide a human- and machine-readable reference that creates a verifiable association between identifiers, typically in both directions.

Mechanism:
Each identifier system must support structured metadata or fields for storing references to other identifiers. Examples include:

• DID Documents referencing DNS domains via dnsValidationDomain,

• X.509 certificates including DIDs in the Subject Alternative Name,

• DNS publishing URI records pointing to a DID.

Implementation Considerations:

• Metadata must be persistently and reliably hosted, ideally in tamper-resistant or integrity-protected formats (e.g., DNSSEC, DID method-specific proofs).

• Access control policies should govern who can write or update these references to avoid unauthorized modifications.

• Governance models should address how references are verified, revoked, or updated over time.

By standardizing how both cryptographic and non-cryptographic bridges are established and verified, this specification lays the groundwork for a scalable model of identity interoperability. These bridges enhance assurance without forcing convergence onto a single identifier format or trust model.

This approach can be extended to accommodate additional VID types, new cryptographic techniques, or evolving trust requirements, enabling secure and meaningful connections between identifiers in increasingly complex digital ecosystems.

5. High Assurance Bridges

The following sections define the implementation guidelines for establishing High Assurance Bridges between three foundational Verifiable Identifier (VID) ecosystems:

• Decentralized Identifiers (DIDs) – W3C DID Core

• Domain Name System (DNS) – RFC 1035

• X.509 Certificates – RFC 5280

These ecosystems represent distinct models of identifier issuance, governance, and trust—but they can be linked using standardized bridging patterns that combine cryptographic control and referential integrity.

The following subsections describe how to construct High Assurance Bridges originating from each VID type. For each pairing, both directional bridges (e.g., DID to DNS and DNS to DID) are covered, along with the technical mechanisms, validation steps, and contextual considerations needed to ensure a secure, verifiable connection.

Together, these bridges provide a practical pathway toward interoperable, high-confidence identity infrastructure that spans legacy PKI, internet-native namespaces, and decentralized identity frameworks.

6. Bridging DIDs and X.509

Both X.509 certificates and Decentralized Identifiers (DIDs) represent public/private key pairs and are defined by structured metadata that enables identity binding and verification. Despite these commonalities, there are fundamental differences in how these systems operate—particularly in their trust models, governance structures, and deployment contexts.

Key Structural Differences

• X.509 Certificates operate within a hierarchical trust model, where certificates are issued by trusted Certificate Authorities (CAs) that vouch for the identity and attributes of the subject. Certificate lifecycle operations—such as issuance, renewal, and revocation—are typically mediated through the CA. While self-signed certificates are possible, they are rarely used in production due to the absence of external trust anchors.

• DIDs, by contrast, generally follow a non-intermediated control model. The entity that controls the private key also manages the identifier directly. While some DID methods may support hierarchical governance, the default model is one in which the subject independently creates and maintains their identifier without centralized issuance or attestation.

Bridging Considerations

This specification defines not only the technical mechanisms for bridging X.509 certificates and DIDs—such as shared key material or mutual referencing—but also acknowledges the governance implications of doing so. Establishing such a bridge allows the two systems to interoperate, but implementers must consider how authority, trust delegation, and control are interpreted differently within each system.

Understanding these structural and governance mismatches is critical when designing systems that rely on both X.509 and DID-based identity frameworks. A well-formed bridge must account not only for technical compatibility but also for differences in lifecycle management, trust assumptions, and operational authority.

6.1 Identity Relationship Anchor (Non-Cryptographic Bridge)

6.1.1 DID to X.509

A DID to X.509 bridge is established by including a reference to an X.509 certificate within a verificationMethod in the DID Document. This creates a non-cryptographic linkage that allows verifiers to associate the public key in the DID with the same key material presented in an X.509 certificate.

To ensure interoperability and conformance with existing cryptographic standards:

• The verificationMethod MUST be of type "JsonWebKey2020" (or a compatible type supporting JWK representation).

• The public key MUST be expressed using the publicKeyJwk property.

• The corresponding X.509 certificate MUST be included via one of the following JWK parameters:

  • x5u – a URI pointing to a retrievable resource containing the X.509 certificate or certificate chain.

  • x5c – an array of base64-encoded DER certificates, representing either a standalone certificate or a complete certificate chain.

This structure allows verifiers to retrieve and inspect the certificate, confirm alignment with the public key in the DID, and apply any additional validation (e.g., issuer trust, certificate expiration, LEI presence).

Example DIDs which have x509 Certificates in their DID documents:

6.1.2 X.509 to DID

A pointer from an X.509 certificate to a Verifiable Identifier (VID) of type DID SHOULD be established by including the DID as a uniformResourceIdentifier within the certificate’s Subject Alternative Name (SAN) extension.

The SAN extension is a standard mechanism in X.509 certificates for associating additional identity information with the subject, including domain names, IP addresses, and URIs. By leveraging this existing extension, a DID can be embedded directly in the certificate without requiring any changes to the X.509 specification or validation infrastructure.

Example:

This creates a non-cryptographic bridge, allowing verifiers to extract and follow the DID reference from the certificate. When used in combination with cryptographic mechanisms (e.g., key correlation between the X.509 certificate and the DID document), a strong linkage can be established.

To conform with this specification, the DID must:

• Appear as a URI in the SAN extension.

• Follow the syntax rules of the relevant DID method.

• Be the only DID in the SAN, or clearly identifiable if multiple URIs are present.

This pattern enables standardized, machine-readable linkage from X.509 certificates to DIDs using existing and widely supported certificate fields

6.2 Cross-Domain Trust Anchor (Cryptographic Bridge)

A cryptographic bridge between an X.509 certificate and a DID is established not through explicit referencing, but through cryptographic proof that the same key material is controlled across both identifiers.

Unlike non-cryptographic methods (e.g., mutual referential anchoring), the cryptographic bridge relies on the inclusion of the X.509 certificate's public key—or an equivalent public key—in a verificationMethod within the DID Document. This mirrors the traditional role of X.509 certificates in protocols like TLS, where trust is derived from demonstrated control over the private key.

To verify the cryptographic bridge, a relying party MUST be able to confirm that the subject in control of the DID is also in possession of the private key corresponding to the X.509 certificate. This proof can be demonstrated through one of the following approaches:

• Challenge-Response: A verifier issues a challenge (e.g., a nonce or timestamped message) which is signed using the private key associated with the X.509 certificate. The verifier then uses the corresponding public key—referenced via the DID’s verificationMethod—to verify the signature.

• Signature over Known Message: A predefined message (e.g., a canonical string or identifier) is signed with the private key. The signature is then verifiable using the public key from the X.509 certificate, which can be compared against the key material present in the DID Document.

• Protocol-Based Proofs: Other protocol-specific methods (e.g., mutual TLS, ACME challenges, or DIDComm authentication) MAY be used, provided they establish proof of possession of the same private key material and are mutually verifiable across both the X.509 and DID representations.

Open

Figure 2: DID to X.509 Certificate bridge

This cryptographic binding ensures that even in the absence of mutual references, a verifier can establish high assurance that the entities behind the X.509 certificate and the DID are cryptographically linked.

7. Bridging DIDs and DNS

DIDs and DNS represent fundamentally different models for digital identification. DIDs are cryptographically verifiable identifiers designed for flexible, controller-managed use, while DNS provides globally recognized, human-readable identifiers backed by a hierarchical trust infrastructure.

Bridging these systems enables identifiers to combine the cryptographic assurances of DIDs with the global discoverability and semantic clarity of DNS domains. A high-assurance bridge—whether cryptographic, referential, or both—allows a DID to be linked to a DNS domain in a verifiable way, and vice versa.

As defined in High Assurance DIDs with DNS, these bridging methods enhance interoperability, enabling verifiers to trace control across systems and rely on multiple layers of assurance without requiring trust model convergence.

Open

Figure 3: DID to DNS bridge

Such a bridge enables:

• Robust Verification: DIDs can be anchored to DNS records, allowing verifiers to confirm that control of a DID and a domain name rests with the same entity.

• Semantic Context: Human-readable DNS names provide context and recognizability for otherwise opaque DID strings.

• Improved Trust Establishment: Applications can leverage the DNS as a discovery or trust mechanism, while maintaining the verifiability and auditability of cryptographic proofs offered by DIDs.

This dual anchoring simplifies trust workflows across systems where both human-recognizable and cryptographically secure identifiers are needed.

7.1 Identity Relationship Anchor

7.1.1 DID to DNS

The method for linking a DID to a DNS domain depends on the type of DID method used. This linkage creates a non-cryptographic bridge by embedding a DNS reference within the DID Document or, in the case of certain methods, within the DID itself.

Web-Based DIDs

For did:web identifiers, the association to a DNS domain is inherent in the DID itself. The DID syntax directly encodes the domain name used to resolve the DID Document, establishing a unidirectional reference from the DID to the domain.

Example

Non-Web-Based DIDs

For all other DID methods, a DNS reference can be established using the dnsValidationDomain property defined in the DID Extensions specification and formalized in the High Assurance DIDs with DNS draft. This property explicitly declares the associated DNS domain within the DID Document.

Example

Summary

7.1.2 DNS to DID 

A DNS-to-DID pointer establishes a non-cryptographic bridge from a DNS domain to a DID by publishing a URI record in the domain's DNS zone. This mechanism allows resolvers to discover a DID associated with a domain using standard DNS queries.

The recommended format is defined in High Assurance DIDs with DNS, and originally proposed in DID Method Discovery using DNS.

Format

A DNS URI resource record is published at a well-known subdomain, typically prefixed with _did.. The record value contains the associated DID.

Example DNS record:

In this example:

• _did.example.ca is the query name.

• URI is the record type.

• "did:web:example.ca" is the associated DID.

Resolution Behavior

A resolver can perform a DNS query for a URI record at _did.<domain> to retrieve the corresponding DID.

Summary

7.2 Cross-Domain Trust Anchor

A cryptographic bridge between a DID and a DNS domain is established by demonstrating mutual control over a shared public–private key pair. This linkage allows verifiers to confirm that both the DID and the DNS domain are operated by the same entity through cryptographically verifiable means.

The bridge is formed by:

• Publishing the public key in the DID Document via a verificationMethod.

• Publishing a corresponding TLSA record in DNS, as defined in Section 3.4 of High Assurance DIDs with DNS, which binds the DNS domain to the same public key.

This allows a verifier to confirm that both the DID and the domain reference the same key, thereby establishing a strong cryptographic linkage.

Key Differences from DID–X.509 Bridging

Unlike an X.509 certificate (which is a static, signed artifact), both DIDs and DNS zones are dynamic in nature. Therefore, the cryptographic integrity of each side must be independently verifiable over time.

• DNS Integrity: Ensured via DNSSEC, which enables cryptographic signing of DNS records, including TLSA records.

• DID Integrity: In some cases MAY be ensured via a dataIntegrityProof embedded in the DID Document, in addition to any trust or update mechanisms inherent to the specific DID method.

By combining these integrity guarantees with key possession proofs, this bridge provides a resilient and verifiable trust anchor across DNS and DID systems.

8. X.509 and DNS

The majority of X.509 certificates in use today are domain-validated (DV) certificates, issued for securing HTTPS communication over the web. These certificates bind a public key to a specific DNS domain name, enabling clients (e.g., web browsers) to authenticate the identity of a server and establish encrypted TLS connections.

Open

Figure 4: X.509 to DNS bridge

In this context, the X.509 certificate functions as a cryptographic assertion that a particular domain is controlled by the entity presenting the certificate. This is validated through a certificate authority (CA), which confirms domain ownership—typically via DNS-based or HTTP-based challenges—before issuing the certificate.

The tight coupling between X.509 certificates and DNS is foundational to internet security. It underpins the Web PKI (Public Key Infrastructure) model, ensuring that user traffic is both encrypted and directed to the correct destination by establishing trust in domain–certificate bindings.

8.1 Identity Relationship Anchor

8.1.1 X.509 to DNS

In early implementations of X.509 certificates, the Common Name (CN) field of the certificate’s subject distinguished name was used to represent the primary DNS domain—for example, www.example.com. This practice is defined in RFC 5280, Section 4.1.2.6.

However, current best practices—and in many environments, requirements—mandate the use of the Subject Alternative Name (SAN) extension to specify one or more fully qualified domain names. This approach is defined in RFC 6125, Section 6.4.4 and has become the standard for domain validation in X.509 certificates.

Summary of DNS Bindings in X.509

The SAN extension supports multiple domain entries, allowing a single certificate to be valid for several domain names (e.g., example.com, www.example.com, api.example.com), and forms the basis for domain validation in modern certificate issuance and verification processes.

8.1.2 DNS to X.509

In typical HTTPS deployments, DNS and X.509 certificates operate independently. When a client connects to a web server, it uses the Domain Name System (DNS) to resolve the server’s IP address, and then verifies the server’s identity using a CA-issued X.509 certificate. In this model, DNS serves purely as a locator, while trust in the server’s identity is derived from the certificate chain anchored in public Certificate Authorities (CAs), supported by mechanisms such as certificate transparency and revocation checking.

However, this default separation of roles can be bridged using DNS-Based Authentication of Named Entities (DANE)—a protocol defined in RFC 6698. DANE enables domain owners to assert their own X.509 certificates (or public keys) directly in DNS, using TLSA records. These records form a cryptographic bridge between the DNS and X.509 ecosystems by allowing verifiers to confirm that a domain name explicitly endorses a specific certificate or key.

How DANE Works

• A domain publishes TLSA records at a predictable DNS name based on service, port, and protocol (e.g., _443._tcp.example.com).

• These records specify:

  1. Whether they refer to the certificate or the key (selector),

  2. Whether they match on the full object or a hash (matching type),

  3. The value itself (certificate or hash thereof).

• The entire DNS zone must be protected with DNSSEC, ensuring authenticity and integrity of the TLSA data.

• When a client connects to a service, it:

  1. Retrieves the TLSA record,

  2. Verifies the DNSSEC signature chain,

  3. Compares the TLSA data against the certificate (or public key) presented during the TLS handshake.

Bridging Outcome

A successful match confirms that:

• The certificate presented over TLS corresponds to the key or certificate published in DNS, and

• The domain has cryptographically endorsed that certificate via DNSSEC.

This creates a bi-directional trust relationship:

• The X.509 certificate includes a DNS name (via the Subject Alternative Name field),

• The DNS record confirms the certificate (or key) is valid for that name.

Summary

While DANE is not widely deployed compared to CA-based PKI, it offers a valuable mechanism for cryptographically binding DNS and X.509 identifiers—enhancing trust without relying solely on external certificate authorities. In the context of High Assurance VIDs, DANE serves as the primary standard for establishing a cryptographic bridge from DNS to X.509, paralleling similar mechanisms used in DID-to-DNS binding.

8.2 Cross-Domain Trust Anchor

A cryptographic bridge between an X.509 certificate and a DNS domain is established by verifying that both refer to, and are controlled by, the same cryptographic key material. This bridge enables high-assurance binding between a domain name and the public key presented in an X.509 certificate—without relying solely on the traditional Certificate Authority (CA) model.

This is accomplished using DNS-based Authentication of Named Entities (DANE), which allows DNS to publish certificate-related assertions via TLSA records, as defined in RFC 6698 and secured via DNSSEC.

TLSA Record Structure

A TLSA record binds a domain name to a certificate (or public key) presented by a TLS server. It specifies:

• The certificate usage (e.g., end-entity or CA),

• The selector (e.g., full certificate or public key),

• The matching type (e.g., exact match or hash),

• And the value (the certificate or key, or a hash thereof).

Example TLSA Record (full certificate hash):

Binding Process

To establish a verifiable cryptographic bridge:

1. The domain publishes a TLSA record under a service-specific prefix (e.g., _443._tcp.example.com) containing the hash or raw data of the X.509 certificate or its public key.

2. The X.509 certificate is served via a TLS endpoint (e.g., HTTPS) on that same domain.

3. A verifier can:

   • Retrieve the X.509 certificate from the domain over TLS,

   • Retrieve the TLSA record from DNS,

   • Validate that the certificate matches the TLSA assertion, and

   • Verify the authenticity of the TLSA record via DNSSEC.

This cryptographic linkage proves that the domain owner not only controls the DNS zone (secured via DNSSEC), but also the key material presented in the X.509 certificate.

9. Resolution and Dereferencing process

This section outlines the process for resolving and dereferencing a High Assurance Verifiable Identifier (VID) by leveraging the cryptographic and non-cryptographic bridges described in this specification. The goal is to enable verifiers to reliably traverse between different VID types (e.g., DIDs, DNS, and X.509) and establish a high-assurance linkage between them.

9.1 Starting Point: Known Identifier

Resolution begins from one known VID—either a DID, DNS domain, or X.509 certificate—depending on the context. From this starting point, the verifier follows standardized bridging mechanisms to retrieve and validate associated identifiers.

9.2 Resolution Flows

9.2.1 DID to DNS and X.509

1. Dereference the DID Document using the appropriate DID resolver.

2. Inspect verificationMethod entries:

   • If a dnsValidationDomain property is present, extract the associated DNS domain.

   • If x5u or x5c parameters are included in a publicKeyJwk, extract the referenced X.509 certificate.

3. Optionally verify cryptographic linkage by:

   • Resolving DNSSEC-signed TLSA records from the domain (for DNS).

   • Matching key material between the DID and X.509 (for X.509).

   • Validating a challenge signature using the shared public key.

9.2.2 DNS to DID and X.509

1. Query for _did.<domain> URI record:

   • If present, retrieve the associated DID.

2. Query for _port._proto.<domain> TLSA record (e.g., _443._tcp.example.com):

   • If present, extract and hash the certificate or key, then compare it to the server's presented certificate.

3. Optionally resolve the DID to verify key equivalence with the certificate.

9.2.3 X.509 to DID and DNS

1. Inspect Subject Alternative Name (SAN):

   • Extract any DNS names or DID URIs.

2. Follow did:<method>:... in SAN (if present):

   • Resolve the DID to retrieve its verification methods and metadata.

3. Verify key alignment:

   • Compare the certificate’s public key with the DID's publicKeyJwk.

   • If the SAN contains a DNS name, query for _did. or TLSA records for linkage.

9.3 Establishing High Assurance

To establish a High Assurance VID, the resolver must confirm:

• Bidirectional reference, where possible (e.g., both DID ↔ DNS and DNS ↔ DID).

• Cryptographic continuity, demonstrated through key reuse and verifiable proofs (e.g., TLSA match or challenge-response).

• Integrity guarantees, ensured through DNSSEC for DNS records and, in some cases, dataIntegrityProof or DID method integrity for DID Documents.

9.4 Caching and Expiry Considerations

Resolvers should respect TTLs for DNS records and the expiration periods of X.509 certificates. DID Documents may also change over time; implementers are advised to define caching policies appropriate to their risk model.

10. Identifying the Real-World Organization Behind an Identifier

One of the core challenges in digital identity systems is determining who actually controls a given identifier. While cryptographic mechanisms can verify that someone holds a private key, they do not, by themselves, prove the real-world organizational identity of the controller.

High Assurance Verifiable Identifiers (VIDs) address this challenge by enabling different types of identifiers—such as DIDs, X.509 certificates, and DNS domains—to be linked and cross-verified. This layered approach allows verifiers to trace identifiers back to an authoritative, legally recognized organization using standardized metadata, including Legal Person Identifiers (LPIDs).

10.1 Bridging to Legal Identity Using DID, X.509, and DNS

Each identifier type contributes differently to establishing real-world organizational identity:

• X.509 Certificates may contain organizational attributes and can embed Legal Person Identifiers such as:

  • LEI (Legal Entity Identifier) in the subject:organizationalIdentifier field, as defined in ISO 17442-2.

  • Other LPID schemes such as VAT numbers, company registration numbers, or national business identifiers depending on jurisdiction and certificate profile.

• DIDs can reference an X.509 certificate in a verificationMethod, allowing a verifier to inherit and verify organizational claims from the certificate’s subject data or embedded LPID. DIDs may also point to information about a legal entity in one or multiple serviceEndpoints.

• DNS domains act as highly recognizable, resolvable identifiers that often align with organizational branding. When linked to a DID or certificate via URI or TLSA records, they serve as an anchor for broader context and trust. Additionally, DNS can directly publish LPIDs such as LEIs, using standardized record types.

10.2 Publishing LPIDs in DNS

Organizations can expose LPIDs—including LEIs—using standardized DNS mechanisms. For example, RFC 9108 defines a method for publishing LEIs in DNS using NAPTR records with a _lei. service prefix.

Example:

This allows verifiers to automatically discover an organization’s LEI from DNS and resolve authoritative metadata (e.g., legal name, registration jurisdiction, address) via the GLEIF API.

While LEIs are a globally governed identifier, other LPIDs may be published in similar ways depending on registry support, DNS schema extensions, or certificate formats.

10.3 End-to-End Resolution to a Legal Person

To identify the organization behind a VID, verifiers can follow this process:

1. Start from a known identifier (DID, DNS domain, or X.509 certificate).

2. Resolve linked identifiers via bridges:

   • Use SAN entries or dnsValidationDomain to connect DIDs and DNS.

   • Use x5u, x5c, or TLSA records to verify cryptographic alignment.

3. Extract LPIDs from:

   • The X.509 certificate subject or extensions (e.g., LEI).

   • DNS NAPTR records (_lei, _lpid, etc.), if available.

4. Query the appropriate registry (e.g., GLEIF for LEIs, national business registries for others) to retrieve verified organizational metadata.

By combining cryptographic verification with referential integrity and registry-based legal identifiers, High Assurance VIDs provide a robust path from abstract digital identifiers to concrete, legally accountable organizations. This enables use cases requiring regulatory compliance, organizational due diligence, or institutional-grade trust in digital interactions.

11. Applications of HAVIDs

High Assurance Verifiable Identifiers (HAVIDs) enable interoperable, cryptographically-verifiable identity linkages across diverse digital trust systems. By combining identifiers from distinct ecosystems—such as DNS, X.509 certificates, and DIDs—HAVIDs create a portable and trustworthy identity layer that supports a wide range of real-world applications.

This section outlines key domains and use cases where HAVIDs can provide clear security, usability, and governance benefits.

11.1 Secure Communication and Authentication

HAVIDs can enhance authentication protocols by linking a domain name, digital certificate, and DID under a single verifiable control structure.

• TLS / HTTPS verification: A website can prove control of both a DNS domain and a DID using X.509 bindings, making the identity behind a TLS session verifiable across multiple layers.

• Mutual TLS with DIDs: Server and client certificates can be bound to DIDs, supporting decentralized identity negotiation and attestation in secure channels.

11.2 Organizational Identity and Legal Entity Discovery

HAVIDs allow organizations to publish identifiers that can be reliably traced back to legally registered entities.

• LEI/LPID resolution: By embedding Legal Person Identifiers (e.g., LEIs) into DNS or certificates, HAVIDs help relying parties identify the actual organization behind a VID.

• Enterprise trust frameworks: HAVIDs can support enterprise-grade compliance and due diligence processes by establishing high-confidence identity bindings without relying on a single trust authority.

11.3 Verifiable Credential Ecosystems

In systems that issue or verify digital credentials, HAVIDs can enhance trust and traceability across participants.

• Issuer provenance: Credential issuers can bridge DIDs and X.509 certificates to prove that their DID is backed by a regulated organization.

• Selective trust in federated ecosystems: Verifiers can follow HAVID bridges to determine whether an issuer meets contextual assurance requirements (e.g., domain control, legal registration, cryptographic integrity).

11.4 Cross-Domain Service Discovery

HAVIDs support resolution of services, endpoints, and credentials across identifier ecosystems.

• Service endpoints in DID Documents can be cryptographically tied to a domain and secured by a valid TLS certificate, increasing trust in endpoint authenticity.

• DNS-based service discovery can include DID or certificate references, allowing decentralized identity resolution workflows to operate within existing DNS infrastructure.

11.5 Regulatory and Compliance Use Cases

HAVIDs provide a standardized foundation for regulated digital identity requirements.

• Financial compliance: Institutions can use HAVIDs to demonstrate linkages between regulatory identifiers (like LEIs), operational endpoints (e.g., domains), and cryptographic assertions (certificates, DIDs).

• eIDAS and trust services: Qualified trust service providers (QTSPs) can use HAVIDs to anchor their digital services in resolvable, high-assurance identifiers.

• Software supply chain integrity: Signing keys, publishing domains, and maintainer DIDs can be bridged, providing an auditable, high-assurance identity graph for software artifacts.

11.6 Human-Readable Trust Anchors for Decentralized Identity

Many decentralized systems rely on opaque identifiers (e.g., DIDs) that are difficult for users to interpret. HAVIDs help bridge these identifiers with globally recognized anchors.

• Trust signals for end-users: Linking a DID to a DNS domain and certificate allows end-users and UIs to associate DIDs with familiar names and entities.

• Identity transparency: Applications can display information derived from HAVID bridges (e.g., organization names, LEIs) to support informed user consent and interaction.

12. Security considerations

This section outlines the key security considerations when linking, resolving, and dereferencing High Assurance Verifiable Identifiers (VIDs) across systems such as DIDs, DNS, and X.509 certificates. The goal of High Assurance VID bridging is to strengthen trust through multiple layers of cryptographic and referential verification—but improper implementation or incomplete validation can introduce significant risks.

12.1 Trust Model Alignment

Bridging systems with distinct trust models—such as CA-based X.509, self-controlled DIDs, and DNS-based naming—introduces governance mismatches.

• Implementations SHOULD explicitly define the trust anchors used (e.g., root CAs, DNSSEC trust chains, DID method registries).

• Implementations SHOULD NOT assume equivalence in trust semantics across VID types without clear justification.

• Bridges that cross governance domains SHOULD provide guidance on trust assumptions and control boundaries.

12.2 Key Reuse and Equivalence

Many cryptographic bridges rely on the same key material being used across identifiers.

• Verifiers MUST ensure that public keys are identical across representations, not merely compatible (e.g., same curve but different keys).

• When using TLSA records or verificationMethod entries with x5c/x5u, verifiers MUST validate the key or certificate against the expected format and fingerprint.

• Entities SHOULD rotate keys periodically and update all bridged identifiers accordingly to prevent key reuse over long periods.

12.3 Replay and Downgrade Protection

Mutable data such as DID Documents, DNS records, and certificate chains are susceptible to replay and downgrade attacks.

• Implementations MUST resolve identifiers at the time of verification and MUST NOT rely on stale or cached versions unless properly validated.

• DID Documents SHOULD include versioning, timestamps, or dataIntegrityProof structures to support freshness verification.

• Resolvers SHOULD limit the trust window for unverifiable or unsigned data.

12.4 DNS Integrity

All DNS-based bridges (e.g., _did URI records, TLSA records) MUST be protected by DNSSEC.

• Verifiers MUST validate the full DNSSEC chain of trust for any DNS assertion.

• Implementers SHOULD treat unsigned or unverifiable DNS records as untrusted.

12.5 Certificate Validation

When referencing or resolving X.509 certificates:

• Verifiers MUST validate certificate chains using trusted root stores.

• Certificates MUST NOT be accepted if expired, revoked, or malformed.

• Self-signed certificates MAY be used only when explicitly permitted and when paired with out-of-band trust validation.

12.6 Loop and Malicious Binding Prevention

Bi-directional bridges and reference chaining can create circular dependencies or be used to escalate trust maliciously.

• Resolvers MUST limit the maximum reference depth to prevent infinite resolution loops.

• Each reference in a chain MUST be validated independently; transitive trust MUST NOT be assumed by default.

• Implementations SHOULD log and rate-limit resolution attempts to detect and mitigate abuse.

13. Governance considerations

Bridging identifiers across systems with differing governance models—such as the hierarchical model of CAs and the more flexible governance of DIDs—requires clearly defined policies and responsibilities to preserve assurance and trust.

13.1 Certificate Policy Requirements for Certificate Authorities Resolving and Verifying DIDs

When a Certificate Authority (CA) issues an X.509 certificate that references a Decentralized Identifier (DID), the following governance and operational requirements apply:

MUST Requirements

• A CA MUST resolve the DID using a conformant DID resolver prior to issuing a certificate that includes the DID (e.g., in the Subject Alternative Name extension).

• A CA MUST retrieve the corresponding DID Document and extract the verificationMethod entries.

• A CA MUST validate that the public key contained in the Certificate Signing Request (CSR) exactly matches a public key controlled by the DID, either by:

  • Matching the key material directly with a publicKeyJwk entry; or

  • Verifying a challenge-response proof of key possession against the DID's verificationMethod.

• A CA MUST record the resolution and validation steps as part of its issuance audit log, consistent with its certificate policy.

SHOULD Recommendations

• A CA SHOULD treat DID resolution failures, unresolved keys, or unverifiable key proofs as grounds to reject the CSR.

• A CA SHOULD establish an automated process for resolving DIDs and validating key material.

• A CA SHOULD include a timestamp or version of the DID Document in issuance metadata, if available, to support post-issuance auditability.

13.2 Hierarchically-Governed Bridges

In certain models, the CA may also act as the controller or authoritative manager of the DID. In these cases:

• The CA MAY create the DID on behalf of the subject during the certificate issuance process.

• The CA MAY maintain operational control or delegated authority over the DID Document (e.g., via controller or alsoKnownAs fields, or a verification relationship (e.g. capabilityInvocation)).

• In such a configuration, the DID–X.509 binding becomes part of a hierarchically-governed trust anchor, and the certificate policy MUST reflect this dual role.

See an example of this relationship in the diagram below:

Open

Figure 5: DID to X.509 bridge (with hierarchical governance)

13.3 Lifecycle Operations and Ongoing Governance

Bridging DIDs and X.509 certificates introduces new responsibilities across the certificate lifecycle:

• Rekeying: If a certificate is rekeyed, the CA SHOULD ensure that the new public key is either added to the DID Document or replaces the old key in a way that preserves continuity of control.

• Revocation: If a certificate is revoked due to key compromise or change in control, the associated DID Document SHOULD also be updated to remove or revoke trust in the affected key.

• Expiration: A certificate’s expiration DOES NOT automatically imply the invalidation of the DID. Implementers SHOULD treat these as separate but interlinked lifecycles.

13.4 Certificate Policy and Profile Guidance

CAs participating in High Assurance VID bridging SHOULD update their Certificate Policies (CP) and Certification Practice Statements (CPS) to:

• Define procedures for resolving and verifying DIDs.

• Specify the validation criteria for DID-linked key material.

• Include requirements for synchronization of DID and certificate lifecycles.

• Document the trust assumptions related to DID methods in scope.

By aligning certificate governance with DID resolution and validation procedures, CAs and relying parties can establish interoperable and verifiable trust anchors across systems, supporting strong assurance for multi-identifier environments.

14. Privacy considerations

Implementers and issuers SHOULD carefully consider the following privacy risks and mitigation strategies.

14.1 Linkability Across Contexts

When DIDs, DNS domains, and X.509 certificates are linked together, they may expose relationships between identifiers that were originally intended to remain separate.

• Publishing a DID in a DNS record (e.g., _did.example.com) or an X.509 SAN field MAY allow external observers to correlate the DID with a specific organization, server, or personal identifier.

• Bridging identifiers across trust domains MAY allow third parties to aggregate identity data unless properly isolated.

Mitigation:

• Use pseudonymous DIDs where feasible to prevent unintentional correlation.

• Avoid unnecessary or redundant bridges unless they serve a clear operational purpose.

• Bridges that include DIDs SHOULD be used primarily for legal entities.

• SHOULD NOT publish personally identifiable DIDs in globally indexed or crawlable DNS records.

14.2 DID and Certificate Revocation Metadata

Tracking revocations of certificates or DIDs may create indirect privacy risks by revealing usage patterns or control changes over time.

• Observers MAY infer rekeying, compromise, or organizational changes based on updates to DID Documents or certificate status.

• Publication of revocation status in CRLs, OCSP, or DID resolution endpoints MAY leak temporal metadata.

Mitigation:

• Where possible, use aggregated revocation mechanisms (e.g., OCSP stapling) to reduce traceability.

• Update DIDs using non-revealing metadata structures to minimize information leakage about the reason or timing of changes.

14.3 Regulatory Compliance

Linking and exposing identifiers may have implications under data protection laws (e.g., GDPR, CCPA) when identifiers can be traced back to natural persons.

• Entities that operate DID resolvers, DNS zones, or CAs SHOULD assess whether any published identifier constitutes personal data.

• Systems MUST provide a clear privacy policy and data handling procedures if personal information is published or resolvable.

References

Normative References

[RFC2119]

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels

Informative References

[DID-CORE]

Manu Sporny; et al. Decentralized Identifiers (DIDs) v1.0. URL: Decentralized Identifiers (DIDs) v1.1

[RFC8174]

B. Leiba. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. May 2017. Best Current Practice. URL: RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

High Assurance DIDs with DNS

Originally defined in: The Decentralized Identifier (DID) in the DNS