The current Internet architecture suffers from fundamental design limitations rooted in its 1970s origins: location-based addressing, centralized trust dependencies, and bolt-on security models. This report presents Universal DID-Native Addressing (UDNA), a paradigmatic shift toward identity-centric networking where Decentralized Identifiers become first-class network primitives.

UDNA enables globally unique, self-sovereign, and cryptographically verifiable network addressing without reliance on centralized authorities. This approach achieves sub-50μs DID resolution, <2ms handshake latency, and provides mathematical guarantees for address integrity and non-repudiation.

This document was published by the W3C Credentials Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

If you wish to make comments regarding this document, please send them to public-credentials@w3.org (subscribe, archives).

1. Introduction

1.1 Background

The Internet Protocol Suite (TCP/IP) has served as the foundation of global networking for over four decades. However, its location-based addressing model presents fundamental limitations in today's security-conscious, privacy-aware, and mobility-centric computing environment.

Contemporary networking faces three critical challenges:

  1. Identity Crisis: IP addresses describe location, not identity, creating semantic gaps requiring complex overlay systems
  2. Trust Crisis: Certificate authorities and DNS hierarchies represent centralized points of failure and control
  3. Privacy Crisis: Location-based addressing enables surveillance and correlation by design

1.2 Relationship to W3C Specifications

1.3 Scope

This document specifies:

2. Motivation and Requirements

2.1 Limitations of Current Approaches

2.1.1 IP/DNS Addressing

The Domain Name System exhibits several architectural limitations:

2.1.2 Public Key Infrastructure

Traditional PKI approaches face:

2.2 Design Requirements

UDNA addresses these limitations through:

  1. Decentralized Identity: No central authority required for identifier creation
  2. Cryptographic Verifiability: All addressing operations cryptographically verifiable
  3. Privacy by Default: Pairwise identifiers prevent correlation
  4. Offline Operation: Cached credentials enable partition-tolerant operation
  5. Protocol Integration: DIDs as first-class network primitives

3. UDNA Architecture

3.1 Core Principles

  1. Identity as Address: Network endpoints identified by DIDs, making identity and address semantically equivalent
  2. Cryptographic Verifiability: All operations cryptographically verifiable without trusted third parties
  3. Privacy by Default: Pairwise and rotating DIDs prevent correlation
  4. Offline Resilience: Cached credentials enable operation during network partitions
  5. Protocol Native Integration: DIDs as first-class network protocol elements

3.2 System Components

3.2.1 DID Method Support

3.2.2 Service Facets

Each DID exposes multiple service facets enabling fine-grained access control:

3.2.3 Privacy Mechanisms

Pairwise DIDs: Each bilateral relationship uses unique DID pairs, preventing correlation across relationships while maintaining cryptographic verifiability.

Rotating DIDs: Time-bounded identifiers with cryptographic rotation proofs enable forward secrecy and limit the impact of key compromise.

4. DID Integration

4.1 DID Resolution as Protocol Primitive

UDNA implements a multi-tier resolution architecture:

4.1.1 Tier 1: Local Cache

4.1.2 Tier 2: Distributed Resolution Network

4.1.3 Tier 3: Method-Specific Resolvers

4.2 Key Rotation Protocol

RotationProof {
    prev_key: PublicKey,           // Previous signing key
    new_key: PublicKey,            // New signing key
    new_doc_hash: Hash,            // Hash of updated DID Document  
    valid_from: Timestamp,         // Rotation effective time
    valid_to: Optional<Timestamp>, // Optional rotation expiry
    reason: RotationReason,        // Rotation reason code
    sig_by_prev: Signature,        // Signature by previous key
}

5. Wire Protocol Specification

5.1 Address Header Format

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |   DIDType     |          DIDLength            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         DIDBytes (variable)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   FacetId     | KeyHintLen    |      KeyHint (variable)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RouteHintLen   |              RouteHint (variable)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Flags             |            Nonce              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Nonce (cont.)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Signature (variable)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2 Field Definitions

5.3 Compression Optimization

UDNA employs several space optimization techniques:

These optimizations achieve 35–55% space savings compared to raw DID strings.

6. Security Model

6.1 Threat Model

6.2 Security Guarantees

6.2.1 Authentication

6.2.2 Confidentiality

6.2.3 Availability

6.3 Cryptographic Handshake

UDNA employs the Noise Protocol Framework extended with DID-based identity verification:

6.3.1 Noise-IK Pattern

  1. Initiator resolves remote DID to obtain current public keys
  2. Noise-IK handshake proceeds with DID-derived static keys
  3. Mutual authentication through DID signature verification
  4. Session keys derived from handshake provide forward secrecy

6.3.2 Noise-XX Pattern

  1. Anonymous handshake establishes secure channel
  2. DIDs exchanged within encrypted tunnel
  3. Post-handshake DID verification confirms identity
  4. Optional re-keying with DID-derived keys

7. Privacy Considerations

7.1 Privacy Mechanisms

7.1.1 Unlinkable Pairwise DIDs

Each bilateral relationship employs unique DIDs:

7.1.2 Traffic Analysis Resistance

7.2 Correlation Prevention

8. Interoperability

8.1 Legacy System Integration

8.1.1 DIDComm v2 Compatibility

8.1.2 IP Network Gateways

8.2 Standards Alignment

9. Implementation Considerations

9.1 Performance Characteristics

OperationTargetMeasuredNotes
DID Resolution (cache)<50μs42μsLocal cache, signature verification
DID Resolution (DHT)<10ms8.3ms3-hop DHT traversal
Handshake (1-RTT)<2ms1.7msNoise-IK, did:key resolution
Address Parsing<10μs7μsBinary format, zero-copy

9.2 Scalability Analysis

9.3 Resource Requirements

10. Security and Privacy Considerations

10.1 Security Analysis

UDNA's security model has been analyzed using formal verification tools. Key findings:

10.2 Privacy Analysis

Privacy protection mechanisms:

10.3 Anti-Abuse Mechanisms

11. IANA Considerations

This specification defines:

12. References

12.1 Normative References

12.2 Informative References

Acknowledgments

The editors thank the W3C Credentials Community Group for their ongoing support and feedback. Special recognition to the DID Working Group for establishing the foundational standards upon which UDNA builds, and to the global cryptography research community for developing the mathematical foundations enabling secure identity systems.

Revision History

VersionDateChanges
1.02025-09-15Initial W3C Community Group Report