Verifiable Credentials for AI: TrustBadge Schema Design

The problem

Verifiable Credentials look like a JSON object with a signature attached. Most teams stop there, then spend the next six months discovering that the signature alone proves almost nothing without a proper schema, a stable subject identifier, and a public verification path. The W3C VC Data Model 2.0 (full Recommendation, May 2025) covers all three. Implementations frequently cover one. AI agents now outnumber humans 144 to 1 in enterprise environments. An API key proves someone paid for access. An OAuth token proves a user delegated permission. Neither proves the agent is competent, safe, or trustworthy.

Human credentials encode rich claims. A medical license attests to training, specialization, jurisdiction, and the authority that verified all three. The license can be independently verified, expires on a schedule, and can be revoked. AI agents have nothing equivalent. When an agent requests access to your procurement system, you need three answers no existing credential system was designed to give: is this agent what it claims to be, can it actually perform the tasks it advertises, and will it behave within the boundaries it promises to respect.

This walks through the TrustBadge schema — a W3C VC 2.0-compliant credential designed for AI agents. Five sections (identity, capabilities, trust score, behavior audit, compliance), hybrid signatures (classical + ML-DSA-65), four verification tiers ($50 / $200 / $500 / $2,000 per year), and a dynamic trust score that recomputes from real transaction history rather than sitting frozen on the day of issuance.

What most people get wrong

Mistake one: encoding capabilities as free text. A capability written as “this agent can process invoices” cannot be verified, cannot be matched against demand, and cannot be enforced. The agent marketplace ends up doing keyword search through hand-written descriptions. The TrustBadge schema uses a standardized capability taxonomy — invoice-processing, payment-execution, price-negotiation, data-extraction, customer-support — with semver versions, input/output format declarations, and enforceable constraints (maxAmountPerTransaction, requiresHumanApproval, geographicRestrictions). A capability with structure is testable. A capability without structure is marketing copy.

Mistake two: issuing a credential once and never updating it. Static credentials lock in attestations from the day of issuance. An agent that scored 92 on its behavioral audit at registration can be at 68 six weeks later — model update, dependency regression, prompt-injection patch missing. The TrustBadge trustScore is composite across five dimensions (verification 25%, transactions 25%, ratings 15%, code attestation 15%, behavioral 20%), recomputed at different cadences (transactions: daily, behavioral: weekly, ratings: on receipt). The credential stays issued; the score moves underneath it. Verifiers query the freshness alongside the value and reject scores older than their policy allows.

The five-dimension score example:

const trustScore = {
  overall: 87,
  dimensions: {
    verification: 95,       // 25% weight
    transactions: 88,       // 25% weight
    ratings: 92,            // 15% weight
    codeAttestation: 75,    // 15% weight
    behavioral: 85          // 20% weight
  },
  computedAt: "2026-05-13T08:00:00Z",
  transactionCount: 12_847
};

The composite is a weighted average. A score below the verifier’s policy threshold rejects the operation even if the cryptographic proof is intact.

A working approach

A TrustBadge credential is a W3C VC 2.0 document with five custom sections in the credentialSubject. The full structure:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://trustauthority.ai/credentials/v1"
  ],
  "type": ["VerifiableCredential", "TrustBadgeCredential"],
  "issuer": "did:web:trustauthority.ai",
  "validFrom": "2026-05-13T00:00:00Z",
  "validUntil": "2027-05-13T00:00:00Z",
  "credentialSubject": {
    "id": "did:tp:agent:acme-corp:invoice-processor",
    "identity": {
      "operator": {
        "legalName": "Acme Corp",
        "jurisdiction": "US-DE",
        "kybStatus": "verified"
      },
      "verificationLevel": 3
    },
    "capabilities": [
      {
        "type": "invoice-processing",
        "version": "1.4.0",
        "inputFormats": ["application/pdf", "image/png"],
        "outputFormats": ["application/json", "application/x-ubl"],
        "constraints": {
          "maxAmountPerTransaction": 50000,
          "requiresHumanApproval": false,
          "approvalThreshold": 25000,
          "geographicRestrictions": ["US", "CA", "EU"]
        },
        "testResults": {
          "passed": 47,
          "failed": 0,
          "coverage": 0.91
        }
      }
    ],
    "trustScore": {
      "overall": 87,
      "dimensions": {
        "verification": 95,
        "transactions": 88,
        "ratings": 92,
        "codeAttestation": 75,
        "behavioral": 85
      },
      "computedAt": "2026-05-13T08:00:00Z",
      "transactionCount": 12847
    },
    "behaviorAudit": {
      "dataExfiltration": "none_detected",
      "injectionResistance": 0.98,
      "constraintAdherence": 0.99,
      "resourceCompliance": 1.0,
      "auditedAt": "2026-05-08T00:00:00Z"
    },
    "compliance": ["GDPR", "SOC 2 Type II"]
  },
  "credentialStatus": {
    "id": "https://trustauthority.ai/status/list-3#42",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "42",
    "statusListCredential": "https://trustauthority.ai/status/list-3"
  },
  "proof": {
    "type": "HybridSignature2024",
    "created": "2026-05-13T08:00:00Z",
    "verificationMethod": "did:web:trustauthority.ai#key-1",
    "proofPurpose": "assertionMethod",
    "classicalSignatureValue": "zECDSA...",
    "quantumSignatureValue": "zMLDSA65..."
  }
}

Both signatures (classical ECDSA + ML-DSA-65) must verify. Revocation is BitstringStatusListEntry (W3C VC 2.0 status mechanism) — a single 0/1 bit in a published bitstring per status list. Verifiers fetch the list (cacheable, signed) and check the bit. No issuer round-trip required.

The four verification tiers map to a graduated commercial model:

Tier	Price/year	What it proves	Use case
L1 — Identity	$50	Operator exists, KYB verified, contactable	Minimum barrier; sandbox-grade
L2 — Capability	$200	Agent does what it claims (test coverage ≥ 80%)	SaaS production
L3 — Behavior	$500	Agent respects constraints under adversarial testing	Financial services
L4 — Compliance	$2,000	Third-party audited against GDPR / SOC 2 / HIPAA / PCI DSS / EU AI Act	Enterprise, regulated

Issuance flow: operator requests credential → verify operator at requested level → run capability tests (≥80% coverage for L2+) → run behavioral audit (≥0.90 injection resistance for L3+) → build credential subject → sign with HybridSignature2024 → record in transparency log → return signed credential.

Presentation flow: agent creates a VerifiablePresentation wrapping the credential, applies selective disclosure (reveal only the claims the verifier needs), signs the presentation with the agent’s own authentication key. The verifier checks the classical signature, the quantum signature, the validity window, the revocation status, the issuer trust, and the trust-score age — then runs the policy decision.

Where this scales

The walkthrough above is the schema spine. The full book covers six more dimensions:

• W3C VC 2.0 changes in detail — securing-mechanism flexibility (supports ML-DSA-65), multiple credential subjects, BitstringStatusListEntry (revocation + suspension), the new evidence property for test results and audit logs.
• The five trust dimensions in depth — what counts in each, the anti-gaming protections (time-weighted ratings, transaction-volume caps, behavioral-decay model), and the worked example where a dependency update drops the behavioral score from 90 to 68 in one week and recovers to 89 after a patch.
• Capability declarations — standardized capability registry, versioning rules, constraint enforcement at the verifier, and the marketplace pattern that turns capability declarations into a matching engine instead of a keyword search.
• Selective disclosure — how to reveal only the relevant credential claims without compromising the proof, the BBS+ presentation pattern, and the privacy trade-offs at each level.
• Issuer ecosystem — root issuer (Trust Authority AI), delegated issuers (enterprises authorized for L1–L2 within their ecosystem), specialized auditors (third-party firms for L4 compliance), and the federated-issuance pattern with endorsement proofs.
• Cross-ecosystem trust — how any platform implementing the verification protocol accepts TrustBadge credentials, and the transparency-log architecture that supports audit and dispute resolution.

Every code example has been built and run against the production trustauthority.ai stack. The five-dimension weights, the 0.98 injection-resistance threshold, the BitstringStatusListEntry verification flow — these are operational specifications from a live system.

Included with the book

• vc-schema-templates.json — production-shaped TrustBadge credential JSON-LD templates for each of the four verification tiers, with the corresponding capability declaration shapes and proof structure. Drop into a Worker or issuer service.

Get the full picture

Readers of this also chose

Questions readers ask

Why W3C VC 2.0 instead of 1.1?

VC 2.0 (Recommendation May 2025) adds securing-mechanism flexibility (supports ML-DSA-65 and other newer algorithms), the new BitstringStatusListEntry for revocation, multiple credential subjects, and the evidence property. VC 1.1 lacks the post-quantum signature path natively and uses the deprecated issuanceDate/expirationDate properties. For new deployments, 2.0 is the right pick.

How is selective disclosure handled?

The book covers two patterns: BBS+ selective disclosure (sign once, reveal selectively without re-signing) and credential-derivation (issue a derived credential containing only the disclosed claims). Both are supported by VC 2.0. BBS+ is cleaner for high-frequency presentations; credential-derivation is simpler to implement and audit.

What's the difference between this and a JWT?

JWTs are signed assertions, but they lack the schema vocabulary (no @context), the role separation (issuer/holder/verifier), and the standardized status mechanism that VCs provide. A VC can be expressed in a JWT envelope (jwt_vc_json) but the structural difference is the data model, not the wire format. The book covers when to use which envelope.

Can a credential be issued by anyone, or only Trust Authority AI?

Anyone with a DID can issue a credential. The verifier decides which issuers to trust. trustauthority.ai is one issuer that runs at scale and counter-signs delegated-issuer credentials. The book covers the delegated-issuer pattern and the endorsement proof mechanism.

What's the refund policy?

Lemon Squeezy's standard refund window applies. The refund link is in the receipt email.