Capability Tokens (IBCT)

Overview

An IBCT (Identity-Bound Capability Token) is a JWT-style envelope (with a JSON-LD body) signed by a delegator DID and carrying a scoped grant of authority to a delegatee DID.

Anatomy

1
{
2
  "header":  { "alg":"EdDSA", "typ":"ibct+jwt", "kid":"did:adi:0xA...#key-1" },
3
  "payload": {
4
    "iss":"did:adi:0xA...",
5
    "sub":"did:adi:0xA1...",
6
    "aud":"did:adi:0xCounterparty...",
7
    "iat": 1714128000,
8
    "nbf": 1714128000,
9
    "exp": 1714214400,
10
    "jti":"ibct-uuid-2",
11
    "capabilities":[
12
      { "action":"read",  "resource":"credentials",  "constraints":{ "schemaId":"schema-uuid-1" } },
13
      { "action":"verify","resource":"proofs",       "constraints":{} }
14
    ],
15
    "autonomyLevel": 2,
16
    "policy":{ "redelegationAllowed": false, "maxDepth": 0 }
17
  },
18
  "signature":"<base64url EdDSA>"
19
}

Verifying an IBCT

The standard verify endpoint (/agents/{did}/verify-delegation) checks:

1. Signature against iss’s DID Document assertionMethod.
2. nbf ≤ now < exp.
3. sub matches the verifier’s DID.
4. Each capability in the request is covered by an entry in capabilities[].
5. Autonomy required by the action ≤ autonomyLevel.
6. The chain back to a human principal is valid (recursive check).
7. Trust score floor (if your policy sets one).

Revoking

$
curl -X POST https://adid.dev/api/v1/agents/<delegator-did>/delegations/<jti>/revoke \
>
  -H "Authorization: Bearer $ACCESS_TOKEN"

The revoked-jti list is published in the platform’s standard revocation API and any verifier checking the IBCT will see allowed: false.

⚠️ Warning — IBCT revocation is eventually propagated to verifiers (cache TTL up to 60 s). For high-stakes capabilities, prefer short exp over long-lived IBCTs.