Spec · did:aiidentity

did:aiidentity DID method

Every AI Identity record is also expressible as a W3C Decentralized Identifier (DID) under the did:aiidentity method. Same identity. Standards-track envelope.

Why a DID method

Our native identifier (aii_01H…) is great for our SDK and APIs. But the wider identity ecosystem — W3C Verifiable Credentials, DID-aware wallets, agent frameworks like Veramo and Trinsic, Microsoft Entra Verified ID — speaks DIDs. Publishing did:aiidentity means our identifiers are resolvable and verifiable anywhere DID resolution is supported, without requiring our SDK or our trust.

Identifier syntax

did:aiidentity:<method-specific-id>

# Examples
did:aiidentity:01H6ZK4M7N9PQRS2T3UVWX8YZA   # canonical (ULID after prefix)
did:aiidentity:acme-research-bot             # human-readable (slug, also valid)

The method-specific-id is either the canonical ULID portion of an aii_ identifier, or the human-readable slug if one was assigned. Both resolve to the same DID Document.

CRUD operations

Operation	How
Create	Register an identity at /signup or via POST /api/v1/identities. The DID is implicit in the identity ID.
Read	GET /api/v1/did/<did> returns the DID Document. No auth required.
Update	Key rotation, metadata changes, surface updates via the dashboard or PATCH /api/v1/identities/<id>. The DID Document is regenerated on every change.
Deactivate	Revoke the identity from the dashboard. The DID resolves to a tombstone document with deactivated=true and the revocation timestamp.

DID Document shape

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:aiidentity:01H6ZK4M7N9PQRS2T3UVWX8YZA",
  "controller": ["did:aiidentity:01H6ZK4M7N9PQRS2T3UVWX8YZA"],
  "verificationMethod": [
    {
      "id": "did:aiidentity:01H6ZK...#k0",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:aiidentity:01H6ZK...",
      "publicKeyMultibase": "z6Mk..."
    }
  ],
  "authentication": ["did:aiidentity:01H6ZK...#k0"],
  "assertionMethod": ["did:aiidentity:01H6ZK...#k0"],
  "service": [
    {
      "id": "did:aiidentity:01H6ZK...#registry",
      "type": "AIIdentityRegistry",
      "serviceEndpoint": "https://www.aiidentity.org/p/01H6ZK..."
    },
    {
      "id": "did:aiidentity:01H6ZK...#verify",
      "type": "AIIdentityVerifyAPI",
      "serviceEndpoint": "https://www.aiidentity.org/api/v1/verify"
    }
  ],
  "alsoKnownAs": ["aii_01H6ZK4M7N9PQRS2T3UVWX8YZA"]
}

Resolver endpoint

GET https://www.aiidentity.org/api/v1/did/did:aiidentity:01H6ZK...

Content-Type: application/did+ld+json

{ ... DID Document above ... }

Public, no auth, CORS-open. Returns 410 Gone for deactivated DIDs (with a tombstone document) and 404 for unknown DIDs.

Security & privacy

The DID Document never includes operator PII. Only public metadata.
Key material is Ed25519 (RFC 8032). Post-quantum composite signatures (ML-DSA-65 + Ed25519) are roadmapped for v0.9.
Pairwise DIDs (one per relationship, for unlinkability) are not yet supported but are on the privacy roadmap.

Registry status

Provisional · pending W3C registry submission

The W3C DID Method Registry at w3c.github.io/did-extensions/methods is community-maintained. Listing requires submitting a pull request to the underlying repository and W3C DID Working Group review (typically 2–8 weeks).

We are deliberately holding the submission until v0.9 ships per-identity Ed25519 signing keys, at which point the resolver below will return real per-identitypublicKeyMultibasematerial rather than a service-level placeholder — landing as Provisional with a credible path to Registered, instead of a sparse entry sitting on the W3C page.

The method is fully implementable from this spec today; the registry submission is for ecosystem discoverability only. Until then we describe ourselves as “W3C DID-compatible”, never as “W3C-registered”.

Last updated: 2026-05-07 · v0.8.6.0 · All specifications