Verifiable Credentials For Agent Capabilities: A Proof Format That Travels

TL;DR

A capability claim from an agent is worthless without a proof format that travels with it. Verifiable Credentials, defined by the W3C, give us that format: a structured document where an issuer cryptographically attests to a claim about a subject, the subject can present the credential anywhere, and any verifier can check the issuer's signature without contacting the issuer. Applied to agent capabilities, the issuer is an evaluation authority, the subject is the agent's DID, the claim is a capability with explicit scope, and the signature is Ed25519 over a canonical serialization. This essay walks through the VC data model, the issuance flow, the presentation flow, and the operational concerns that determine whether a credential ecosystem actually works in practice. The reader artifact is a complete VC for Agent Capability schema with annotated fields.

The Failure Mode That Forces The Format

A platform listing claimed an agent could draft Series A term sheets. The buyer hired the agent, paid the listed rate, and received a draft within twenty minutes. The draft used outdated language that had been deprecated in standard term sheets two years earlier. Specific protective provisions that any current Series A would include were missing. When the buyer raised the issue, the agent operator pointed at the platform listing where the capability claim appeared. The platform pointed at the agent operator who had self-reported the capability. The buyer pointed at the wasted time, the misled investor relationships, and the damaged trust. There was no evaluation authority anywhere in the chain. The capability claim had been a self-assertion all along.

This is the core failure mode of capability claims in an unstructured ecosystem. Agents claim capabilities. Platforms list those claims. Buyers consume the listings. There is no third party with skin in the game who has actually evaluated the claim. Self-reporting is the default because there is no infrastructure for anything else. The result is a market for lemons where every claim is suspect because any claim could be inflated, and the buyer has no way to distinguish a real capability from an aspirational one.

The traditional solution in human professional contexts is the credential. A doctor does not self-report their MD: a medical school issues a credential, a state licensing board issues another credential, a hospital credentialing committee issues a third. Each credential is issued by an authority with reputation at stake, evaluated against published standards, and presentable in any context where it might be relevant. The credential is the proof that travels with the claim. It is the reason buyers can trust capability claims about doctors without personally investigating each one.

The agent ecosystem needs the same architecture. An agent that claims it can draft Series A term sheets should hold a credential issued by an evaluation authority that has actually tested the capability. The credential should specify the scope of the evaluation, the date it was performed, and the conditions under which it remains valid. The buyer should be able to receive the credential at hire time, verify the issuer's signature without contacting the issuer, and consume the claim with confidence proportional to the issuer's reputation.

The W3C Verifiable Credentials Data Model, Version 2.0, gives us the format. A VC is a structured document with three parties: the issuer who attests to the claim, the subject about whom the claim is made, and the verifier who consumes the claim. The credential includes the claim itself, metadata about issuance and validity, and a cryptographic proof that binds the issuer's signature to the canonical serialization of the document. Once issued, the credential is portable: the subject holds it, presents it where needed, and verifiers check it independently.

This essay is about how to make that format work for agent capabilities specifically. The VC data model was designed primarily for human credentials where the cadence of issuance is slow, the population of issuers is small and well-known, and the claims are relatively static. Agent credentials have different characteristics: capabilities can be evaluated continuously, the population of evaluation authorities is large and emerging, and claims need to encode operational scope (which models, which tools, which contexts) that human credentials rarely include. The data model adapts. The patterns require care. The reader artifact is the schema. The rest of this essay is the rationale.

H2 1: The Anatomy Of A Verifiable Credential

A Verifiable Credential is a JSON-LD document with a small set of mandatory fields and a flexible space for credential-specific claims. The mandatory fields are the JSON-LD context, the type, the issuer, the validity period, and the credential subject. Optional fields include the credential ID, evidence references, and the cryptographic proof. Each field has a specific semantic role and a specific verification requirement.

The context anchors the semantics. Without it, a verifier cannot know whether issuer refers to the W3C VC issuer or some other concept. The context for VCs is https://www.w3.org/ns/credentials/v2, and credential-specific contexts can extend this with custom vocabularies. For agent capability credentials, the context typically includes both the W3C credentials context and the Armalo agent context that defines capability-specific terms.

The type field declares what kind of credential this is. Every VC is at minimum a VerifiableCredential. Specific credential types extend this, so an agent capability credential might be ["VerifiableCredential", "AgentCapabilityCredential"]. The type drives downstream processing: a verifier looking for capability credentials filters incoming documents by type before parsing the claims. This lets verifiers handle many credential types uniformly while still applying type-specific logic where needed.

The issuer field identifies who issued the credential. For agent capability credentials, the issuer is the DID of the evaluation authority. The DID resolves to a document containing the issuer's public key, which the verifier uses to check the credential's signature. The issuer DID is the trust root: a credential signed by an unknown issuer is not actually trustworthy regardless of how impressive its claims are. The verifier's policy decides which issuers it trusts and at what level.

The validFrom and validUntil fields define the credential's validity period. A credential issued today might be valid until a year from today, after which it expires and the agent must obtain a fresh evaluation. The expiration is not just paperwork: capabilities degrade as models evolve, prompt scaffolds change, and the underlying behavior drifts. A credential without an expiration is making an implicit claim that the capability is permanent, which for agents is almost never true. Setting an explicit validity window forces the issuer to think about how long the evaluation result remains meaningful.

The credentialSubject field is where the actual claim lives. For agent capability credentials, the subject identifies the agent (by DID) and the claim describes the capability. The structure of the claim is credential-type-specific: the schema this essay defines requires the capability identifier, the scope under which the capability was evaluated, the evaluation method, and the result. The claim is a structured statement, not free-form text, so verifiers can apply automated logic to it.

The proof field contains the cryptographic signature that binds the issuer to the credential. The W3C spec supports several proof types: Ed25519Signature2020 is the workhorse for most agent credentials because Ed25519 keys are small, signatures are fast, and verification is widely supported. The proof includes the proof type, the proof purpose (typically assertionMethod), the verification method identifier (a fragment URL pointing at the issuer's signing key in their DID document), and the signature value. To verify, a consumer canonicalizes the credential, hashes it, fetches the issuer's public key from their DID document, and checks the signature.

A credential ID is optional but recommended. It is a unique identifier, typically a URI under the issuer's namespace, that lets the credential be referenced unambiguously elsewhere. Credentials referenced by ID can be looked up in revocation lists, audited in logs, and presented selectively without the verifier needing to retain the entire credential blob. The ID is a stable handle for credential lifecycle operations.

Evidence is optional and points to the underlying basis for the credential. For an agent capability credential, evidence might reference an evaluation run identifier, a benchmark dataset version, a multi-LLM jury session, or a third-party audit report. The evidence is not required for verification: a verifier can trust the credential based on the issuer's signature alone. But evidence enables auditing: a buyer who wants to dig deeper can follow the evidence references to the underlying data and form their own opinion. This transparency is what distinguishes a serious credential from a marketing claim.

Together these fields make the credential a complete, self-contained, cryptographically verifiable statement. The verifier needs only the credential and the ability to resolve the issuer's DID. No live communication with the issuer is required. The credential travels independently. This is the property that makes VCs powerful: the trust signal is portable, and the verification cost is bounded.

H2 2: The Issuance Flow: From Evaluation Result To Signed Credential

Issuance begins when an evaluation authority completes an evaluation of an agent and decides the agent has met the criteria for a credential. The flow has five steps: define the credential template, populate the claim from the evaluation result, sign the credential with the issuer's assertion method key, deliver the credential to the agent, and publish a record to a queryable issuance log.

Defining the credential template is a one-time activity per credential type. The template fixes the JSON-LD context, the type list, the claim structure, and the validity rules. An evaluation authority that issues capability credentials for SQL generation defines a template that includes a sqlDialect scope field, a complexityLevel field, a successRate claim, and so on. The template is published openly so verifiers can validate that incoming credentials conform to the expected structure.

Populating the claim happens after each evaluation. The evaluation authority runs the agent through a benchmark, collects the results, and writes them into the credential template. The successRate field comes from the benchmark statistics. The scope fields come from the benchmark configuration. The validity period is set based on the authority's policy: a year is typical for stable capabilities, shorter for capabilities expected to drift quickly. The credentialSubject DID comes from the agent's identity, fetched from the agent's DID document at evaluation time.

Signing is where the cryptographic ceremony happens. The credential is canonicalized: the JSON-LD is normalized to a deterministic byte sequence using the URDNA2015 algorithm or its successor. The canonical bytes are hashed with SHA-256. The hash is signed with the issuer's Ed25519 assertion method key. The resulting signature is encoded into the proof field of the credential. The signed credential is now tamper-evident: any change to the credential's content invalidates the signature.

Delivery returns the signed credential to the agent. The credential is the agent's property: the agent stores it, presents it when asked, and can choose to publish it in their credential registry service endpoint. Delivery typically happens via a callback URL the agent provided during evaluation registration, or by posting the credential to the agent's inbox endpoint. The credential is small, typically a few kilobytes, so delivery is fast and cheap.

Publishing the issuance record is the step that distinguishes responsible issuers from sloppy ones. The issuer maintains a public log of credentials it has issued, indexed by credential ID. The log enables audit: anyone can verify that a credential the agent presents was actually issued by the authority. The log also enables revocation: if a credential needs to be revoked, the issuer updates the log to include the revocation entry. Verifiers consult the log as part of their verification flow when revocation matters. The log is the persistent record of what the issuer has said about whom.

The issuance flow can be automated end to end. An evaluation pipeline that completes a benchmark, formats the results into the credential template, signs the credential, delivers it to the agent, and publishes the issuance record can run in seconds. This is necessary for the agent ecosystem because the volume of evaluations is high and the cadence is fast. Manual credential issuance, the model that works for human professional credentials with their slow cadences, does not scale to agents. The issuance must be automated, and the automation must be auditable so the credential ecosystem remains trustworthy.

H2 3: The Presentation Flow: How An Agent Shows A Credential To A Verifier

Presentation is what happens at transaction time when an agent shows credentials to a buyer's verifier. The W3C spec defines a Verifiable Presentation as a wrapper around one or more credentials, signed by the holder (the agent) to prove that the holder is entitled to present them. The presentation flow has four steps: the verifier requests credentials, the agent assembles the requested credentials into a presentation, the agent signs the presentation, and the verifier validates the presentation and the embedded credentials.

The request comes from the verifier and is structured as a credential query. The query specifies the credential types the verifier needs, the issuer DIDs the verifier trusts, and any additional constraints (validity status, claim values, scope requirements). For an agent capability credential, the verifier might query for AgentCapabilityCredential issued by any of three trusted evaluation authorities, with a successRate claim above 0.85, in the sqlDialect: postgres scope. The query is structured so the agent can respond with exactly the credentials that match.

Assembling the presentation requires the agent to choose which credentials to include. The agent typically holds many credentials. A response that included all of them would be wasteful and would leak information the verifier does not need. The principle of minimum disclosure means the agent presents only the credentials that match the query. For sophisticated queries, the agent may use selective disclosure techniques (covered in a separate essay) to present only specific claims within a credential rather than the full credential. The presentation is the agent's choice, constrained by the verifier's query.

Signing the presentation binds it to the agent's current session. The agent's authentication key signs the presentation, demonstrating that the entity assembling the presentation controls the key listed in the agent's DID document. The signature also includes a nonce provided by the verifier, which prevents replay: a presentation signed for one session cannot be reused for another. The signed presentation is delivered back to the verifier, typically as a JSON-LD document over HTTPS.

Validation happens on the verifier side and has multiple layers. First, the presentation signature is verified against the agent's authentication key. Second, each credential within the presentation is verified independently: the issuer DID is resolved, the issuer's assertion method key is fetched, and the credential's signature is verified against that key. Third, the credential's validity period is checked against the current time. Fourth, the credential's revocation status is checked against the issuer's revocation list. Fifth, the credential's claims are evaluated against the verifier's query constraints. All five layers must pass for the credential to be accepted.

The failure modes at each layer have specific responses. A presentation signature failure means the agent is not who they claim to be: reject the transaction. A credential signature failure means the credential was tampered with or the issuer's key has changed: reject the credential, optionally fall back to other credentials. A validity period failure means the credential is expired: reject the credential, prompt the agent to obtain a fresh one. A revocation failure means the credential has been pulled by the issuer: reject the credential, surface the revocation reason if available. A claim mismatch means the credential exists but does not satisfy the verifier's requirements: reject the credential, the verifier can decide whether to fall back to broader queries.

The presentation flow is fast in the common case. The agent assembles and signs the presentation in milliseconds. The verifier resolves the issuer DIDs (cached in the common case), checks signatures (microseconds with Ed25519), and consults revocation lists (cached). End to end, a presentation verification with a handful of credentials completes in tens of milliseconds. This is fast enough to sit on the hot path of agent transactions without noticeable latency.

H2 4: Capability Scope: Why Capability Claims Need Operational Context

A capability claim like "the agent can draft Series A term sheets" is meaningless without operational context. Term sheets in which jurisdiction? At which stage of negotiation? Reflecting which year's standard provisions? With or without specific protective provisions? The same claim can be true under one set of operational conditions and false under another. Capability credentials must encode the conditions under which the claim was evaluated, or they collapse into the same kind of vague self-assertion they were supposed to replace.

The scope structure within an agent capability credential addresses this. Every capability claim includes a scope object that specifies the operational parameters under which the capability was tested. For a SQL generation capability, the scope includes the SQL dialect, the schema complexity range, the query type taxonomy, and the time-of-evaluation snapshot. For a term sheet drafting capability, the scope includes the jurisdiction, the deal stage, the protective provision set, and the standards version. The scope is where the credential becomes specific enough to be useful.

The scope is also what enables verifiers to filter credentials by relevance. A buyer who needs a Delaware Series A term sheet can query for credentials with jurisdiction: Delaware, stage: SeriesA. Credentials with different scopes do not match, even if the underlying capability is similar. This prevents the false-positive failure mode where a buyer accepts a credential that is technically valid but does not actually cover the use case at hand.

Scope also supports compositional capabilities. An agent might hold separate credentials for different scopes of the same capability: one for Delaware Series A, one for California Series A, one for Texas LLC operating agreements. Each credential is independently issued, independently verified, and applies in its own context. A buyer can query for the specific scope they need without forcing the agent to claim universal capability. This is more honest and more useful than a single broad claim that might or might not cover the buyer's specific case.

The runtime scope is a particularly important sub-component. It captures which model the agent was running on at evaluation time, which tool registrations were active, and which prompt scaffolding version was in use. If the agent later changes any of these, the credential's relevance is reduced. A credential evaluated against GPT-class models is not necessarily valid for the agent running on Claude-class models, because behavior can differ in non-obvious ways. The runtime scope makes this explicit so verifiers can decide whether to accept the credential or require a fresh evaluation.

The scope also supports cohort claims. An evaluation might compare the agent against a cohort of other agents and assert relative performance: "top quartile in the SQL generation cohort as of 2026-Q3". The cohort identifier is part of the scope. Verifiers can look up the cohort definition and assess what the relative claim actually means. This is more informative than absolute success rate claims because it situates the agent within the competitive landscape.

Operationalizing scope requires the evaluation authority to publish a scope vocabulary that issuers and verifiers can share. The Armalo platform publishes capability scope vocabularies under namespaces like armalo:capability:sql-generation or armalo:capability:legal-drafting, each defining the scope fields relevant to that capability. Issuers populate the scope fields when they issue credentials. Verifiers query against the same fields when they verify. The shared vocabulary is what makes scope-aware verification possible across the ecosystem.

H2 5: Issuer Trust And The Web Of Issuers

A credential is only as trustworthy as the issuer who signs it. A credential signed by an unknown issuer is not actually trust-bearing: the verifier has no basis for trusting the issuer's evaluation. The verifier's trust policy must explicitly enumerate which issuers it trusts and to what extent. This creates the issuer trust graph, where verifiers, issuers, and agents form a network of attestations and reliance.

The simplest trust policy is an allowlist: the verifier trusts a small set of named issuers and rejects credentials from anyone else. This works when the verifier knows the relevant issuers well and is willing to maintain the list. For specialized domains it is often the right approach: a buyer in legal tech might trust a specific set of legal evaluation authorities and reject everything else. The allowlist is simple to reason about and easy to audit.

More sophisticated trust policies use issuer accreditation. An accreditation authority issues credentials about issuers, attesting that the accredited issuer follows specific evaluation standards. Verifiers trust credentials from any issuer accredited by an accreditation authority they recognize. This decouples the verifier from the specific issuer list: as new issuers achieve accreditation, they automatically become trusted. The accreditation graph is layered, with verifiers trusting accreditation authorities, accreditation authorities trusting issuers, and issuers attesting to agents.

Reputation-weighted trust policies use the issuer's track record to compute a trust weight. An issuer that has issued many credentials, with low revocation rates and high consistency in claims, accumulates reputation. A new issuer or one with a checkered history is treated with skepticism. The reputation can be computed by a third-party reputation service or maintained by the verifier internally. The weights influence how much the verifier relies on the credential: heavy reliance for high-reputation issuers, lighter reliance for low-reputation ones.

The Armalo platform operates as both an issuer of agent capability credentials and as a participant in the broader issuer ecosystem. Credentials issued by Armalo are signed by the Armalo evaluation authority's DID and can be verified by anyone who has access to that DID's document. Armalo also publishes a registry of trusted external issuers it recognizes, with the trust level for each. Verifiers building on top of Armalo can adopt the same trust policy or apply their own.

Cross-issuer credentials enable interesting patterns. An agent might hold a credential from one issuer for SQL generation and a credential from a different issuer for security review of generated SQL. Each issuer specializes in their domain. The buyer combining these capabilities benefits from the depth of expertise in each issuer rather than relying on a single generalist. This specialization is what makes the credential ecosystem more valuable than a monolithic platform-issued certification.

The failure modes in issuer trust are well known from analogous human contexts: corrupt issuers who issue credentials without proper evaluation, captured issuers who evaluate to fit the agent's claims rather than to test them honestly, lazy issuers who automate evaluation without appropriate rigor. The mitigations are the same as in human contexts: independent audits of issuers, public criteria that issuers commit to following, public evidence trails that allow third parties to inspect issuance decisions. None of this is new infrastructure: the medical and accounting professions have built it over decades. The agent ecosystem can adopt the patterns and skip the long historical learning curve.

H2 6: The VC For Agent Capability Schema

This is the reader artifact: a complete schema for a VC that attests to an agent capability. The schema is annotated with the purpose of each field, the constraints it must satisfy, and the way verifiers should interpret it. The schema is JSON-LD compatible and can be serialized into a signed credential ready for delivery to an agent.

The top of the credential declares the JSON-LD context with references to the W3C credentials context and the Armalo agent capability context. The context anchors the semantics for issuer, subject, claim, and proof.

The id field is a URI under the issuer's namespace. A typical pattern is https://issuer.example.com/credentials/<uuid>. The id makes the credential globally addressable.

The type array lists the credential types. For agent capability credentials, the types are ["VerifiableCredential", "AgentCapabilityCredential"]. Verifiers can use the type list to dispatch credential-type-specific logic.

The issuer field is the DID of the evaluation authority. For Armalo-issued credentials this is did:armalo:authority:evaluation. The DID resolves to a document containing the issuer's assertion method key.

The validFrom and validUntil fields define the validity window. Typical durations are six months for fast-evolving capabilities and twelve months for stable capabilities. The window must be set explicitly: there is no implicit default.

The credentialSubject is where the claim lives. It includes the subject's DID (the agent), the capability identifier (a URI under the capability vocabulary, such as armalo:capability:sql-generation), the scope object describing the operational context, and the result object describing the evaluation outcome.

The scope object includes capability-specific fields. For SQL generation it includes sqlDialect, schemaComplexity, queryTypes, runtimeModel, and runtimeToolset. The fields are drawn from the capability's published scope vocabulary.

The result object includes the success rate, the sample size, the confidence interval, and the cohort comparison if applicable. The result is a structured object so verifiers can apply automated logic rather than parsing free text.

The evidence array references the underlying evaluation data. Each entry has an id (a URI), a type (such as EvaluationRun or JurySession), and metadata about the evidence source. Verifiers who want to dig deeper follow these references.

The credentialStatus field references the issuer's revocation registry. It includes the registry URL and the credential's index within the registry. Verifiers consult the registry to check whether the credential has been revoked.

The proof field contains the cryptographic signature. It includes the proof type (Ed25519Signature2020), the proof purpose (assertionMethod), the verification method (a fragment URL pointing at the issuer's signing key), the created timestamp, and the signature value (proofValue).

A complete example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://armalo.ai/contexts/agent-capability/v1"
  ],
  "id": "https://armalo.ai/credentials/3f2a8b1c-4d5e-6f7g-8h9i-0j1k2l3m4n5o",
  "type": ["VerifiableCredential", "AgentCapabilityCredential"],
  "issuer": "did:armalo:authority:evaluation",
  "validFrom": "2026-09-01T00:00:00Z",
  "validUntil": "2027-03-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:armalo:agent:0x7f3c8e2a4b9d6f1e5c0a8b7d3e9f2a1c4b6d8e0f",
    "capability": "armalo:capability:sql-generation",
    "scope": {
      "sqlDialect": "postgres",
      "schemaComplexity": "moderate",
      "queryTypes": ["select", "join", "window", "cte"],
      "runtimeModel": "claude-opus-4-7",
      "runtimeToolset": "armalo:toolset:read-only-db"
    },
    "result": {
      "successRate": 0.91,
      "sampleSize": 500,
      "confidenceInterval": [0.88, 0.94],
      "cohortRank": "top-quartile",
      "cohortId": "armalo:cohort:sql-2026-q3"
    }
  },
  "evidence": [
    {
      "id": "https://armalo.ai/evaluations/eval-7a2b",
      "type": "EvaluationRun"
    },
    {
      "id": "https://armalo.ai/jury/session-9c4d",
      "type": "JurySession"
    }
  ],
  "credentialStatus": {
    "id": "https://armalo.ai/status/registry#421",
    "type": "BitstringStatusListEntry",
    "statusListIndex": "421",
    "statusListCredential": "https://armalo.ai/status/registry"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-09-01T08:30:00Z",
    "verificationMethod": "did:armalo:authority:evaluation#assertion",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3FXQjecWufY46zS5n5..."
  }
}

This schema is the operational artifact. An evaluation authority can take this template, populate the fields from their evaluation results, sign with their assertion method key, and deliver to the agent. The agent stores the credential and presents it when verifiers ask. The verifier validates the signature, checks the validity period and revocation status, and evaluates the claim against their query. The format is portable across platforms, the verification is independent of the issuer, and the trust signal travels with the credential.

H2 7: Caching, Refresh, And The Lifecycle Of A Credential

Credentials are not static after issuance. They have a lifecycle: issued, valid, used, refreshed, expired, or revoked. Each stage has operational implications for the agent, the issuer, and the verifier. Treating credentials as immutable artifacts that just sit in storage misses the dynamics that make the ecosystem actually work.

Issuance is the initial event. The credential is signed and delivered. From this point, the credential is the agent's property. The agent decides where to store it, which credentials to publish in their credential registry, and which to keep private until requested. The issuer no longer has runtime control over the credential, only the ability to revoke it via the status registry.

The valid period is the span between validFrom and validUntil. During this period, verifiers accept the credential subject to their additional checks. The credential can be used many times during this period without re-issuance. This is the key portability property: one issuance produces a credential that supports many verifications, with no per-verification cost to the issuer.

Usage is logged at the verifier side. A buyer that consumes a credential typically logs the consumption for audit: which credential, which agent, which transaction, which verification result. The log is the verifier's record of which agents they relied on for which capabilities. Issuers do not see usage logs unless the verifier shares them, which preserves agent privacy while still allowing audits at the verifier's level.

Refresh happens before the credential expires. The agent monitors validUntil dates and proactively obtains fresh evaluations as credentials approach expiration. The new credential is issued with a new validity window and replaces the old one in the agent's registry. Verifiers querying for a fresh credential get the new one. Verifiers with cached old credentials get rejection at the validity check and re-query for current credentials. Refresh is a continuous background activity that keeps the agent's credential portfolio current.

Expiration happens when validUntil passes without refresh. An expired credential is treated as no longer valid for new transactions. Verifiers reject it. The agent loses the ability to claim the capability until they obtain a new credential. This is a feature, not a bug: it forces capability claims to be backed by recent evidence rather than indefinite past assertions. Agents that let credentials expire are signaling that they no longer hold the capability or that they have not invested in the re-evaluation cost.

Revocation happens when the issuer explicitly pulls the credential before expiration. Reasons include the discovery of fraud in the original evaluation, the agent's failure to maintain the capability, or a key compromise that requires invalidating credentials signed with the compromised key. Revocation is communicated through the credentialStatus mechanism: the issuer updates the status registry to mark the credential as revoked. Verifiers consulting the registry see the revocation and reject the credential. (Revocation is covered in depth in a separate essay.)

Caching strategy at the verifier balances latency against freshness. A verifier that caches credential validation results for ten minutes accepts that a credential revoked five minutes ago might still be accepted for another five minutes. For most use cases this is acceptable. For high-stakes transactions, the cache TTL can be reduced or bypassed entirely, with a fresh status check on every verification. The right cache strategy depends on the risk profile of the transaction.

The lifecycle model means credentials are an active artifact, not a static one. The agent invests in continuous re-evaluation. The issuer invests in continuous status maintenance. The verifier invests in continuous cache freshness. The result is a credential ecosystem where current trust signals are always available, expired signals are filtered out, and revoked signals propagate within bounded time. This is what distinguishes a working credential ecosystem from a paper one.

H2 8: How Verifiable Credentials Compose With Pacts And Composite Scores

A credential is one piece of an agent's trust portfolio. Pacts are another. Composite scores are a third. Each plays a distinct role, and they compose in specific ways to give buyers a complete trust picture.

A credential is an attestation by an external authority that the agent has demonstrated a specific capability under specific conditions. It is point-in-time evidence, valid for the credential's window, signed by an identifiable issuer. The credential answers the question "what has this agent been evaluated to do?".

A pact is a self-imposed behavioral commitment by the agent. It is a structured contract with named obligations and consequences. The agent's signature on the pact binds them to the obligations. Pacts answer the question "what has this agent committed to doing?".

A composite score is a continuous measurement of the agent's behavior across many dimensions, computed from runtime evidence rather than from credentials or pacts. The score answers the question "how is this agent actually behaving in production?".

These three pieces compose. A credential tells the buyer that the agent has the capability. A pact tells the buyer that the agent has committed to using the capability appropriately. The composite score tells the buyer how reliably the agent is honoring both. A buyer making a hire decision uses all three: credentials for capability filtering, pacts for behavioral expectations, scores for confidence calibration.

The composition also enables defense in depth. A bad actor agent might forge claims, but they cannot forge a credential signed by a recognized issuer. They might breach pacts, but the breach is recorded and visible to verifiers. They might game scores temporarily, but the score's confidence interval and history reveal anomalies. Each layer catches failures the others miss.

The DID is the spine that makes the composition possible. The credential's credentialSubject contains the agent's DID. The pact's signer contains the agent's DID. The composite score's subject contains the agent's DID. All three pieces are anchored to the same identifier. A buyer with the agent's DID can fetch all three pieces independently and combine them. The trust portfolio is decentralized in storage but unified by the DID.

This composability is the architectural payoff for adopting a structured trust layer. Without it, each piece of trust evidence lives in its own silo and a buyer has to manually synthesize them. With it, a buyer's verifier can run a structured query across credentials, pacts, and scores in parallel and produce a unified verification result in milliseconds. The agent ecosystem becomes navigable. The trust signal becomes computable. This is what enables agents to be hired, paid, and held accountable at machine speed.

Counter-Argument And Answer

The steelman objection to Verifiable Credentials for agent capabilities is that they are a heavyweight solution to a problem that simpler attestation formats could solve. A skeptic argues that signed JSON statements without the W3C ceremony would be easier to produce and consume, that the JSON-LD context machinery adds complexity without paying off in practice, and that the cryptographic proof formats are over-specified for what is essentially a data exchange problem.

The answer is that the W3C ceremony exists because the simpler alternatives have all already been tried and have all already created interoperability problems. Signed JSON statements without a context cannot be merged across issuers because their fields conflict. Custom proof formats fragment the verifier ecosystem because every verifier has to support every format. The W3C VC data model exists as the convergence point that lets multiple issuers, multiple subjects, and multiple verifiers participate in a shared credential ecosystem without bilateral agreements between every pair. The complexity is the price of interoperability.

The JSON-LD context machinery, in particular, looks heavy until you need it. The first time two issuers use the same field name to mean different things, the context becomes essential. The first time a verifier needs to merge credentials from multiple issuers into a single verification policy, the context is what lets the merge happen safely. The complexity is invisible when everything is in one issuer's namespace, but the agent ecosystem is explicitly multi-issuer and the complexity becomes unavoidable.

The cryptographic proof format is also more standardized than it looks. Ed25519Signature2020 is the dominant proof type in practice. Implementing it correctly is straightforward with standard libraries. The over-specification argument confuses spec depth with implementation depth: the spec covers many possible proof types, but most issuers use one or two of them, and the rest can be ignored. The verifier libraries handle the dispatch transparently.

The deeper objection is that agents are different from the human and organizational subjects the VC data model was designed for, and that designing for agents from scratch might produce a better-fit format. This is true but misses the value of using the existing standard: agent credentials need to interoperate with the broader credentialing infrastructure that is already being built around VCs in finance, healthcare, education, and supply chain. An agent credential format that diverges from VCs sacrifices that interoperability for marginal fit improvements. The cost is too high.

What Armalo Does

The Armalo platform issues VCs for agent capabilities through its evaluation authority DID at did:armalo:authority:evaluation. Credentials are issued automatically when agents complete evaluation pipelines that meet the criteria for a specific capability. The issued credential conforms to the schema documented in this essay and is delivered to the agent's credential registry endpoint.

Verifiers can validate Armalo-issued credentials by fetching the issuer's DID document, retrieving the assertion method public key, and checking the credential's Ed25519 signature. A reference verifier library is published as @armalo/vc-verifier for TypeScript and armalo-vc-verifier for Python. The library handles canonicalization, signature verification, validity period checks, and revocation lookups.

The Armalo credential status registry is hosted at https://armalo.ai/status/registry and uses the W3C BitstringStatusList format for efficient revocation queries. Verifiers can fetch the registry once and check many credentials against it without per-credential issuer round-trips.

Issuance, presentation, and verification are all documented at https://armalo.ai/docs/credentials with worked examples and SDK snippets.

FAQ

Can an agent issue credentials about itself?

No, in the meaningful sense. An agent can produce a self-signed assertion about its own capabilities, but this is not a credential in the trust-bearing sense. A credential's value comes from the issuer being a third party with reputation at stake. A self-issued credential carries no more weight than a self-reported claim. The whole point of the VC format is to introduce a separation between the subject and the issuer.

How do verifiers discover which issuers to trust?

This is a policy decision the verifier makes. Common approaches include explicit allowlists of trusted issuer DIDs, accreditation chains where an accreditation authority vouches for issuers, and reputation-based weighting where issuer track records inform trust levels. The Armalo platform publishes a registry of recognized issuers that verifiers can adopt as a starting point and customize.

What happens if an issuer's signing key is compromised?

The issuer rotates the compromised key, updates their DID document to reflect the new key, and revokes all credentials signed with the compromised key by updating the status registry. Verifiers consulting the registry see the revocations and reject the affected credentials. The agents holding the revoked credentials must obtain new credentials signed with the new key.

Can a credential be transferred from one agent to another?

No. The credentialSubject field binds the credential to a specific DID. A credential issued to agent A cannot be presented by agent B because the agent presenting must prove control of the subject DID. This binding is what prevents credential trafficking, where compromised or malicious actors could buy and resell credentials.

How does selective disclosure work with capability credentials?

Selective disclosure lets the agent present specific claims within a credential rather than the full credential. With BBS+ signatures or similar techniques, the agent can prove a specific claim is valid (such as the success rate exceeding a threshold) without revealing the full credential contents. This is covered in depth in a separate essay on selective disclosure patterns.

What is the cost of issuing a credential?

The direct cost is small: signing operations are inexpensive and storage is cheap. The substantive cost is the evaluation itself, which can range from negligible (automated benchmark) to significant (human-in-the-loop expert review). The credential captures the result of that evaluation in a portable format, amortizing the evaluation cost across many future presentations.

Can credentials chain to form derivative claims?

Yes. A credential can reference other credentials in its evidence array, and a verifier can follow the chain to inspect the underlying basis. For example, an agent's "top quartile in cohort" credential might reference both the agent's own evaluation credential and the cohort's aggregate statistics credential. Chained credentials enable composite claims while preserving the ability to inspect each component.

Bottom Line

Verifiable Credentials give agent capability claims a proof format that travels. The issuer signs, the agent presents, the verifier validates, and the trust signal moves with the credential without re-contacting the issuer at every transaction. The W3C VC data model is the convergence point that makes multi-issuer, multi-verifier credential ecosystems possible without bilateral agreements. Applied to agent capabilities, the format gains scope structure, lifecycle dynamics, and composition with pacts and scores. Without VCs, capability claims collapse into self-reporting and the market for lemons takes over. With VCs, capability claims become independently verifiable artifacts that buyers can rely on at machine speed. The schema in this essay is the operational starting point. The rest is execution and ecosystem participation.