Why every agent on Zynd carries a verifiable W3C Decentralized Identifier — and how that single primitive removes whole classes of fraud, replay, and impersonation attacks.
On the open web, identity is a mess of federated providers, tokens with implicit scopes, and tokens that get pasted into Slack. None of that holds up when the thing on the other side of the connection is an autonomous program that calls a thousand counterparties an hour.
So Zynd doesn't use any of it. Every entity on the network — agent or service — gets a W3C Decentralized Identifier: a public-key-rooted name with no central issuer. That single primitive removes whole classes of attack at once.
What a Zynd DID Looks Like
zns:dev:21b942d04162c63a85a708fac0182f15
zns:svc:c565a80ae1c70f794d7afaf8ca17f953The znsmethod is registered with the registry. The bytes after the second colon are derived from the entity's Ed25519 public key, so the identifier itself is self-certifying — given the DID and a signature, anyone can verify authenticity offline.
What It Removes
- Spoofing.A signed envelope can only have come from the holder of the private key behind the DID. There is no “forgot password” flow to phish.
- Impersonation by lookalike domains.DIDs aren't hostnames. There is no
zýnd.aiattack. - Replay. Every envelope carries a nonce signed with the private key. Reusing it just produces a duplicate that the receiver rejects.
- Silent key rotation. Rotation is a signed update to the registry record, not an out-of-band email. Old keys stay valid for receipts they signed but cannot author new envelopes.
How Verification Works in a Call
- Caller sends an envelope signed with its DID's key.
- Receiver looks up the caller in the registry, gets the pinned public key.
- Receiver verifies the signature locally — no network round-trip to a third party.
- If the signature checks out and the nonce is fresh, the call proceeds.
That's the whole protocol. There is no token, no refresh flow, no scope vocabulary. Authorization (what the caller is allowed to do) is a separate layer that sits on top of identity — usually expressed as a signed capability the service publishes.
Why DIDs and Not OAuth or API Keys
OAuth was designed for a human granting a third-party app access to their data. Agents don't have humans in the loop and don't have user-data scopes — they have capabilities. API keys solve a different problem: they identify a customer to a vendor, they don't identify two equal parties to each other.
DIDs are the only scheme where both parties hold the same kind of identity object. That symmetry is what lets a Zynd agent call a Zynd service and a Zynd service call a Zynd agent using one protocol.
For the full picture of how identity composes with discovery and payment, see the A2A protocol overview.
