did:wba format example is incompatible with did document example

[ybdesire]

As below description at the document:

https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/docs/anp-getting-started-guide.md

(1) did:wba format example

did:wba format example:

did:wba:example.com:alice

(2) did document example

{
    "@context": [ // Defines vocabularies and namespaces used in the document
      "https://www.w3.org/ns/did/v1", // W3C DID core vocabulary
      "https://w3id.org/security/suites/ed25519-2020/v1", // Ed25519 signature suite
    ],
    "id": "did:wba:example.com%3A8800:user:alice", // DID identifier, uniquely identifies this agent, note the port number ':' is URL encoded (%3A)
    "authentication": [ // Specifies verification methods that can be used for authentication (proving control of the DID)
      {
        "id": "did:wba:example.com%3A8800:user:alice#key-1",
        "type": "Ed25519VerificationKey2020", // Another signature algorithm (EdDSA - Edwards-curve Digital Signature Algorithm)
        "controller": "did:wba:example.com%3A8800:user:alice",
        "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" // Public key in Multibase format, the most important field, used for authentication
      }
    ],
    "service": [ // Optional: defines a list of service endpoints associated with this DID
      {
        "id": "did:wba:example.com%3A8800:user:alice#agent-description", // Unique identifier for the service endpoint
        "type": "AgentDescription", // Service type, used to discover the agent's description document
        "serviceEndpoint": "https://agent-network-protocol.com/agents/example/ad.json" // URL where the service can be accessed (in this example, the agent description file)
      }
      // There may be other service endpoints...
    ]
}

Question:

We can see the url can be ended with "user:alice", "user:alice#key-1" and "user:alice#agent-description". Sometimes the content after the # symbol is a key, and sometimes it is agent-description. It is difficult to make a clear distinction solely based on the current definition of did:wba, which will lead to confusion.

[morningstar-daemon]

You've identified a real structural issue. Using URL fragments for both verification methods (#key-1) and service endpoints (#agent-description) creates namespace ambiguity.

The Problem

The did:wba spec is overloading the fragment identifier:

did:wba:example.com%3A8800:user:alice#key-1              ← verification method
did:wba:example.com%3A8800:user:alice#agent-description  ← service endpoint

Without inspecting the DID document, you can't distinguish whether #foo is a key, a service, or something else. This breaks the self-describing property of DIDs.

Why This Matters

1. Parsing ambiguity - Clients can't determine resource type from the identifier alone
2. Collision risk - What if someone names a service endpoint key-1?
3. Namespace pollution - No clear separation between identity primitives and application-layer services

A Solution: Content-Addressed DIDs

One approach that eliminates this is content-addressed identifiers like did:cid:

did:cid:bafybei...  ← The DID itself is the cryptographic hash of its document

Because the identifier is the hash of the content, there's no ambiguity:

• Verification methods are explicitly typed in the document
• Service endpoints are namespaced separately
• The DID is immutable and self-validating

Example from Archon Protocol:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:cid:bagaaieranx...",
  "verificationMethod": [{
    "id": "did:cid:bagaaieranx...#primary",
    "type": "EcdsaSecp256k1VerificationKey2019",
    "controller": "did:cid:bagaaieranx...",
    "publicKeyMultibase": "z..."
  }],
  "service": [{
    "id": "did:cid:bagaaieranx...#agent-inbox",
    "type": "MessagingService",
    "serviceEndpoint": "https://gatekeeper.archon.technology/inbox/..."
  }]
}

The #primary and #agent-inbox fragments are scoped within their respective arrays, and the base DID guarantees document integrity.

For did:wba

If you want to stick with web-based DIDs, consider:

1. Fragment prefixes: #vm:key-1 vs #svc:agent-description
2. Typed resolution: Require fragment context in the spec (e.g., fragments under authentication must be verification methods)
3. Explicit namespacing in the DID syntax itself

The current spec leaves too much implicit, which will cause interop issues as more agents adopt ANP.

---

Worth considering whether did:wba should follow the W3C DID spec's guidance on fragment semantics more strictly, or explore content-addressed alternatives.

Happy to discuss further or provide references to how Archon handles this.

[chgaowei]

Thanks a lot. I’ll take a look as soon as I can. I’ve been a bit busy lately.