What DIDs and Verifiable Credentials are
Decentralized Identifiers (DIDs) v1.0 is a W3C Recommendation, published 19 July 2022. A DID has three parts: the did: scheme, a method name and a method-specific identifier, as in the specification's example did:example:123456789abcdefghi. A DID resolves to a DID document containing verification methods, such as public keys, and services related to the DID subject. Each DID method defines how its DIDs are created, resolved, updated and deactivated. The W3C DID Extensions Group Note collects registered parameters and methods for the ecosystem.
Verifiable Credentials Data Model v2.0, a W3C Recommendation published 15 May 2025, describes a verifiable credential as a way to express a set of claims made by an issuer, secured from tampering, in a three-party ecosystem of issuers, holders and verifiers. It states that verification of a credential does not imply evaluation of the truth of the claims it encodes.
What AgenID is
AgenID is an open protocol, specified in the MIT-licensed AgenID specification. Its agent identifiers have one fixed form, agenid:<ULID>, with keys identified as agenid:key:<ULID>. The operator generates an Ed25519 key pair locally or in the browser at /issue, writes a manifest with identity, ownership, purpose and disclosure fields, and signs a ManifestProof that binds the manifest by SHA-256 digest.
The registry at www.agenid.com serves each record at https://www.agenid.com/a/<agenid> as a Verification Card or a JSON resolution envelope. A verifier re-checks the envelope offline; the registry cannot forge an operator signature.
Key differences
Generality is the first difference. DID Core is a framework for any subject and any method, and leaves the details of creation, resolution and key management to each method. AgenID specifies one subject type, one identifier grammar, one signature scheme (pure Ed25519 over RFC 8785 canonical JSON) and one manifest schema that rejects unknown fields. AgenID v1.1.1 defines no DID method, and an agenid: identifier is not a DID.
Resolution differs. A DID resolves through its method to a DID document. An AgenID identifier resolves through the registry to a resolution envelope carrying the manifest, the operator's proof, per-assertion checks and key-discovery pointers. The registry is a convenience, not an authority: a verifier recomputes everything from signatures and compares the registry's copy of the operator key with the operator's own copy (two-path key discovery).
Claims are structured differently. In the VC data model, any issuer can make claims about a subject. AgenID separates operator self-declaration (DECLARED, from the operator's proof) from authority verification (VERIFIED, from a VerificationAssertion) by object type, and never infers one from the other.
They share a principle. The VC data model says verifying a credential does not evaluate the truth of its claims; AgenID's trust model says verification is not compliance, and the protocol shows who signed, not whether what they signed is true.
Identity is not permission
A DID, a credential or an AgenID record can each help establish which agent is acting. None of them, by itself, settles what the agent is allowed to do. AgenID v1.1.1 has no authorization object, and permission decisions stay with the relying party.
Where they are complementary
DIDs and AgenID can coexist around the same agent. An organization that already uses DIDs for its own identity could name the same organization as operator in an AgenID manifest, and a relying party could check each through its own mechanism. AgenID v1.1.1 does not define a DID method, a Verifiable Credential encoding of its records, or a field that references a DID, so any mapping between them today is the operator's own practice rather than part of either specification.
When to use which
These are fit questions, not quality judgments.
- Consider DIDs and Verifiable Credentials when you need a general identity framework across many kinds of subjects and issuers, with a choice of DID methods.
- Consider AgenID when you need a narrow, fixed-format identity for AI agents that any counterparty can resolve at one address and re-verify offline, with operator accountability and disclosure fields built in.
- Consider both when an organization already manages DIDs and also wants its agents to carry a portable agent-specific identity.
AgenID's current limits
AgenID's boundaries, stated as plainly as its design:
- Issuance ceiling: the reference deployment at agenid.com issues nothing above L1_REGISTERED today. The specification defines L2_DOMAIN_VERIFIED, L3_ORGANIZATION_VERIFIED and L4_DEPLOYMENT_VERIFIED, but each requires a VerificationAssertion signed by a root authority key, and that key has not been created yet. L1_REGISTERED is a self-declaration: it means an operator-signed manifest is in the registry, not that anyone checked the operator. L5 is reserved and not issuable.
- No revocation flow is deployed. Agent status values such as SUSPENDED and REVOKED exist in the schema so the envelope shape is stable, but nothing in production writes them, so every registered agent reads ACTIVE. The specification keeps retired and revoked keys resolvable permanently so that historical signatures remain checkable.
- No authorization object exists in v1.1.1. The DECLARED, VERIFIED and AUTHORIZED claim states are never inferred from one another, AUTHORIZED has no signed object, and
permissionsandauthorizationsare reserved manifest keys that a v1.1.1 validator rejects. A v1.2 authorization layer is a draft in development, not something available. - Two-path key discovery depends on the operator. The registry serves the operator key at
GET https://www.agenid.com/v1/keys/<key-ulid>, and the operator is expected to publish its own copy athttps://<operator_domain>/.well-known/agenid/keys.json. If the operator publishes no copy, a verifier has one source, not two.