- 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
Universal DID-Native Addressing (UDNA)
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.
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.
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
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:
- 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
- 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
|| : 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
Application Layer
DApps, Services, User Interfaces
Security & Privacy Layer
ZCAPs, Pairwise DIDs, Encryption
Network Layer
SCP Overlay, Routing, Discovery
Cryptographic Layer
Key Management, Signatures, KDFs
Resolution Layer
DID Resolution, Document Caching
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 |
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) │ |
| └─────────┴──────┴─────────────┴─────────────────────────────────────────┘ |
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)
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
5. Resolution Subsystem
5.1 Resolution Architecture
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:
- Initial Resolution: For `did:scp` methods, the DHT record must be signed by a key present in the DID Document itself
- Document Updates: Updated documents must be signed by a key authorized in the previous valid version
- 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
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
// 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
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
- 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 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 │ |
| └──────────────────────────┴──────────────────────────────────┘ |
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
#[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.
- Phase 1 (Gateway Services): UDNA gateways provide access to UDNA network from traditional applications
- Phase 2 (Dual-Stack Applications): Applications support both IP and UDNA addressing
- Phase 3 (UDNA-Native Applications): New applications built specifically for UDNA architecture
- Phase 4 (Legacy Protocol Deprecation): Gradual reduction of traditional protocol support as UDNA adoption increases
10. Interoperability
10.1 Legacy Internet Integration
| ┌─────────────────────────────────────────────────────────────┐ |
| │ HTTP ↔ UDNA Gateway Operation │ |
| ├─────────────────────────────────────────────────────────────┤ |
| │ 1. HTTP client sends request to gateway │ |
| │ 2. Gateway extracts Host header │ |
| │ 3. Query DNS for `_udna. |
| │ 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
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
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
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
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 = "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
| ┌─────────────────────────────────────────────────────────────┐ |
| │ 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
{
"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"
}