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).