Capability Tokens (IBCT) | IDA — Identity for the AI Age

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

{
  "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:

Signature against iss’s DID Document assertionMethod.
nbf ≤ now < exp.
sub matches the verifier’s DID.
Each capability in the request is covered by an entry in capabilities[].
Autonomy required by the action ≤ autonomyLevel.
The chain back to a human principal is valid (recursive check).
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.