Deactivate a DID

When to use

You no longer want anyone to trust this DID for new credentials/presentations. Deactivation is a soft-delete: the DID Document remains resolvable but is flagged deactivated: true, and the platform refuses to use it for issuance, presentation, or DIDComm.

Before you begin

• You own the DID.
• You have no active credentials issued by this DID that you intend to revoke first (revoke them before deactivating; afterwards the deactivated DID cannot be used to sign revocation entries).

Steps

1. Open /dids/:did.
2. Click Deactivate (red button at the bottom).
3. Confirm in the modal — type the DID into the confirmation field.
4. The portal calls DELETE /api/v1/dids/{did} (did.go:166). The handler emits DIDDeactivated on the registry.

API & SDK

$
curl -X DELETE https://adid.dev/api/v1/dids/did:adi:0x9a2c... \
>
  -H "Authorization: Bearer $ACCESS_TOKEN"

1
await client.deactivateDID('did:adi:0x9a2c...');

Verify

Resolution still works, but the document metadata shows deactivated: true. Per W3C DID Core 1.0 §5.2, this is the canonical end state.

Troubleshooting

3.1.7. Adding & Revoking Delegates ##### When to use

A delegate is a different DID authorised to act on behalf of yours for a specific purpose (e.g. an agent DID that may sign DIDComm messages on your behalf, or an organisational sub-DID that may issue credentials under your authority). Delegation is the cleaner alternative to sharing keys.

Before you begin

• You own the principal DID.
• The delegate’s DID is resolvable.

Steps

1. Open /dids/:did and scroll to Delegates.
2. Click Add delegate. 3. Fill:
   • Delegate (delegate) — the delegate’s DID or address, e.g. did:adi:0x4f3a....
   • Type (delegateType) — e.g. sigAuth, veriKey (per ERC-1056 conventions).
   • Validity (validity) — number of seconds (default 86400 = 24 h).
3. Save. The portal calls POST /api/v1/dids/{did}/delegates (did.go:290). The body is the params object directly: { delegateType, delegate, validity }.

API & SDK

$
curl -X POST https://adid.dev/api/v1/dids/did:adi:0x9a2c.../delegates \
>
  -H "Authorization: Bearer $ACCESS_TOKEN" \
>
  -H "Content-Type: application/json" \
>
  -d '{
>
    "delegateType":"sigAuth",
>
    "delegate":"did:adi:0x4f3a...",
>
    "validity": 86400
>
  }'

$
curl -X DELETE https://adid.dev/api/v1/dids/did:adi:0x9a2c.../delegates \
>
  -H "Authorization: Bearer $ACCESS_TOKEN" \
>
  -H "Content-Type: application/json" \
>
  -d '{ "delegateType":"sigAuth", "delegate":"did:adi:0x4f3a..." }'

Verify

$
curl -H "Authorization: Bearer $ACCESS_TOKEN" \
>
  https://adid.dev/api/v1/dids/did:adi:0x9a2c.../delegates

Returns an array [{ delegate, delegateType, validUntil }].

Troubleshooting

3.1.8. DID Attributes ##### When to use

You want to attach a small piece of structured data to your DID — e.g. a service URL, a name, a hash — without modifying the DID Document directly. This mirrors the ERC-1056 attribute mechanism: signed key/value pairs anchored on chain.

Before you begin

• You own the DID.
• The attribute name is short (≤32 bytes) and meaningful.

Steps

1. Open /dids/:did and scroll to Attributes.
2. Click Set attribute.
3. Enter:
   • Name — e.g. did/svc/HubService, did/auth/email.
   • Value — string or hex-encoded bytes.
   • Validity — seconds.
4. Save. Calls POST /api/v1/dids/{did}/attributes (did.go:369).

API & SDK

$
curl -X POST https://adid.dev/api/v1/dids/did:adi:0x9a2c.../attributes \
>
  -H "Authorization: Bearer $ACCESS_TOKEN" \
>
  -H "Content-Type: application/json" \
>
  -d '{
>
    "name":"did/svc/AgentCard",
>
    "value":"https://my.agent/.well-known/agent.json",
>
    "validity":2592000
>
  }'

$
curl -X DELETE https://adid.dev/api/v1/dids/did:adi:0x9a2c.../attributes \
>
  -H "Authorization: Bearer $ACCESS_TOKEN" \
>
  -H "Content-Type: application/json" \
>
  -d '{
>
    "name":"did/svc/AgentCard"
>
  }'

Verify

Resolve the DID; the attribute is exposed via the didDocumentMetadata.attributes array (or whatever the resolver returns — see §3.1.9).

Troubleshooting

If a value isn’t appearing, the most common cause is a stale cache. Force a re-resolve with:

$
curl https://adid.dev/api/v1/dids/resolve/did:adi:0x9a2c...?refresh=true

3.1.9. Universal DID Resolver Tool ##### When to use

You need to fetch the DID Document for any DID — yours, someone else’s, or a DID from a different method entirely. The universal resolver is the public, no-auth endpoint that does this.

Before you begin

Nothing required. The endpoint is unauthenticated.

Steps

1. Open the DID Resolver page in the portal (/tools/did-resolver) — or just call the endpoint directly.
2. Paste the DID into the input field.
3. Click Resolve.
4. The portal calls GET /api/v1/dids/resolve/{did} (did.go:29, registered at router.go:74).

Supported methods

API

$
curl https://adid.dev/api/v1/dids/resolve/did:adi:0x9a2c...

1
// Universal resolver — works for did:adi, did:key, did:web, did:ethr.
2
const { didDocument, didDocumentMetadata } =
3
  await client.resolveAny('did:adi:0x9a2c...');
4
5
// Or, for did:adi only (authenticated):
6
// const didDocument = await client.resolveDID('did:adi:0x9a2c...');

Response shape (per W3C DID Resolution):

1
{
2
  "didDocument":         { "@context":[...], "id":"did:adi:0x9a2c...", ... },
3
  "didDocumentMetadata": { "created":"...", "updated":"...", "deactivated":false, "txHash":"0x..." },
4
  "didResolutionMetadata":{ "contentType":"application/did+ld+json" }
5
}

Verify

Compare the returned key fingerprint against an out-of-band channel (e.g., the issuer’s website, a printed business card). DID Documents are public, but their binding to a real-world entity is your responsibility.

Troubleshooting