Universal DID Native Addressing (UDNA)

Universal DID Native Addressing (UDNA) defines a lightweight, extensible addressing scheme that makes Decentralized Identifiers (DIDs) native to resource location and service discovery on the Web. UDNA provides a uniform udna:// URI scheme that encodes a DID and a resource path, enabling secure, cryptographically verifiable interactions across decentralized systems. This specification builds on W3C Recommendations ([[DID-CORE]], [[VC-DATA-MODEL]]) and the DIDComm v2 messaging protocol ([[DIDCOMM]]). It is an incubation deliverable of the UDNA W3C Community Group and does not represent consensus of the broader W3C Membership.

This document is a Community Group Draft produced by the W3C Community Group for DID Native Addressing. It is not a W3C Standard nor on the W3C Standards Track. Publication by the W3C does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This specification is being developed to explore the intersection of decentralized identifiers, native addressing, and universal service discovery. The goal is to mature the proposal toward a future W3C Working Group deliverable. The CG welcomes issues and pull requests on GitHub. Before contributing, please review the W3C Community Contributor License Agreement.

The CG has received early reviews from implementers of Solid, DIDComm, and Hyperledger Aries, and expects to conduct multiple interoperability events during 2026.

Introduction

The Web's addressing model is built on URLs that bind authority to domain names, which in turn rely on centralized DNS and certificate authorities. While this has enabled massive growth, it introduces identity silos, privacy leaks, and intermediary dependency. Decentralized Identifiers (DIDs) offer self-sovereign, cryptographically verifiable identities, but they lack a native addressing scheme to directly locate resources, APIs, or services tied to a DID.

UDNA fills this gap. By introducing the udna:// URI scheme and a deterministic resolution mechanism, UDNA allows any entity with a DID to publish service endpoints, resources, and sub-paths that can be resolved in a secure, privacy-preserving way. UDNA leverages [[DID-CORE]] for identity, [[DIDCOMM]] for secure messaging, and [[VC-DATA-MODEL]] for authorization policies.

Terminology

This section defines the terms used throughout this specification.

UDNA Address: A URI conforming to the udna scheme, composed of a DID component, an optional service segment, and a resource path. Formally specified in .
DID Resolution: The process defined in [[DID-CORE]] by which a DID string is dereferenced to obtain a DID Document containing public keys and service endpoints.
UDNA Resolver: An implementation that accepts a [=UDNA Address=], extracts the embedded DID, performs [=DID Resolution=], and executes endpoint selection according to the algorithm in .
Native Addressing: An addressing model where the identifier of an entity (a DID) is an integral part of the resource locator, enabling direct, verifiable interactions without external naming authorities.
Service Endpoint: A network address defined within a DID Document under the service array property, expressed as a URI string, a set of URI strings, or a DIDComm endpoint object.
UDNARoot Service: The default service entry used by UDNA resolution when no explicit service segment is present. Identified by type: "UDNARoot" or the fragment identifier #udna-root in the DID Document.

UDNA URI Scheme

Scheme Syntax

The udna URI scheme follows the ABNF syntax below (extending [[RFC3986]]):

udna-URI   = "udna://" did-string [ "/" service-id ] path [ "?" query ] [ "#" fragment ]
did-string = scheme ":" method-specific-id
             ; a valid DID per [[DID-CORE]]
service-id = *( unreserved / pct-encoded )
path       = *( "/" segment )
query      = *( pchar / "/" / "?" )
fragment   = *( pchar / "/" / "?" )

A complete example illustrating all components:

udna://did:example:123456/service/api/resource?version=1#section

Components

DID (mandatory): A valid DID string per [[DID-CORE]], e.g., did:key:z6Mkp… or did:web:example.com. The DID forms the authority component of the [=UDNA Address=].
Service segment (optional): Identifies a specific service endpoint by matching the id fragment of a service entry in the resolved DID Document. If omitted, the resolver selects the [=UDNARoot Service=].
Path: A hierarchical path that is opaque to the UDNA resolution layer but meaningful to the target service after resolution.
Query and Fragment: Standard URI semantics per [[URL]], interpreted by the target service after resolution is complete.

Resolution Model

Resolution Algorithm

To resolve a [=UDNA Address=], a conformant [=UDNA Resolver=] MUST perform the following steps in order:

Parse the UDNA address to extract the DID string, service segment (if present), path, query, and fragment components per the syntax in .
Resolve the DID to a DID Document using the appropriate DID method resolver, as specified in [[DID-CORE]]. If resolution fails, return a resolution error of type notFound.
Perform service selection:
- If a service segment is present, locate the entry in the DID Document's service array whose id fragment matches the given segment. If no match is found, return error serviceNotFound.
- If no service segment is provided, select the entry whose type contains "UDNARoot" or whose id fragment equals udna-root. If neither is found, return error defaultServiceNotFound.
Obtain the serviceEndpoint value from the selected service entry. This value MAY be a URI string, a set of URI strings, or a DIDComm endpoint object.
Construct the final target URL by appending the path, query, and fragment to the resolved endpoint base URI. If the endpoint is a URI template ([[RFC6570]]), template expansion MUST be applied using available context variables.
Return a resolution result containing: targetUrl, didDocument, didDocumentMetadata, and verificationMethods associated with the selected service.

Resolvers SHOULD implement caching with appropriate TTL derived from DID Document metadata (created, updated). Resolvers MUST respect HTTP cache headers when resolving did:web identifiers.

Example Resolution

Input:  udna://did:web:example.com/app/profile#me

Step 1 — Parse:
  DID      = did:web:example.com
  path     = /app/profile
  fragment = me

Step 2 — Resolve DID → DID Document (simplified):
{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:web:example.com",
  "service": [{
    "id": "#udna-root",
    "type": "UDNARoot",
    "serviceEndpoint": "https://api.example.com/udna"
  }]
}

Step 3 — No service segment → select UDNARoot:
  serviceEndpoint = "https://api.example.com/udna"

Step 4 — Construct target URL:
  https://api.example.com/udna/app/profile#me

Step 5 — Return resolution result:
  { targetUrl: "https://api.example.com/udna/app/profile#me", ... }

Security and Privacy Considerations

UDNA inherits the security properties of the underlying DID methods and DIDComm. The following considerations apply specifically to the UDNA addressing layer.

Endpoint Confidentiality

UDNA addresses may expose service endpoints in plaintext within the resolved DID Document. For private services, implementers SHOULD use DIDComm-based routing or encrypted serviceEndpoint values.

Authentication

When accessing resolved endpoints, clients SHOULD demonstrate proof-of-possession of a private key associated with the resolving DID, or delegate access via a Verifiable Credential issued under [[VC-DATA-MODEL]].

Correlation and Privacy

UDNA addresses do not inherently create persistent trackable identifiers because DIDs can be rotated. However, repeated resolution of the same DID across different network contexts could enable correlation. To mitigate this, implementers SHOULD use pairwise DIDs per relationship where strong privacy is required.

Denial of Service

Resolvers SHOULD enforce rate limiting on DID resolution requests and employ aggressive caching policies to mitigate amplification attacks against DID method infrastructure.

Extensibility and Versioning

UDNA follows a minimal core + extension model. Core behavior is defined by this specification; optional capabilities are registered via the udna-ext query parameter (?udna-ext=https://…). The following extensions are known at the time of publication:

Batch Operations: Enables resolving multiple [=UDNA Address=]es in a single roundtrip, reducing resolution overhead in high-frequency use cases.
Gateway Forwarding: Defines behavior for relays and gateways that bridge UDNA resolution to legacy HTTP URLs, enabling progressive adoption in existing infrastructure.
Resource Integrity: Allows embedding cryptographic integrity hashes (e.g., SHA-256) for content-addressed resources referenced via a [=UDNA Address=].

Versioning of the core scheme is indicated via the udna-version query parameter. The default value for this specification is 1.0. Future versions MUST be backward-compatible at the resolution layer unless a breaking version increment is declared.

Relationship with Other Web Standards

UDNA is not intended to replace the following protocols but to unify them under a common addressing layer that respects decentralized identity. Implementations MAY embed UDNA support as a complementary naming and discovery mechanism.

Relationship of UDNA to related specifications and protocols.
Framework / Protocol	Focus	UDNA Role
[[DID-CORE]]	Identifier and DID Document	UDNA uses DID as the naming authority and cryptographic trust anchor.
[[DIDCOMM]]	Secure encrypted messaging	UDNA addresses can resolve to DIDComm service endpoints for encrypted channel establishment.
Solid (WebID) [[SOLID]]	Personal linked-data pods	UDNA can replace WebID URLs, enabling DID-based access control for Solid pods.
ActivityPub	Federated social web	UDNA provides identity-native addressing for actors and objects, removing dependency on domain-based actor URIs.
IPFS / IPNS	Content-addressed distributed storage	UDNA addresses can reference IPFS resources and supply DID identity context for access control.

Incubation Roadmap and Next Steps

The UDNA Community Group is actively incubating this specification. The following are current priorities for the 2026 incubation cycle:

Interoperability test suite — multi-language resolver implementations targeting JavaScript (Node.js), Rust, and Python reference libraries.
DID method profiling — concrete guidelines for did:web, did:key, and did:tdw to correctly expose UDNA service endpoints in their DID Documents.
Security review — formal analysis of the resolution algorithm, including potential endpoint confusion and injection attack vectors.
Integration pilots — live integration tests with Solid pod servers and Matrix homeservers to validate real-world addressing patterns and performance.

Example Implementations

This appendix is informative.

Resolving a UDNA Address in JavaScript

import { UDNAResolver } from '@udna/resolver';

const resolver = new UDNAResolver({
  didResolvers: {
    web: new WebDIDResolver(),
    key: new KeyDIDResolver()
  }
});

const address =
  "udna://did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1bZZw7pf9c7Dg5bKBz5tP/api/messages";

const resolved = await resolver.resolve(address);
console.log(resolved.targetUrl);
// → "https://didcomm.example.com/msg"

DID Document with UDNA Service Endpoints

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123",
  "service": [
    {
      "id": "#udna-root",
      "type": "UDNARoot",
      "serviceEndpoint": "https://udna-gateway.example/endpoint"
    },
    {
      "id": "#chat",
      "type": "UDNAChatService",
      "serviceEndpoint": "wss://chat.example/ws"
    }
  ]
}