Universal DID-Native Addressing (UDNA)

Document Version: 2.0
Standards Track: Informational
Category: Network Protocol
Author: Amir Hameed Mir
Date: October 28, 2025
W3C Community Group Draft

Universal DID-Native Addressing (UDNA) integrates Decentralized Identifiers (DIDs) as fundamental network addresses, enabling identity-based routing and communication. This specification defines a network architecture where cryptographic identity and network addressing are unified, providing built-in authentication, privacy, and trust mechanisms at the network layer.

Core Concept Explained

Traditional Internet: IP addresses (e.g., 192.168.1.1) identify locations, not entities. Separate systems (DNS, PKI, etc.) are needed to map names to addresses and establish trust.

UDNA Approach: DIDs (e.g., did:scp:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK) serve as both identity and address. Each DID resolves to a cryptographically verifiable document containing public keys and service endpoints, eliminating the need for separate trust systems.

Abstract

Universal DID-Native Addressing (UDNA) is a network architecture specification that integrates Decentralized Identifiers (DIDs) as native network addresses. By using cryptographic identities as network endpoints, UDNA enables location-independent routing, inherent authentication, and privacy-preserving communication.

This specification provides the complete technical framework for UDNA implementation, including protocol mechanics, cryptographic requirements, architectural design, and implementation guidelines. UDNA addresses fundamental limitations in current internet architecture by unifying identity and addressing at the network layer.

Status of This Document

Publication Status
W3C Community Group Draft

This document is a draft technical specification. It is subject to change and should not be considered stable for production implementation without further review and standardization.

Important: This is a Community Group Draft and does not represent W3C consensus. It is inappropriate to cite this document as other than work in progress.

This document is published by the Universal DID-Native Addressing (UDNA) Community Group as part of the W3C Community Group process. GitHub Issues are preferred for discussion of this specification.

1. Introduction

1.1 Problem Statement

Current internet architecture separates identity from addressing, requiring multiple layered systems to establish communication and trust:

Current Internet Architecture Limitations
  • IP Addresses identify network interfaces, not entities or users
  • DNS provides name resolution but introduces centralization and single points of failure
  • Public Key Infrastructure (PKI) requires certificate authorities as trusted third parties
  • Network Address Translation (NAT) breaks end-to-end connectivity
  • Application-layer protocols must reimplement authentication and authorization

1.2 Solution Approach

UDNA integrates Decentralized Identifiers (DIDs) as native network addresses, providing:

Identity-based Addressing

Network addresses are cryptographic identities, enabling direct entity-to-entity communication

Built-in Authentication

Authentication is inherent to the network layer through cryptographic proofs

Privacy by Design

Pairwise ephemeral DIDs enable unlinkable communication and privacy preservation

Decentralized Operation

No single points of control or failure in the addressing and routing system

1.3 Design Principles

Core Design Principles
Technical Foundation of UDNA
  • Decentralization: No central authorities or single points of failure in the addressing system
  • Self-Sovereign Identity: Users control their cryptographic keys and identity documents
  • Privacy Preservation: Built-in mechanisms for unlinkable communication and data protection
  • Protocol Interoperability: Compatibility with existing DID methods and network protocols
  • Cryptographic Agility: Support for multiple cryptographic algorithms and future advances
  • Network Efficiency: Optimized routing and minimal overhead for practical deployment

2. Terminology

2.1 Core Definitions

Term Definition Notation
Decentralized Identifier (DID) A URI composed of three parts: `did:method:identifier`. Resolves to a DID Document containing cryptographic material and service endpoints. did:M:ID
DID Document A structured document (JSON-LD or CBOR) containing cryptographic keys, verification methods, and service endpoints associated with a DID. D_doc(d) = (K, V, S)
UDNA Address A unique, routable endpoint within the SCP network, defined as a function of a DID and facet identifier. A = f(did, facet_id)
Pairwise-Ephemeral DID (PE-DID) A short-lived DID derived from a privacy-preserving DID for specific transactions, providing unlinkability. PE = KDF(Root, Context)
Zero-Knowledge Capability (ZCAP) A cryptographically signed delegation token that authorizes specific actions using zero-knowledge proofs. ZCAP = Sig(sk, {action, resource})

2.2 Mathematical Notation

Notation Reference
||    : Concatenation operator
⊕     : XOR operation  
H(x)  : Cryptographic hash function applied to x
Sig(sk, m) : Digital signature of message m using private key sk
Verify(pk, m, σ) : Signature verification using public key pk
KDF(k, c) : Key derivation function with key k and context c
A ⊕ B : XOR distance between identifiers A and B

3. Architecture Overview

3.1 Layered Architecture

6

Application Layer

DApps, Services, User Interfaces

5

Security & Privacy Layer

ZCAPs, Pairwise DIDs, Encryption

4

Network Layer

SCP Overlay, Routing, Discovery

3

Cryptographic Layer

Key Management, Signatures, KDFs

2

Resolution Layer

DID Resolution, Document Caching

1

Binary Protocol Layer

Wire Protocol, Header Format

3.2 Protocol Stack Comparison

Layer Traditional Internet UDNA/SCP Network Improvement
Addressing IP (Location-based) DID (Identity-based) Location independence
Naming DNS (Centralized) DID Resolution (Decentralized) Censorship resistance
Trust PKI/CA (Hierarchical) Self-sovereign cryptography No central authorities
Authentication Application layer Network primitive Simplified development
Privacy Add-on services Built-in design Stronger default guarantees
Why This Architecture Matters

Traditional Approach: Applications must implement their own authentication, manage certificate authorities, and handle NAT traversal. Each layer adds complexity and potential security vulnerabilities.

UDNA Approach: Identity, authentication, and privacy are built into the network layer. Applications communicate directly using cryptographic identities, eliminating the need for intermediate trust systems and simplifying development.

4. Core Protocol Specification

4.1 UDNA Address Header Format

Header Structure

┌─────────────────────────────────────────────────────────────────────────┐
│ UDNA Header Format │
├─────────────────────────────────────────────────────────────────────────┤
│ Offset │ Size │ Field │ Description │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 0 │ 1 │ Version │ Protocol version (0x01) │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 1 │ 2 │ Flags │ Protocol control flags │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 3 │ 1 │ DID Type │ DID method identifier │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 4 │ 1 │ DID Length │ Length of DID in bytes │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 5 │ 1 │ Facet ID │ Service facet identifier (0-255) │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 6 │ 1 │ Reserved │ Reserved for future use │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 7 │ n │ DID Bytes │ DID identifier bytes (variable) │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 7+n │ 32 │ Key Hint │ Public key hint (256 bits) │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 39+n │ m │ Route Hint │ Route information (CBOR, variable) │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 39+n+m │ 16 │ Nonce │ Random nonce (128 bits) │
├─────────┼──────┼─────────────┼─────────────────────────────────────────┤
│ 55+n+m │ k │ Signature │ Cryptographic signature (≥64 bytes) │
└─────────┴──────┴─────────────┴─────────────────────────────────────────┘
Header Field Explanation

Key Hint (32 bytes): A truncated hash of the public key, used for efficient key lookup in resolution caches without revealing the full public key.

Route Hint (variable): CBOR-encoded routing information that helps nodes efficiently locate the destination, particularly useful for mobile or NAT-traversed nodes.

Nonce (16 bytes): Prevents replay attacks and ensures message uniqueness. Each message must have a unique nonce within its validity period.

4.2 Field Specifications

4.2.1 Version (8 bits)

Protocol version identifier. Current version is 0x01.

4.2.2 Flags (16 bits)

Flag Bit Assignments
Bit 0 (P): Pairwise flag - indicates PE-DID derived from PP-DID
Bit 1 (R): Rotation flag - message contains key rotation proof  
Bit 2 (E): Ephemeral flag - single-use DID, no state persistence
Bit 3 (A): Acknowledgment requested - requests transport-layer ACK
Bit 4 (K): Key pre-rotation hint - signals upcoming key rotation
Bits 5-15: Reserved for future use

4.2.3 DID Types

Value DID Method Description
0x01 did:key Inline public key DIDs
0x02 did:web Web-hosted DIDs
0x03 did:scp SCP network DIDs (native)
0x04 did:ion ION blockchain DIDs
0x05 did:ethr Ethereum-based DIDs
0xFF Experimental Reserved for experimental methods

How UDNA Works: A Practical Example

1
DID Creation: Alice generates a cryptographic key pair and creates a DID (e.g., did:scp:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK)
2
Document Publication: Alice creates a DID Document with her public key and service endpoints, then publishes it to the DHT
3
Address Resolution: Bob wants to send a message to Alice. He uses her DID as the address, and the network resolves it to current network locations
4
Secure Session: Bob establishes an encrypted session using Alice's public key from her DID Document
5
Message Delivery: Messages are routed through the SCP overlay network directly to Alice's current network location
Key Technical Innovations
  • Location Independence: Alice can move between networks without changing her address
  • Built-in Authentication: Bob verifies Alice's identity using her cryptographic keys
  • Privacy Protection: Optional pairwise DIDs prevent correlation of different conversations
  • Decentralized Resolution: No central directory service required for address lookup

5. Resolution Subsystem

5.1 Resolution Architecture

Three-Tier Resolution System
Efficient DID Document Lookup with Caching

L1 Cache

In-memory LRU cache for frequently accessed DID Documents (~1000 entries)

L2 Cache

Persistent local storage for recently accessed documents (~10,000 entries)

L3 Cache

Distributed cache via SCP DHT for all documents in the network

5.2 DID Resolution Process

┌─────────────────────────────────────────────────────────────┐
│ DID Resolution Flow │
├─────────────────────────────────────────────────────────────┤
│ 1. Receive UDNA address with DID │
│ 2. Check L1 cache (memory) │
│ ├─ Hit: Return cached document │
│ └─ Miss: Continue to step 3 │
│ 3. Check L2 cache (local storage) │
│ ├─ Hit: Return cached document, update L1 │
│ └─ Miss: Continue to step 4 │
│ 4. Query SCP DHT (distributed cache) │
│ ├─ Hit: Return document, update L2 and L1 │
│ └─ Miss: Perform full resolution │
│ 5. Full resolution based on DID method │
│ ├─ did:scp: Query DHT directly │
│ ├─ did:web: HTTPS request to web server │
│ ├─ did:key: Local key derivation │
│ └─ Other: Method-specific resolution │
│ 6. Validate document signatures and proofs │
│ 7. Cache document in L3, L2, and L1 │
│ 8. Return resolved document │
└─────────────────────────────────────────────────────────────┘

5.3 Proof-of-Control Verification

Verification Requirements:

  1. Initial Resolution: For `did:scp` methods, the DHT record must be signed by a key present in the DID Document itself
  2. Document Updates: Updated documents must be signed by a key authorized in the previous valid version
  3. Key Rotation: Rotation proofs must be signed by the previous key and include the new document hash

6. Cryptographic Framework

6.1 Required Algorithms

Category Algorithm Standard Purpose Status
Digital Signatures Ed25519 RFC 8032 Primary signature algorithm REQUIRED
Key Agreement X25519 RFC 7748 Primary key exchange REQUIRED
Symmetric Encryption ChaCha20-Poly1305 RFC 8439 AEAD cipher (preferred) REQUIRED
Hash Functions BLAKE2b RFC 7693 Primary hash function REQUIRED
Alternative Signatures ES256K RFC 7515 Ethereum compatibility OPTIONAL
Advanced Signatures BLS12-381 draft-irtf-cfrg-bls-signature Signature aggregation OPTIONAL

6.2 Key Derivation and Management

┌─────────────────────────────────────────────────────────────┐
│ Key Hierarchy and Derivation │
├─────────────────────────────────────────────────────────────┤
│ Master Key (Root) │
│ ├─ Identity Key (Ed25519) - Long-term identity │
│ ├─ Encryption Key (X25519) - Session establishment │
│ └─ Derivation Key - For generating ephemeral keys │
│ │
│ From Identity Key: │
│ ├─ Pairwise-Persistent DIDs (PP-DIDs) │
│ │ └─ For long-term relationships │
│ └─ Pairwise-Ephemeral DIDs (PE-DIDs) │
│ └─ For single transactions/sessions │
│ │
│ Derivation Formula: │
│ PE-DID = BLAKE2b(Root_Private_Key || Context || Counter) │
│ Context = relationship_id || purpose || timestamp │
└─────────────────────────────────────────────────────────────┘

6.3 Key Rotation Protocol

Three-Phase Rotation Protocol
Ensuring Continuous Service During Key Updates

Phase 1: Pre-rotation

Generate new key pair, create new DID Document with both old and new keys, begin advertising new key

Phase 2: Rotation

Create and sign rotation proof, broadcast to cached nodes, update service endpoints, accept both keys

Phase 3: Post-rotation

Monitor old-key usage, remove old key after grace period (typically 7 days), update DHT with final document

7. Network Layer: SCP Overlay

7.1 DHT Architecture

Modified Kademlia DHT
// Node Identification (Sybil-resistant)
NodeID = BLAKE3(primary_verification_key_bytes)

// Distance Metric (XOR for efficient routing)
fn distance(a: NodeID, b: NodeID) -> NodeID {
    a ^ b
}

// Stored Values (Signed PeerInfo structures)
struct PeerInfo {
    did: String,
    multiaddrs: Vec,
    facets: Vec,
    timestamp: u64,
    signature: Vec,
}

struct FacetInfo {
    id: u8,
    capability: Option>,
}

7.2 Network Discovery and Routing

┌─────────────────────────────────────────────────────────────┐
│ SCP Network Node Discovery │
├─────────────────────────────────────────────────────────────┤
│ 1. Bootstrap: Connect to known entry nodes │
│ 2. Exchange: Share routing tables with neighbors │
│ 3. Store: Publish own PeerInfo to DHT │
│ 4. Discover: Learn about other nodes through DHT queries │
│ 5. Maintain: Regularly refresh routing table entries │
│ │
│ Message Routing Process │
├─────────────────────────────────────────────────────────────┤
│ 1. Resolve target DID to current network locations │
│ 2. Select optimal route based on latency and reliability │
│ 3. Establish encrypted session (Noise_XX pattern) │
│ 4. Transmit message with end-to-end encryption │
│ 5. Acknowledge delivery or retry as needed │
└─────────────────────────────────────────────────────────────┘

7.3 NAT Traversal and Relaying

Network Connectivity Solutions

UDNA includes several mechanisms to handle network connectivity challenges:

  • STUN/ICE Integration: Uses standard NAT traversal techniques to establish direct connections
  • Relay Nodes: Designated nodes that forward traffic for NAT-traversed peers
  • Hole Punching: Coordinated connection attempts to establish direct P2P links
  • UPnP/IGD Support: Automatic port forwarding where supported by network equipment

Relay nodes are compensated for their services through micro-payments or reputation systems, ensuring sustainable operation without central funding.

8. Security and Privacy

8.1 Security Model

Security Assumptions
Foundation for Security Analysis
  • Cryptographic Primitives: Standard assumptions hold (SUF-CMA for signatures, IND-CCA2 for encryption)
  • Network Adversary: Adversary controls network communication but not endpoint devices
  • Honest Majority: More than 50% of DHT nodes follow the protocol correctly
  • Key Security: Private keys are securely stored and managed by their owners
  • Timing Assumptions: Clocks are loosely synchronized (±5 minutes acceptable)

8.2 Security Properties and Proofs

8.2.1 Address Integrity Theorem

Theorem: A UDNA Address Header cannot be modified in transit without detection.

Proof: The header signature is computed as Sig(SK_i, H(header_fields)) where SK_i is the DID's private key. Verification requires Verify(PK_i, H(header_fields), signature) where PK_i is from the resolved DID Document. The security reduces to the existential unforgeability of the signature scheme under chosen message attacks (SUF-CMA).

8.2.2 Identity Binding Theorem

Theorem: A successful UDNA session establishes proof of private key possession.

Proof: The Noise_XX handshake pattern requires both parties to perform Diffie-Hellman operations using their static private keys. A party not possessing the private key corresponding to their advertised DID cannot complete the handshake, as the shared secret derivation will fail.

8.3 Privacy Architecture

Pairwise Identity System
Unlinkable Privacy by Design
┌─────────────────────────────────────────────────────────────┐
│ Pairwise DID Privacy Properties │
├─────────────────────────────────────────────────────────────┤
│ Property │ Description │
├──────────────────────────┼──────────────────────────────────┤
│ Deterministic │ Same inputs → same PE-DID │
├──────────────────────────┼──────────────────────────────────┤
│ Unlinkable │ Without root key, cannot relate │
│ │ PE-DIDs to each other │
├──────────────────────────┼──────────────────────────────────┤
│ Unique │ Different relationships → │
│ │ different PE-DIDs │
├──────────────────────────┼──────────────────────────────────┤
│ Recoverable │ With root key, can regenerate │
│ │ any PE-DID │
└──────────────────────────┴──────────────────────────────────┘
Practical Privacy Example

Scenario: Alice wants to communicate with Bob, Carol, and Dave without revealing that all communications are from the same person.

Solution: Alice uses different Pairwise-Ephemeral DIDs for each relationship:

  • For Bob: PE-DID_B = KDF(Root_Key, "bob-relationship")
  • For Carol: PE-DID_C = KDF(Root_Key, "carol-relationship")
  • For Dave: PE-DID_D = KDF(Root_Key, "dave-relationship")

Each party sees a different DID, and without Alice's root key, they cannot determine that these DIDs belong to the same person.

8.4 Attack Mitigations

Attack Type Description UDNA Mitigation Effectiveness
Eclipse Attack Adversary surrounds target with malicious nodes Diverse routing table maintenance, random walk discovery High
Sybil Attack Adversary creates many fake identities Proof-of-work for node ID generation, reputation systems High
Replay Attack Reusing valid messages Nonces, timestamps, session-specific context High
Man-in-the-Middle Intercepting and modifying communication End-to-end encryption, cryptographic authentication High
Traffic Analysis Analyzing metadata patterns Cover traffic, timing randomization, onion routing Medium

9. Implementation Guidelines

9.1 Reference Implementation Structure

┌─────────────────────────────────────────────────────────────┐
│ UDNA Implementation Stack │
├─────────────────────────────────────────────────────────────┤
│ Application Layer │
│ ├─ DApps, messaging clients, file sharing │
│ └─ UDNA SDK integration │
├─────────────────────────────────────────────────────────────┤
│ UDNA SDK │
│ ├─ Resolver Engine (DID resolution, caching) │
│ ├─ Crypto Engine (signatures, encryption, KDFs) │
│ └─ Transport Stack (session management, message routing) │
├─────────────────────────────────────────────────────────────┤
│ SCP Core Engine │
│ ├─ DHT Routing (Kademlia implementation) │
│ ├─ Wire Protocol (binary format, framing) │
│ └─ NAT Traversal (STUN, ICE, relaying) │
└─────────────────────────────────────────────────────────────┘

9.2 Performance Requirements

Metric Target Performance Rationale Test Conditions
DID Resolution <100ms Interactive application responsiveness Cached resolution, warm DHT
Header Validation <1ms Network layer efficiency Single signature verification
Session Establishment <200ms Comparable to TLS handshake Noise_XX handshake pattern
DHT Lookup <500ms 3-hop average in 1M node network Concurrent queries, α=3
Memory Usage <50MB Suitable for mobile deployment 10K cached DIDs, full stack

9.3 Error Handling and Recovery

Error Handling Framework
#[derive(Debug, Error)]
pub enum UDNAError {
    #[error("DID resolution failed: {0}")]
    ResolutionFailed(String),
    
    #[error("Cryptographic operation failed: {0}")]
    CryptoError(#[from] CryptoError),
    
    #[error("Network error: {0}")]
    NetworkError(#[from] NetworkError),
    
    #[error("Protocol violation: {0}")]
    ProtocolError(String),
    
    #[error("Header validation failed: {0}")]
    HeaderValidationError(HeaderError),
    
    #[error("Key rotation in progress: {0}")]
    KeyRotationError(String),
    
    #[error("ZCAP verification failed: {0}")]
    ZCAPError(String),
}

// Automatic recovery strategies based on error type
impl UDNAError {
    pub fn recovery_strategy(&self) -> RecoveryStrategy {
        match self {
            UDNAError::ResolutionFailed(_) => RecoveryStrategy::RetryWithFallback,
            UDNAError::NetworkError(_) => RecoveryStrategy::Reconnect,
            UDNAError::KeyRotationError(_) => RecoveryStrategy::RefreshAndRetry,
            _ => RecoveryStrategy::FailFast,
        }
    }
}

Deployment and Migration Strategies

Gateway Deployment

UDNA gateways translate between traditional protocols (HTTP, SMTP) and UDNA, enabling gradual adoption without requiring all endpoints to upgrade simultaneously.

Hybrid Operation

Applications can support both traditional addressing and UDNA addressing, with automatic protocol selection based on destination capabilities.

Mobile and IoT

Lightweight client implementations with reduced resource requirements for mobile devices and IoT endpoints.

Enterprise Integration

Corporate deployment models with enhanced logging, monitoring, and integration with existing identity management systems.

Migration Path from Current Internet
  1. Phase 1 (Gateway Services): UDNA gateways provide access to UDNA network from traditional applications
  2. Phase 2 (Dual-Stack Applications): Applications support both IP and UDNA addressing
  3. Phase 3 (UDNA-Native Applications): New applications built specifically for UDNA architecture
  4. Phase 4 (Legacy Protocol Deprecation): Gradual reduction of traditional protocol support as UDNA adoption increases

10. Interoperability

10.1 Legacy Internet Integration

UDNA Gateway Architecture
Protocol Translation Between Systems
┌─────────────────────────────────────────────────────────────┐
│ HTTP ↔ UDNA Gateway Operation │
├─────────────────────────────────────────────────────────────┤
│ 1. HTTP client sends request to gateway │
│ 2. Gateway extracts Host header │
│ 3. Query DNS for `_udna.` TXT record │
│ 4. TXT record contains target DID │
│ 5. Gateway resolves DID to service endpoints │
│ 6. Establish UDNA session to target │
│ 7. Translate HTTP request to UDNA message │
│ 8. Forward response back to HTTP client │
│ │
│ DNS Integration Example: │
│ _udna.example.com. 300 IN TXT │
│ "did:scp:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"│
└─────────────────────────────────────────────────────────────┘

10.2 DID Method Compatibility

Cross-Method Support Implementation
pub enum DIDMethod {
    Key(did_key::KeyDID),
    Web(did_web::WebDID), 
    SCP(did_scp::SCPDID),
    ION(did_ion::IONDID),
    Unknown(String),
}

impl DIDMethod {
    pub async fn resolve(&self) -> Result {
        match self {
            DIDMethod::Key(did) => did.resolve_locally(),
            DIDMethod::Web(did) => did.resolve_via_https().await,
            DIDMethod::SCP(did) => did.resolve_via_dht().await,
            DIDMethod::ION(did) => did.resolve_via_bitcoin().await,
            DIDMethod::Unknown(_) => Err(ResolverError::UnsupportedMethod),
        }
    }
}

10.3 Protocol Bridges

Seamless Cross-Protocol Communication: UDNA enables communication between different network protocols through protocol bridges:

┌─────────────────────────────────────────────────────────────┐
│ Supported Protocol Bridges │
├─────────────────────────────────────────────────────────────┤
│ Protocol │ Bridge Type │ Use Case │
├───────────┼──────────────────┼──────────────────────────────┤
│ HTTP/HTTPS│Gateway │ Web application access │
├───────────┼──────────────────┼──────────────────────────────┤
│ SMTP │Email Gateway │ Email sending/receiving │
├───────────┼──────────────────┼──────────────────────────────┤
│ XMPP │Messaging Bridge │ Instant messaging │
├───────────┼──────────────────┼──────────────────────────────┤
│ Matrix │Federation Bridge│ Chat room federation │
├───────────┼──────────────────┼──────────────────────────────┤
│ IPFS │Storage Bridge │ Decentralized file storage │
└───────────┴──────────────────┴──────────────────────────────┘

11. Formal Analysis

11.1 Protocol Verification

11.1.1 State Machine Models

DID Resolution State Machine (TLA+)
VARIABLES 
    cache,          \* Local DID document cache
    resolving,      \* Set of DIDs currently being resolved  
    network_state   \* Network connectivity status

Init == 
    /\ cache = [did \in DID |-> NULL]
    /\ resolving = {}
    /\ network_state = "connected"

Resolve(did) ==
    /\ did \notin resolving
    /\ resolving' = resolving \union {did}
    /\ \/ /\ cache[did] # NULL 
          /\ cache[did].ttl > Now()
          /\ RETURN cache[did].document
       \/ /\ QueryNetwork(did)
          /\ AWAIT NetworkResponse(did)

UpdateCache(did, document, ttl) ==
    /\ cache' = [cache EXCEPT ![did] = 
                  [document |-> document, ttl |-> ttl]]
    /\ resolving' = resolving \ {did}

11.1.2 Security Properties

Formal Security Properties (TLA+)
AuthenticationIntegrity ==
    \A session \in Sessions :
        session.authenticated => 
            ControlsKey(session.peer_did, session.peer_key)

MessageOrdering ==
    \A s1, s2 \in SentMessages :
        /\ s1.session_id = s2.session_id
        /\ s1.sequence < s2.sequence
        => s1.timestamp <= s2.timestamp

ResolutionLiveness ==
    \A did \in ValidDIDs :
        <>[] (ResolveRequest(did) ~> ResolveResponse(did))

11.2 Performance Analysis

Operation Time Complexity Space Complexity Practical Impact
DID Resolution (cached) O(1) O(n) for cache <1ms for cache hit
DID Resolution (DHT) O(log n) O(log n) per node ~200ms for 1M nodes
Session Establishment O(1) O(1) ~150ms (2x DH ops)
Message Routing O(log n) O(log n) routing table ~3 hops average
Key Rotation O(k) for k cached nodes O(1) Scales with network size

12. Future Considerations

12.1 Research Directions

Active Research Areas
Technical Challenges Requiring Further Investigation

Post-Quantum Cryptography

Integration of NIST-selected PQC algorithms, hybrid cryptographic modes, quantum key distribution integration

Advanced Privacy

Private information retrieval, fully homomorphic encryption, secure multi-party computation integration

Scalability Solutions

DHT sharding, hierarchical addressing schemes, content-addressable storage for large documents

Performance Optimization

Hardware acceleration, protocol simplifications, reduced handshake overhead for low-power devices

12.2 Standardization Roadmap

Phase Timeline Objectives Deliverables
Phase 1: Core Protocol Q4 2025 Reference implementation, basic DID resolution and messaging Rust SDK, basic specs, test vectors
Phase 2: Network Infrastructure Q2 2026 DHT overlay deployment, relay system, gateway services Production DHT, NAT traversal, legacy bridges
Phase 3: Production Deployment Q4 2026 Mobile/desktop apps, enterprise tools, performance optimization Mobile SDKs, monitoring tools, enterprise integration
Phase 4: Standards Finalization 2027 IETF/W3C standardization, formal verification, security audits RFCs, formal proofs, audit reports

13. References

13.1 Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015.
  • [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, January 2016.
  • [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017.
  • [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.

13.2 Informative References

  • [DID-CORE] Reed, D., Sporny, M., Longley, D., Allen, C., Grant, R., Sabadello, M., "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, 19 July 2022.
  • [NOISE] Perrin, T., "The Noise Protocol Framework", 2018.
  • [KADEMLIA] Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-peer Information System Based on the XOR Metric", IPTPS 2002.
  • [ZCAP-LD] Longley, D. and M. Sporny, "Authorization Capabilities for Linked Data v0.3", Digital Bazaar, 2021.

14. Appendices

14.1 Appendix A: Protocol Grammar

UDNA Address Grammar
udna-address = "udna://" did-identifier ":" facet-id
did-identifier = "did:" method-name ":" method-specific-id
method-name = 1*method-char
method-char = %x61-7A / DIGIT  ; lowercase letters and digits
method-specific-id = *idchar
idchar = ALPHA / DIGIT / "." / "-" / "_"
facet-id = 1*3DIGIT  ; 0-255

14.2 Appendix B: Implementation Checklist

Implementation Requirements Checklist
Minimum Requirements for UDNA Compliance
┌─────────────────────────────────────────────────────────────┐
│ Core Protocol Requirements │
├─────────────────────────────────────────────────────────────┤
│ ☐ UDNA header parsing and validation │
│ ☐ Ed25519 signature creation and verification │
│ ☐ X25519 key agreement for session establishment │
│ ☐ ChaCha20-Poly1305 encryption and decryption │
│ ☐ BLAKE2b/BLAKE3 hash functions │
│ ☐ DID resolution with three-tier caching │
│ ☐ Key rotation protocol implementation │
│ ☐ SCP DHT node operation and routing │
│ ☐ NAT traversal mechanisms (STUN/ICE/relaying) │
│ ☐ Pairwise DID generation and management │
└─────────────────────────────────────────────────────────────┘

14.3 Appendix C: Test Vectors

Sample Test Case
{
  "test_name": "Basic DID Resolution and Validation",
  "input": {
    "did": "did:scp:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
    "operation": "resolve_and_validate"
  },
  "expected_output": {
    "resolution_time": "<100ms",
    "validation_result": "valid",
    "document_properties": {
      "has_verification_method": true,
      "has_service_endpoint": true,
      "signature_valid": true
    }
  },
  "notes": "Test should be run with warm cache and network connectivity"
}