Version: Draft 05
Authors: Alex Tweeddale, Jesse Carter
Contributors: Markus Sabadello, Scott Perry, Drummond Reed, Tim Bouma

Table of Contents

1. Abstract

The digital identity landscape comprises multiple Verifiable Identifier (VID) types, including X.509 certificates, Decentralized Identifiers (DIDs), and DNS records. Each serves a distinct purpose. X.509 certificates bind public keys to domain names under Certificate Authority governance. DIDs provide controller-managed cryptographic key control. DNS offers globally recognizable, human-readable naming and discoverability. These systems will continue to coexist, yet no widely adopted method exists for establishing verifiable relationships between them.

This specification defines cross-endorsement: the practice of having identifiers in different ecosystems explicitly and verifiably reference one another to establish that they are controlled by the same entity. Cross-endorsement enables a composite trust picture in which each identifier contributes the assurance it is best suited to provide, without collapsing the distinct governance, lifecycle, and security properties of each system.

Implementers MAY additionally establish key alignment, demonstrating the same or verifiably linked cryptographic key material across identifiers, as a supplementary assurance mechanism. Key alignment carries significant risks and is subject to strict normative requirements defined herein.

Together, cross-endorsement and (optionally) key alignment allow a VID to participate in a High Assurance Verifiable Identifier (HAVID): a composite identity structure in which multiple identifiers, each operating under its native trust model, are linked through verifiable mutual references and (where warranted) cryptographic proof.

This specification defines a linking mechanism, not a trust framework. The trust semantics of each identifier remain governed by their native frameworks (Web PKI, DNSSEC, DID method specifications, eIDAS, GLEIF, etc.). A HAVID complements these frameworks by enabling verifiable cross-referencing between them. It does not substitute for them.

2. Status of This Document

This section is non-normative.

3. Goals and Motivation

This section is non-normative.

3.1. Motivation

Today, a digital wallet holding a DID has no standardized way to prove that the DID belongs to a specific legal entity. A Certificate Authority that wants to include a DID in an X.509 certificate has no defined procedure for validating DID control. A DNS domain can serve as a globally recognizable anchor for an organization, but provides no cryptographic identity binding beyond TLS. Each of these gaps exists because the identifier systems involved were designed independently, and no common mechanism exists for establishing verifiable, machine-readable relationships between them.

Without such a mechanism, relying parties are forced to treat each identifier in isolation, forgoing the composite assurance that comes from knowing that a DID, a domain, and a certificate are all controlled by the same organization. This specification addresses that gap by defining cross-endorsement as a standard bridging pattern, giving implementers a concrete, auditable way to link identifiers across ecosystems without requiring any single system to become authoritative over the others.

3.2. Goals

This specification has two goals:

• Goal 1: Asserting legal and organizational identity for identifiers. By linking identifiers across ecosystems, relying parties can trace an abstract digital identifier (such as a DID or domain name) to a legally recognized organization through standardized metadata, including organizational identifiers such as LEIs.

• Goal 2: Creating common patterns for cross-endorsement of identifiers controlled by the same entity. This specification defines how identifiers in different ecosystems can verifiably reference one another, establishing that the same entity controls them and enabling composite assurance without requiring convergence on a single identifier format or trust model.

These goals are intentionally scoped. This specification does not seek to unify the governance models of different identifier ecosystems, nor does it prescribe which identifier type is authoritative. It provides a framework for enabling trust to flow between systems in a verifiable, auditable, and safe manner.

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

4.1. Conformance Classes

This specification defines requirements for three conformance classes. An implementation MAY conform to more than one class.

5. Terminology

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

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

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

X.509 Certificate: As defined in [RFC 5280].

DNS Domain Name: A globally unique and hierarchical identifier assigned through the Domain Name System, as defined in [RFC 1035].

DNSSEC: DNS Security Extensions, 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, as defined in [RFC 6698].

Legal Entity Identifier (LEI): A globally unique identifier for legal persons, defined in ISO 17442 and administered by GLEIF.

Organizational Identifier: A broader category of identifiers for legal entities, including LEIs, VAT numbers, company registration numbers, and national business identifiers.

Verification Method: As defined in [DID-CORE], a data structure in a DID Document describing a mechanism for proving control of a DID.

Verifiable Identifier (VID): A digital identifier whose control can be verified through cryptographic or integrity-protected mechanisms. In this specification, VIDs include DIDs, X.509 certificates, and DNS domain names (when integrity-protected).

Cross-Endorsement: A verifiable, bi-directional linkage between identifiers established through explicit mutual references in each identifier's native metadata or record format. Cross-endorsement is the primary bridging mechanism defined in this specification.

Key Alignment: A supplementary assurance mechanism in which the same or verifiably linked cryptographic key material is demonstrated across multiple identifiers. Key alignment is OPTIONAL and subject to the normative requirements of Section 10.

High Assurance Verifiable Identifier (HAVID): A composite identity structure formed by linking two or more Verifiable Identifiers through cross-endorsement (and optionally key alignment), enabling strong, cross-system assurance of identity control and integrity.

6. Identifier Role Taxonomy

This section is non-normative.

Each identifier type contributes a specific kind of assurance. Cross-endorsements compose these assurances; they do not transfer or replicate them.

6.1. DNS: Naming and Discoverability

DNS provides globally unique, human-readable names resolvable across the internet:

• Human recognizability. Domain names are meaningful to end users and correspond to organizational branding.

• Global discoverability. DNS is the universal resolution layer of the internet.

• Integrity (when DNSSEC is deployed). Cryptographic assurance of record authenticity and integrity.

DNS does not, by itself, prove who controls a domain in any legally meaningful sense.

6.2. X.509 Certificates: Domain Ownership via PKI

X.509 certificates operate within a hierarchical trust model governed by Certificate Authorities:

• Domain ownership attestation. A CA validates that the certificate subject controls the domain.

• Organizational identity (for OV/EV certificates). Higher-assurance certificate profiles may include verified organizational metadata such as legal name, jurisdiction, and LEI.

• TLS integration. X.509 certificates are the standard mechanism for securing HTTPS and other TLS-based communications.

X.509 certificates are time-bounded artifacts with defined cryptoperiods, issued, renewed, and revoked under CA governance.

6.3. DIDs: Cryptographic Key Control

DIDs follow a controller-managed model:

• Key control. DIDs prove that an entity controls one or more cryptographic keys, without requiring CA intermediation.

• Programmable identity. DID Documents can express verification methods, service endpoints, and delegation structures.

• Portability. DIDs can be managed independently of any single service provider or domain registrar.

DIDs do not inherently prove domain ownership or organizational identity.

6.4. Compositional Principle

Identifier Controllers SHOULD design cross-endorsements that leverage each identifier's native strengths. Identifier Controllers SHOULD NOT use cross-endorsement to imply an assurance that is native to another identifier type. A DID cross-endorsed with an X.509 certificate does not inherit CA-attested domain ownership; that assurance belongs to the certificate. An X.509 certificate cross-endorsed with a DID does not inherit the DID's programmable key management; that assurance belongs to the DID.

6.5. did:web and Circular Trust

The did:web method resolves DID Documents by fetching them from a web server at a domain encoded in the DID itself. The domain owner controls the DID Document. As a consequence, a cross-endorsement between a did:web identifier and its own host domain is circular: the DID already depends on the domain for its integrity, so the cross-endorsement does not introduce an independent trust anchor.

Identifier Controllers and Verifiers MUST observe the following:

(a) A did:web-to-own-host-domain cross-endorsement provides discoverability and structural linkage only. Verifiers MUST NOT treat it as providing independent assurance equivalent to a cross-endorsement involving an independently-anchored DID.

(b) For independent assurance, the DID method used SHOULD have integrity properties that do not depend solely on the DNS domain (e.g., did:webvh, did:webs, ledger-based methods, or methods with independent verifiable history).

(c) Verifiers MUST consider the DID method's trust properties when assessing the overall assurance level of a HAVID. A HAVID built entirely on did:web and its host domain carries strictly lower assurance than one built on a DID method with independent integrity.

6.6. Cardinality

A single identifier MAY participate in cross-endorsements with multiple identifiers of the same or different types.

When an identifier participates in multiple cross-endorsements:

(a) Each cross-endorsement MUST be independently verifiable.

(b) Verifiers MUST NOT infer transitive trust across cross-endorsements. If a DID is cross-endorsed with Domain X and Domain X is cross-endorsed with Certificate Y, the Verifier MUST NOT treat the DID as cross-endorsed with Certificate Y unless a direct, independently verifiable cross-endorsement exists between them.

(c) Identifier Controllers SHOULD limit active cross-endorsements to those serving a clear operational purpose.

7. Architecture Overview

This section is non-normative.

This specification defines a compositional architecture for establishing high-assurance linkages between VID types. The architecture rests on two mechanisms:

1. Cross-endorsement (primary) creates explicit, machine-readable, bi-directional references between identifiers. Each identifier points to the other using fields and record types native to its own ecosystem. Cross-endorsement provides discoverability, declared intent, and verifiable integrity.

2. Key alignment (supplementary, optional) provides additional proof of common control by demonstrating possession of the same or verifiably linked key material across systems. Key alignment increases assurance but introduces lifecycle mismatch risk, lowest-common-denominator security reduction, governance role collapse, and increased attack surface. It is OPTIONAL and subject to strict normative requirements.

7.1. Relationship to Existing Trust Frameworks

This specification does not define, replace, or modify the trust frameworks that govern individual identifier types. Web PKI continues to govern X.509 certificates. DNSSEC continues to govern DNS record integrity. DID method specifications continue to govern DID operations. Regulatory frameworks (eIDAS, national digital identity schemes) continue to govern legal recognition. GLEIF continues to govern LEI issuance.

A HAVID does not elevate an identifier's trust level beyond what its native framework provides. A DID cross-endorsed with a qualified eIDAS certificate does not itself become a qualified identifier. However, a Verifier can follow the cross-endorsement to discover and validate the qualified certificate, and can compose the assurances of both identifiers in its trust decision.

8. Threat Model

This section is non-normative.

This section identifies the principal adversaries, attack goals, and mitigations relevant to HAVID deployments. Implementers SHOULD use this model to inform their risk assessments.

8.1. Adversaries

8.2. Attack Goals and Mitigations

Fabricated cross-endorsement. An attacker creates a unidirectional reference from an identifier they control to an identifier they do not, making it appear that the two are linked. Mitigation: Bi-directional cross-endorsement requirement (Section 9) ensures both sides must assert the link. Verifiers MUST confirm both directions.

Stale key exploitation. An attacker obtains a compromised key that remains valid in one system (e.g., a DID Document) after it has been rotated in another (e.g., an X.509 certificate). Mitigation: Coordinated key rotation requirements (Section 10.2) and shortest-cryptoperiod rule.

Trust escalation via transitive inference. An attacker chains cross-endorsements to imply a relationship that was never directly asserted. Mitigation: The no-transitivity rule (Section 6.6) and maximum reference depth limits (Section 19.6).

DNS record manipulation. An attacker modifies _did URI or TLSA records to point to attacker-controlled identifiers. Mitigation: DNSSEC requirement for DNS-based cross-endorsements (Section 19.4). See also Section 11.4 for deployment pragmatics.

Rogue certificate issuance. A CA issues a certificate containing a DID URI in the SAN without verifying control of the DID. Mitigation: CA validation requirements (Section 20.1).

Correlation and linkability. An observer uses publicly visible cross-endorsement records to correlate identities across contexts. Mitigation: Privacy guidance (Section 21), encrypted DNS, and limiting cross-endorsements to those serving a clear operational purpose.

9. Cross-Endorsement

This section is normative.

Cross-endorsement is the primary mechanism for linking VID types. It is established through explicit, bi-directional references between identifiers, using fields and record types native to each identifier's ecosystem.

9.1. Requirements for Identifier Controllers

To establish a cross-endorsement between two identifiers, an Identifier Controller:

(a) MUST include an explicit reference to each identifier within the other's native metadata or record format, using the mechanisms defined in Sections 11 through 13 for each identifier pairing.

(b) MUST ensure that references are persistently and reliably hosted for the duration of the cross-endorsement.

(c) MUST store references in integrity-protected formats where available. For DNS records, this means DNSSEC (see Section 11.4 for deployment guidance). For X.509 certificates, this means CA-signed extensions. For DID Documents, this means the integrity mechanisms provided by the DID method.

(d) SHOULD implement access control policies governing who can write or update references.

(e) SHOULD define governance procedures for how references are verified, updated, and revoked over time.

9.2. Requirements for Verifiers

To verify a cross-endorsement, a Verifier:

(a) MUST resolve both identifiers using their native resolution mechanisms.

(b) MUST confirm that each identifier contains a reference to the other (bi-directional cross-endorsement).

(c) MUST validate the integrity of each reference (DNSSEC validation, certificate chain validation, DID method integrity).

(d) MUST check the current validity of each identifier (not expired, not revoked, not deactivated).

For handling partial or failed validation states, see Section 15.

9.3. Lifecycle

Cross-endorsements are subject to the lifecycle of each participating identifier:

(a) If an identifier is revoked, expired, or deactivated, the cross-endorsement MUST be treated as invalid by Verifiers.

(b) When an identifier is updated (e.g., a certificate is renewed or a DID Document is modified), the Identifier Controller MUST preserve or re-establish cross-endorsement references.

(c) Verifiers SHOULD define re-validation intervals appropriate to their risk model.

10. Key Alignment

This section is normative.

Key alignment is an OPTIONAL, supplementary mechanism that provides additional proof of common control by demonstrating that the same or verifiably linked cryptographic key material is present across multiple identifiers.

10.1. When Key Alignment is Appropriate

An Identifier Controller MAY establish key alignment when all of the following conditions are met:

(a) The participating identifier systems share compatible cryptographic formats and algorithms.

(b) The key rotation schedules and cryptoperiods are compatible or can be explicitly coordinated.

(c) The Identifier Controller has assessed and accepted the risks described in Section 7 and the threat model in Section 8.

An Identifier Controller SHOULD NOT establish key alignment when:

(a) The participating systems have significantly different cryptoperiods (e.g., short-lived TLS certificates and long-lived DIDs) and the Identifier Controller cannot commit to synchronized key rotation.

(b) Using the same key would collapse governance boundaries or operational roles that should remain distinct.

(c) Cross-endorsement alone provides sufficient assurance for the intended use case.

10.2. Requirements for Identifier Controllers

When key alignment is implemented, the Identifier Controller:

(a) MUST ensure the key material is identical across all representations. This means byte-for-byte equivalence of public key material after normalization to a common encoding. Keys that are merely compatible (e.g., same curve but different keys) do not satisfy this requirement.

(b) MUST coordinate key rotation across all systems in which the key is used. When a key is rotated in any one system, it MUST be rotated in all systems, or the key alignment MUST be explicitly dissolved.

(c) MUST treat the effective cryptoperiod of the shared key as the shortest cryptoperiod among all participating systems.

(d) MUST document which systems share key material and maintain an auditable record of key alignment relationships.

(e) SHOULD monitor for key compromise indicators across all participating systems.

10.3. Requirements for Verifiers

To verify key alignment, a Verifier:

(a) MUST extract the public key from each identifier (DID Document verificationMethod, X.509 certificate subject public key, or DNS TLSA record).

(b) MUST confirm that the keys are identical by byte-for-byte comparison after normalization.

(c) MUST verify that the key is currently valid in all participating systems, not just one.

(d) MAY request proof of possession (see Section 10.4).

10.4. Proof of Possession

Where key alignment is used, Verifiers MAY request proof of possession through:

Challenge-Response. The Verifier issues a nonce or timestamped challenge. The entity signs it using the private key. The Verifier confirms the signature against the public key as represented in each identifier system.

Protocol-Based Proofs. Mutual TLS, ACME challenges, DIDComm authentication, or other protocol-specific methods MAY be used, provided they establish proof of possession and are verifiable across the relevant identifier representations.

10.5. Failure Scenario: Key Alignment Without Lifecycle Coordination

This section is non-normative.

Consider an organization that uses the same RSA key pair in both a DID Document and a Let's Encrypt TLS certificate for org.example.com. The certificate has a 90-day validity period. After 90 days, the certificate expires and is renewed with a new key pair, as is recommended practice.

At this point the DID Document still contains the old public key while the TLS certificate contains a new one. A Verifier checking key alignment will find a mismatch. If the old key is later compromised, an attacker could present the DID Document's stale key as valid, since the DID has not been updated.

This scenario illustrates why key alignment MUST be accompanied by coordinated rotation (Section 10.2(b)) and why the effective cryptoperiod MUST track the shortest-lived system (Section 10.2(c)). When these requirements cannot be met, cross-endorsement without key alignment is the safer choice.

11. Bridging DIDs and DNS

This section is normative.

DIDs and DNS represent fundamentally different identification models. Cross-endorsement between these systems combines the cryptographic assurances of DIDs with the global discoverability of DNS domains. These mechanisms are defined in [High Assurance DIDs with DNS].

11.1. Cross-Endorsement: DID to DNS

The method for establishing a DID-to-DNS reference depends on the DID method.

11.1.1. Web-Based DIDs

For did:web identifiers, the association to a DNS domain is inherent in the DID syntax, which encodes the domain used to resolve the DID Document.

Example:

See Section 6.5 for the trust implications of this inherent dependency.

11.1.2. Non-Web-Based DIDs

For DID methods other than did:web, the Identifier Controller MUST establish a DNS reference using the dnsValidationDomain property defined in [DID Extensions] and formalized in [High Assurance DIDs with DNS].

Example:

11.1.3. Summary

11.2. Cross-Endorsement: DNS to DID

To complete the cross-endorsement from the DNS side, the Identifier Controller MUST publish a URI record in the domain's DNS zone at the _did. subdomain prefix. This mechanism is defined in [High Assurance DIDs with DNS], originally proposed in [DID Method Discovery using DNS].

Example DNS record:

The DNS zone containing the URI record MUST be integrity-protected (see Section 11.4).

11.3. Key Alignment: DID and DNS (Optional)

Where key alignment is desired between a DID and a DNS domain, it is established by:

(a) Publishing the public key in the DID Document via a verificationMethod.

(b) Publishing a corresponding TLSA record in DNS, as defined in Section 3.4 of [High Assurance DIDs with DNS], binding the domain to the same public key.

Both the DID Document and the DNS zone are mutable. Therefore:

• DNS integrity MUST be ensured via DNSSEC.

• DID integrity MAY be ensured via dataIntegrityProof, verifiable history logs (e.g., did:webvh, did:webs), or other method-specific integrity mechanisms.

All normative requirements of Section 10 apply.

11.4. DNSSEC Deployment Considerations

This section is non-normative.

This specification encourages integrity protection for DNS-based cross-endorsements. DNSSEC is the normative mechanism for achieving this. However, DNSSEC deployment remains uneven: some TLDs, registrars, and managed DNS providers offer limited or no DNSSEC support.

Identifier Controllers operating in environments where DNSSEC is not yet available SHOULD:

(a) Prioritize registrars and DNS providers that support DNSSEC signing and DS record publication.

(b) Document the absence of DNSSEC in their operational security assessment and treat the resulting HAVID as carrying reduced DNS-side integrity assurance.

(c) Consider compensating controls such as CAA records, DANE-TA pinning (where the CA supports it), or monitoring for unauthorized DNS changes.

Verifiers encountering DNS-based cross-endorsement records without DNSSEC validation MUST treat those records as integrity-unverified. This corresponds to State 5 (Integrity Failure) in Section 15. Verifiers MAY accept such records with reduced assurance if their risk model explicitly permits it, but MUST NOT treat them as equivalent to DNSSEC-validated records.

The HAVID ecosystem SHOULD track DNSSEC adoption trends and revisit this guidance as deployment matures.

12. Bridging DNS and X.509

This section is normative.

The relationship between DNS and X.509 is the most established of the three pairings. Domain-validated X.509 certificates bind a public key to a DNS domain name, forming the foundation of Web PKI and TLS.

12.1. Cross-Endorsement: X.509 to DNS

X.509 certificates reference DNS domains through the Subject Alternative Name (SAN) extension, as defined in [RFC 6125, Section 6.4.4]. The legacy practice of using the Common Name (CN) field ([RFC 5280, Section 4.1.2.6]) is deprecated for this purpose.

12.2. Cross-Endorsement: DNS to X.509

DNS can explicitly endorse an X.509 certificate using DANE ([RFC 6698]), which publishes certificate assertions via TLSA records.

An Identifier Controller establishes a DNS-to-X.509 cross-endorsement by:

(a) Publishing a TLSA record at a service-specific DNS name (e.g., _443._tcp.example.com) containing the hash or raw data of the X.509 certificate or its public key.

(b) Protecting the DNS zone with DNSSEC (see Section 11.4).

A Verifier confirms the cross-endorsement by:

(a) Retrieving the TLSA record and validating the DNSSEC signature chain.

(b) Retrieving the X.509 certificate presented over TLS.

(c) Confirming that the certificate matches the TLSA assertion.

12.3. Note on Key Alignment

In the DNS/X.509 pairing, key alignment is inherent: the X.509 certificate contains the public key, and the TLSA record references either the certificate or the key. Because the certificate's cryptoperiod naturally governs the key's validity, lifecycle alignment is more naturally managed in this pairing than in the others. The normative requirements of Section 10 still apply.

13. Bridging DIDs and X.509

This section is normative.

DIDs and X.509 certificates both use public/private key pairs, but they serve fundamentally different purposes. Cross-endorsement between these systems allows an entity to demonstrate that its DID and its X.509 certificate are controlled by the same party. This composes the CA-attested identity of the certificate with the key management capabilities of the DID. It does not transfer trust properties between them.

13.1. Cross-Endorsement: DID to X.509

An Identifier Controller establishes a DID-to-X.509 cross-endorsement by including a reference to the X.509 certificate within a verificationMethod in the DID Document.

Requirements:

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

(b) The public key MUST be expressed using the publicKeyJwk property.

(c) 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 a standalone certificate or a complete chain.

Example DIDs with X.509 Certificates in DID Documents: