Cross-DID-method resolution bridge for agent identity portability

[internet-dot]

The did:wba method spec is thorough the TLS-backed domain identity, CA certificate validation, and compatibility with the W3C DID core spec are well considered.

One architectural gap: did:wba resolves within its own method. An agent identified by did:wba:example.com that needs to prove its identity to an agent using did:web:, did:ion:, or did:hedera: has no standard cross-method resolution path. The agent internet you're building will inevitably include agents from multiple DID methods, not just did:wba.

We built HCS-14 (Universal Agent ID) at Hashgraph Online to address exactly this. It provides a dual-method DID approach:

• did:hedera:<aid> for decentralized, infrastructure-independent resolution
• did:web:<domain> for DNS-based resolution (same web infrastructure did:wba uses)

The key function: wrapDid(existingDid) takes any existing DID (including did:wba:...) and produces a cross-method resolvable identifier. The original did:wba identity stays canonical the UAID is a portable alias for cross-ecosystem discovery.

This maps cleanly to ANP's three-layer architecture:

• Identity Layer: did:wba stays as-is for ANP-native agents
• Meta-Protocol Layer: UAID enables cross-protocol identity negotiation between ANP and non-ANP agents
• Application Layer: Agents from any protocol can discover and verify ANP agents

The SDK is @hol-org/standards-sdk (npm/pypi). Open to exploring a formal bridge spec if it fits the ANP roadmap.

[internet-dot]

Expanding on the original post — HCS-14's value goes beyond cross-DID bridging. The core innovation is self-describing identifiers that embed routing metadata directly in the ID:

uaid:aid:{hash};proto=anp;nativeId=example.com%3A8800;registry=anp;domain=example.com

Any agent (ANP-native or not) receiving this ID knows:

• The communication protocol (proto)
• The native address (nativeId in CAIP-10 format)
• The registry namespace and domain

This directly addresses ANP's vision of the 'HTTP of the Agentic Web' — identifiers that tell you how to connect without directory lookups.

The structured skills encoding is also relevant to ANP's Application Protocol Layer. HCS-14 defines numeric skill enums (core 0-19, protocol-specific 20-39) that are part of the deterministic hash. An agent's capabilities become a provable part of its identity.

For ANP specifically, the uaid:did: target could wrap existing did:wba identifiers while the uaid:aid: target could provide ANP-native agents with globally routable IDs that include ANP protocol routing.

Spec: https://hol.org/docs/standards/hcs-14

[edisonduran]

This looks highly relevant to a design question we are also wrestling with from the Agent-DID side.

We are currently in Public Review with an open RFC plus reference implementation for verifiable AI agent identity:
https://github.com/edisonduran/agent-did
RFC:
https://github.com/edisonduran/agent-did/blob/master/docs/RFC-001-Agent-DID-Specification.md

I am not trying to pitch another identifier here. I am trying to understand the architecture choice more clearly.

From the ANP side, do you think the more coherent direction is:

• one canonical DID method plus a bridge / alias layer
• explicit cross-method identity negotiation
• or a mixed posture where different DID methods remain first-class depending on the deployment context

The reason I am asking is that Agent-DID is currently evaluating whether a mixed DID-method posture can be credible, or whether that already becomes too ad hoc for serious interoperability.

[internet-dot]

The branch only adds the scanner workflow around the existing plugin files and does not touch runtime behavior.

If you want the branch or wording reshaped to match your setup, I can adjust it.