> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.adid.dev/llms.txt.
> For full documentation content, see https://docs.adid.dev/llms-full.txt.

# 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

```json
{
  "header":  { "alg":"EdDSA", "typ":"ibct+jwt", "kid":"did:adi:0xA...#key-1" },
  "payload": {
    "iss":"did:adi:0xA...",
    "sub":"did:adi:0xA1...",
    "aud":"did:adi:0xCounterparty...",
    "iat": 1714128000,
    "nbf": 1714128000,
    "exp": 1714214400,
    "jti":"ibct-uuid-2",
    "capabilities":[
      { "action":"read",  "resource":"credentials",  "constraints":{ "schemaId":"schema-uuid-1" } },
      { "action":"verify","resource":"proofs",       "constraints":{} }
    ],
    "autonomyLevel": 2,
    "policy":{ "redelegationAllowed": false, "maxDepth": 0 }
  },
  "signature":"<base64url EdDSA>"
}
```

| Field                        | Description                                    |
| ---------------------------- | ---------------------------------------------- |
| `iss`                        | Delegator DID.                                 |
| `sub`                        | Delegatee DID.                                 |
| `aud`                        | Optional — audience (counterparty) constraint. |
| `iat` / `nbf` / `exp`        | Standard JWT timestamps.                       |
| `jti`                        | Unique token id (used for revocation).         |
| `capabilities[]`             | Action × resource × constraints triples.       |
| `autonomyLevel`              | Cap on delegatee autonomy.                     |
| `policy.redelegationAllowed` | If false, delegatee cannot mint child IBCTs.   |
| `policy.maxDepth`            | Cap on further sub-delegation depth.           |

#### 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

```bash
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.