The Revocation Problem: How To Take Back A Credential Without Breaking The Web Of Trust

TL;DR

Issuing a credential is the easy part. Taking it back is where credential systems break. Revocation must propagate from the issuer to every verifier who might consume the credential, must preserve verifier privacy (no leaking which agents are being verified back to the issuer), must scale to ecosystems with millions of credentials, and must keep working when verifiers are offline or when issuers fail. The W3C BitstringStatusList specification is the current best practice for verifiable credentials, complemented by Bloom filter techniques for high-cardinality scenarios and OCSP-equivalent live query patterns for high-stakes verifications. This essay walks through the revocation design space, the failure modes of each pattern, and the operational policies that make revocation actually work in agent trust ecosystems. The reader artifact is a Credential Revocation Plan template that issuers can adapt for their own credential portfolios.

The Failure Mode That Forces The Pattern

An evaluation authority issued a capability credential to an agent eight months ago. The credential attested to the agent's reliability in handling sensitive customer data. Three weeks ago, the authority discovered that the original evaluation had been compromised: a sample selection bug had inflated the agent's measured reliability by approximately fifteen percentage points. The authority needed to revoke the credential and notify the ecosystem. They posted a notice on their public site, sent emails to known verifiers, and updated their internal database to mark the credential as revoked.

Two weeks after the notice, a buyer hired the agent for exactly the kind of customer data handling the credential was meant to attest to. The buyer's verification flow had cached the credential six weeks earlier and had not consulted the issuer's site since. The cached credential validated cleanly: the signature was good, the validity window was open, the issuer was trusted. The buyer hired the agent. The agent failed in production within the first day, exposing customer data in a way the inflated reliability score had falsely promised against. The buyer's loss was significant. The authority had revoked the credential. The buyer had not seen the revocation. The protocol had failed in the gap between issuer intent and verifier reality.

This is the canonical revocation failure mode. The issuer takes an action. The action does not propagate. Verifiers continue to rely on data that no longer reflects the issuer's position. The harm happens in the gap. Every credential system has this gap. The question is not whether revocation propagation has latency, but how that latency is bounded, how the system behaves when propagation fails, and what evidence the verifier has about whether a check was performed.

The naive solutions all fail at scale. A central revocation list that every verifier polls every few seconds becomes a single point of failure and a privacy leak: the issuer learns which agents the verifier is checking, when, and how often. A push-based notification scheme requires every issuer to maintain a registry of every verifier and to push updates reliably, which does not scale beyond a small ecosystem. Strong expiration windows that force credentials to expire frequently shift the cost to the agent (constant re-evaluation) without solving the underlying problem (revocation can still be needed within the validity window).

The production-grade solutions involve careful tradeoffs between propagation latency, verifier privacy, scalability, and offline behavior. The W3C BitstringStatusList specification is the current best practice for most use cases: a compressed bitmap of revocation states that verifiers fetch periodically, providing privacy by serving the entire bitmap to all verifiers regardless of which credentials they are actually checking. Bloom filters extend this for very high-cardinality scenarios where bitmap size becomes prohibitive. OCSP-equivalent live queries fill the gap for high-stakes verifications where verifiers need real-time confirmation rather than periodic-polled state.

The rest of this essay is about how to combine these patterns into a revocation infrastructure that actually works for agent trust ecosystems. The reader artifact at the end is a complete revocation plan template that issuers adapt for their own credential portfolios. The intermediate sections walk through the design choices, the failure modes, and the operational policies that determine whether revocation is a real protection or a paper promise.

H2 1: Why Revocation Is Hard: The Three Properties That Conflict

Any revocation scheme must balance three properties that fundamentally conflict. The first property is propagation latency: the time between when an issuer revokes and when verifiers see the revocation. Lower latency is better for trust but requires more frequent communication between issuers and verifiers. The second property is verifier privacy: the property that issuers should not be able to observe which credentials verifiers are checking. Stronger privacy is better for agent ecosystems but requires verifiers to fetch information they may not need. The third property is scalability: the system must work when there are millions of credentials, hundreds of issuers, and thousands of verifiers. Higher scalability is better for ecosystem health but pushes against fine-grained revocation tracking.

The tension between these properties means no single revocation scheme can be optimal on all three. Live OCSP-style queries minimize propagation latency (verifiers see revocations immediately) but destroy verifier privacy (issuers see every verification) and limit scalability (issuers must respond to every query). Periodic polled status lists preserve verifier privacy (issuers serve the same list to all comers) and scale well (one fetch per period regardless of credential count) but add propagation latency (verifiers see revocations only after their next poll).

The agent trust context has specific characteristics that inform the tradeoff. Verifications happen at machine speed, so polling-based propagation latency is usually acceptable as long as the polling cadence is faster than the typical hire-to-failure interval. Verifier privacy matters because issuers should not be able to map the consumption patterns of credentials in the ecosystem. Scalability matters because the agent ecosystem is targeting millions of agents and many more credentials.

The architectural answer is layered: a polled status list as the default mechanism for most credentials, with optional live query support for high-stakes credentials where verifiers want stronger guarantees. The combination preserves privacy for normal verifications, scales to millions of credentials, and gives high-stakes verifiers a path to real-time revocation when they need it. Issuers implement both. Verifiers choose which to use based on the transaction context.

The propagation guarantees should be explicit. A credential ecosystem that relies on polling without specifying the polling cadence has not actually delivered a guarantee. Issuers should publish their expected revocation propagation latency. Verifiers should configure their polling cadences accordingly. Buyers should understand that any credential check has an effective freshness window that bounds the strength of the guarantee. Without this clarity, revocation becomes wishful thinking rather than a real protection.

The historical lesson from TLS certificate revocation is instructive. Browser vendors spent years implementing OCSP queries for every TLS handshake, then discovered that OCSP responders were too unreliable to actually use, then fell back to OCSP stapling, then to periodic CRLite Bloom filter updates, then to revocation reports embedded in browser updates. The current state of TLS revocation is layered, mostly polling-based, with stapled responses for high-volume sites. Agent trust ecosystems can skip the painful history by adopting the layered model from the start.

H2 2: The W3C BitstringStatusList: Compressed Bitmaps For Revocation State

The W3C BitstringStatusList is the current best practice for verifiable credential revocation. It is a credential type itself: a status list is a verifiable credential whose subject is a bitmap of revocation states for many other credentials. The structure is elegant. The semantics are clean. The operational characteristics are well understood. Issuers should adopt it as the default revocation mechanism for any new credential type.

The core idea is straightforward. Each credential issued by an issuer is assigned an index in a bitmap. The bitmap has one bit per credential, set to zero if the credential is valid and one if it is revoked. The issuer publishes the bitmap as a verifiable credential at a known URL. Verifiers fetch the bitmap, look up the credential's index, check the bit, and use the result. The bitmap is small: a million-credential bitmap fits in 125 kilobytes uncompressed, and compresses well below 25 kilobytes due to the sparsity of revocations in healthy ecosystems.

The credential references the status list through its credentialStatus field. Each credential includes a status entry pointing at the status list URL and the index within the list. Verifiers parsing the credential extract the status entry, fetch the status list, look up the index, and confirm the credential is not revoked. The flow is fully declarative: nothing about the verification depends on out-of-band coordination between issuer and verifier beyond agreement on the URL.

The verifier privacy property comes from the unitary nature of the bitmap. The verifier fetches the entire bitmap, regardless of which credentials they are checking. The issuer cannot tell which specific credentials any verifier is interested in. The issuer sees only that the bitmap was fetched. This is a meaningful privacy improvement over OCSP-style live queries, where the issuer learns the specific credential being checked at every verification.

The propagation latency depends on how often verifiers refresh the bitmap. The W3C spec does not mandate a refresh cadence: it is a policy choice. Issuers should publish their recommended refresh interval, typically minutes for high-stakes credentials and hours for low-stakes. Verifiers configure their refresh cadence to match. The latency between revocation and verifier awareness is bounded by the refresh interval. Issuers can communicate that a major revocation has happened by tagging the response with a higher-priority signal that prompts verifiers to refresh sooner.

The bitmap is signed by the issuer. The signature is over the bitmap itself plus metadata including the publication timestamp. Verifiers checking the bitmap also check the signature, ensuring the bitmap they are using actually came from the issuer and has not been tampered with by intermediaries. The signature verification adds negligible cost: an Ed25519 signature check is microseconds. The signed bitmap is tamper-evident.

Scalability is good. A single issuer can manage hundreds of millions of credentials with a few status lists segmented by credential type or issuance period. Each list is fetched once per refresh cycle by each verifier. The fetch cost is bounded by network bandwidth, not by issuer compute. The issuer's revocation operation is a single bit flip in the bitmap, then republishing. The republished bitmap is served from a CDN at low marginal cost.

The operational pattern: issuers publish status lists at well-known URLs, sign them with their issuance authority key, refresh them on a schedule (typically every few minutes), and serve them through CDN-cached HTTPS endpoints. Verifiers cache fetched status lists locally with a TTL matching the issuer's refresh cadence, look up credentials against the cached list, and refresh when the cache expires. The protocol is simple, the operational cost is low, and the privacy properties are appropriate for the agent trust use case.

H2 3: Bloom Filters For High-Cardinality Revocation

Bloom filters complement status lists in scenarios where the absolute revocation count is high enough that bitmap size becomes problematic. A Bloom filter is a probabilistic data structure that supports membership queries with bounded false positive rates and zero false negatives. For revocation, the inverse semantics are useful: the filter contains the set of revoked credentials, and a query returns either "definitely not revoked" or "possibly revoked". A possibly-revoked answer triggers a fallback check against an authoritative source.

The size advantage matters when revocations grow large. A Bloom filter with one million revoked entries and a one percent false positive rate fits in approximately 1.2 megabytes. The same data in a status list bitmap of equivalent space efficiency might be smaller for a sparse list but larger for a dense one. For ecosystems where revocations grow to a substantial fraction of issued credentials (mass revocations after key compromise, for example), Bloom filters may be the more efficient representation.

The operational pattern for Bloom filter revocation has been deployed in browser TLS revocation under the name CRLite. The approach uses a cascading set of Bloom filters that achieve very low false positive rates with reasonable size. The construction is non-trivial but well-understood and has working implementations. The pattern transfers to agent credential revocation directly: issuers publish a Bloom filter (or cascade of filters) representing their revoked credentials, verifiers download and query the filter, and possibly-revoked results trigger an authoritative check.

The authoritative check fallback is what makes Bloom filters work despite their false positive rate. A Bloom filter that returns "possibly revoked" for a credential prompts the verifier to query the issuer's authoritative endpoint to confirm. The endpoint can be a status list lookup, an OCSP-style live query, or any other mechanism that returns a definitive answer. The Bloom filter handles the bulk of queries (returning "definitely not revoked" for the overwhelming majority of credentials at no marginal cost) while authoritative checks handle the small fraction of false positives. The combined system has the latency of authoritative checks for the false positive rate (one percent typically) and the cost of Bloom filter checks for the rest.

The privacy implications are similar to status lists: the verifier fetches the entire filter regardless of which credentials they are checking. The issuer learns only that the filter was fetched. The authoritative check fallback does reveal individual queries to the issuer, but only for the small fraction that fail the Bloom check. For most queries, privacy is preserved.

The limitations are the false positive rate and the construction complexity. The false positive rate can be tuned but cannot be eliminated. Verifiers must implement the fallback path or accept that some valid credentials may be falsely flagged. The construction (cascading Bloom filters with optimized parameters) is more complex than a simple bitmap and requires more careful tooling. For most agent credential ecosystems, the basic BitstringStatusList is sufficient and Bloom filters are an optimization for ecosystems that exceed the bitmap's natural scale.

The Armalo platform deploys BitstringStatusList as the default and is evaluating Bloom filter cascades for the long-term scaling path. The platform's status list infrastructure currently serves thousands of issued credentials with revocation rates well under one percent, well within the optimal range for status list bitmaps. As the ecosystem grows and more issuers come online, the Bloom filter pattern will become relevant for managing the aggregate revocation state across many issuers.

H2 4: OCSP-Equivalent Live Queries For High-Stakes Verifications

For high-stakes verifications where the verifier needs real-time revocation confirmation rather than periodic-polled state, an OCSP-equivalent live query mechanism complements the polled status list. The verifier sends a query to the issuer with the credential identifier; the issuer responds with the current revocation state. The freshness is real-time. The privacy cost is real: the issuer sees every query.

The pattern has lessons from TLS OCSP. Live OCSP queries were originally proposed as the default revocation mechanism for TLS certificates. In practice they failed for several reasons: OCSP responders were unreliable, browsers had to soft-fail when responses were unavailable (defeating the security property), and the privacy leakage was a real concern. The community moved to OCSP stapling, where the server includes a signed status response in the TLS handshake itself, eliminating the verifier-to-responder round trip and the privacy leak.

The agent credential equivalent of OCSP stapling is for the agent to obtain a fresh status response from the issuer and present it alongside the credential at verification time. The verifier checks the credential's signature against the issuer's key and checks the status response's signature and timestamp. The status response is short-lived (minutes to hours), signed by the issuer, and presented by the agent. The verifier gets fresh revocation information without making a query to the issuer. The issuer's load is bounded because the agent fetches status responses on a schedule rather than the issuer responding to every verification.

The operational pattern: issuers expose a status response endpoint that returns a short-lived signed assertion of the credential's current revocation state. Agents fetch fresh status responses periodically (every few minutes for high-stakes credentials, less often for low-stakes). Agents present the credential and the recent status response together. Verifiers validate both. The credential's freshness is bounded by the status response's age, which is in turn bounded by the agent's refresh cadence.

The pattern preserves verifier privacy as long as the agent is the one fetching status responses. The verifier never queries the issuer. The agent's status response fetches reveal the agent's identity to the issuer but nothing about which verifiers are using the credential. This is a meaningful privacy improvement over verifier-side OCSP queries.

The scaling is good. Issuers serve status responses through CDN-cached endpoints. Agents fetch on a schedule. The total request rate is bounded by the agent count and the refresh cadence, not by the verification rate. For an issuer with a million credentialed agents and a one-hour refresh cadence, the request rate is approximately 280 requests per second sustained, easily handled by modern infrastructure.

The limitations are the agent-side complexity and the failure mode when status responses are stale or unavailable. Agents must implement the fetch loop and handle response failures gracefully. Verifiers must define soft-fail or hard-fail policies for missing or stale responses. A hard-fail policy maximizes security but breaks transactions when status response infrastructure is briefly unavailable. A soft-fail policy preserves availability but creates a failure mode where revocations may be temporarily ignored. The choice is application-specific.

The Armalo platform supports stapled status responses for credentials where high-stakes verifiers prefer real-time freshness. The agent runtime fetches and caches status responses automatically; the agent presentation flow attaches the most recent response when verifiers request it. The verifier library validates both the credential and the status response in a single integrated flow. The complexity is encapsulated in the libraries and does not surface to applications.

H2 5: Revocation Reasons And Severity Levels

Not all revocations are equal. A credential revoked because the underlying evaluation was found to be flawed is different from one revoked because the agent's key was compromised, which is different from one revoked because the agent was retired by its operator. The reason and severity matter for verifier policy: how should the verifier respond to seeing a revocation, and how should they treat related credentials?

The W3C status list framework supports multiple status indicators beyond a simple revoked-or-not bit. Each credential can have multiple status flags reflecting different revocation dimensions: revoked, suspended, expired, superseded, fraud-indicated. The verifier reads the relevant flags and applies their policy.

A revocation reason field gives verifiers more context for their decisions. The reason should come from a controlled vocabulary so verifiers can apply automated logic. The Armalo platform publishes a reason vocabulary including evaluation-flawed, key-compromise, pact-violation, agent-retired, policy-violation, and superseded-by-newer. Each reason has documented semantics and recommended verifier responses.

Severity levels indicate how seriously the verifier should treat the revocation. A revocation due to evaluation flaw is serious: the credential should be rejected and other credentials from the same evaluation batch may be suspect. A revocation due to agent retirement is procedural: the credential is no longer valid but does not indicate any failure or risk. A revocation due to key compromise is severe: the credential should be rejected and any related credentials signed by the compromised key should be assumed at risk.

The verifier's policy should map reasons and severities to actions. For high-severity reasons, the verifier might reject not just the revoked credential but also any credentials issued by the same authority during a suspect window. For low-severity reasons, the verifier might accept the revocation as final without escalating to related credentials. The policy is the verifier's judgment about how to translate revocation signals into transaction decisions.

The propagation of severity also matters. A high-severity revocation should propagate faster than a low-severity one. Issuers can use multiple status lists with different refresh cadences: a high-stakes list refreshed every minute and a routine list refreshed every hour. Verifiers polling both can prioritize high-stakes refreshes for high-severity reasons. This bounds the propagation latency for the most consequential revocations while keeping the overall system load manageable.

The Armalo platform implements multi-list status with severity-driven refresh policies. High-severity revocations propagate within minutes. Low-severity revocations propagate within hours. The verifier library is configured with the appropriate refresh cadences per list and surfaces the revocation reason and severity to the application layer for policy decisions. Reasoning about revocation becomes structured rather than ad hoc.

H2 6: The Credential Revocation Plan Template

This is the reader artifact: a complete plan template that issuers adopt to manage credential revocation across their portfolio. The plan addresses the policy decisions, the operational mechanisms, and the verifier communication required to make revocation actually work.

The top of the plan declares the issuer DID and the policy version. The version matters for retrospective audit: when was this version of the revocation policy in effect.

The credential portfolio section enumerates the credential types the issuer manages. For each type, the plan specifies the status list URL, the refresh cadence, the supported status flags, and the reason vocabulary in use.

The revocation triggers section enumerates the conditions under which the issuer revokes credentials. For agent capability credentials, typical triggers include: discovery of evaluation flaws, agent failure to maintain the certified capability, agent key compromise, agent retirement, pact violations relevant to the certified capability, accreditation lapse of the issuing authority. Each trigger has a documented severity and reason.

The operational mechanism section specifies the revocation process. Steps include: trigger detection, internal review and approval, status list update, propagation timing, verifier notification (for high-severity cases), and post-revocation audit log. The process should be fast for high-severity cases and deliberate for low-severity cases.

The verifier communication section specifies how verifiers learn about the issuer's revocation policy and how they receive notifications about high-severity events. The plan should include the URLs for status lists, the URLs for the issuer's revocation policy documentation, the channels for emergency notifications, and the contact information for issuer support.

The sample plan:

planVersion: "2.1"
issuerDid: "did:armalo:authority:evaluation"
lastReviewed: "2026-08-15"

credentialPortfolio:
  AgentCapabilityCredential:
    statusListUrl: "https://armalo.ai/status/registry/capability"
    refreshCadence: "5m"
    statusFlags: ["revoked", "suspended", "superseded"]
    reasonVocabulary: "https://armalo.ai/vocab/revocation-reasons/v1"
  AgentReliabilityCredential:
    statusListUrl: "https://armalo.ai/status/registry/reliability"
    refreshCadence: "5m"
    statusFlags: ["revoked", "suspended"]
    reasonVocabulary: "https://armalo.ai/vocab/revocation-reasons/v1"

revocationTriggers:
  evaluation-flawed:
    severity: "high"
    reason: "evaluation-flawed"
    review: "required"
    notificationChannel: "emergency-broadcast"
  key-compromise:
    severity: "critical"
    reason: "key-compromise"
    review: "automatic-escalation"
    notificationChannel: "emergency-broadcast"
  agent-retired:
    severity: "low"
    reason: "agent-retired"
    review: "none"
    notificationChannel: "none"
  pact-violation:
    severity: "medium"
    reason: "pact-violation"
    review: "required"
    notificationChannel: "routine-update"
  policy-violation:
    severity: "medium"
    reason: "policy-violation"
    review: "required"
    notificationChannel: "routine-update"

operationalMechanism:
  triggerDetection:
    sources: ["automated-monitoring", "agent-self-report", "third-party-audit", "buyer-complaint"]
  reviewAndApproval:
    severityHigh: "two-person-approval"
    severityCritical: "emergency-protocol"
    severityLowMedium: "single-reviewer"
  statusListUpdate:
    targetLatency: "60s-after-approval"
  verifierNotification:
    emergencyBroadcast: ["webhook-subscribers", "public-announcement", "status-page"]
    routineUpdate: ["status-page"]
  postRevocationAudit:
    retentionPeriod: "7-years"
    auditLogUrl: "https://armalo.ai/audit/revocations"

verifierCommunication:
  policyDocumentationUrl: "https://armalo.ai/docs/revocation-policy"
  statusPageUrl: "https://status.armalo.ai"
  webhookSubscribeUrl: "https://armalo.ai/api/v1/webhooks/revocation"
  supportContact: "trust-ops@armalo.ai"

propagationGuarantees:
  highSeverity: "under 10 minutes from revocation to verifier visibility"
  mediumSeverity: "under 1 hour"
  lowSeverity: "under 24 hours"
  measurementMethod: "monthly synthetic revocation tests reported in audit log"

This plan is the operational artifact issuers maintain. It is published openly so verifiers can understand the issuer's revocation behavior and configure their verification policies accordingly. It is versioned so changes are traceable. It is auditable through the published audit log. The combination of explicit policy and verifiable execution is what distinguishes a serious credential ecosystem from a paper one.

H2 7: Verifier Behavior: Caching, Stapling, And Soft-Fail Policies

The verifier's side of revocation has its own design space. How aggressively to cache status data, whether to require stapled responses, how to behave when status checks fail: each decision shapes the security and availability properties of the verifier's transactions.

Caching strategy: a verifier that caches status list data for ten minutes accepts that a credential revoked within that window may continue to validate as fresh. For most applications this is acceptable because the alternative (uncached fetches on every verification) is too slow. The cache TTL should match the issuer's refresh cadence, not exceed it. A cache TTL longer than the issuer's refresh cadence increases the propagation latency without saving fetches, because the verifier's stale cache is refreshed at the verifier's TTL boundary regardless of issuer updates.

Stapling support: a verifier that requires stapled status responses gets the freshest revocation information at the cost of forcing agents to maintain stapled responses. The requirement is appropriate for high-stakes verifications. For low-stakes verifications, requiring stapling may force agents to take on operational complexity that exceeds the verification's value.

Soft-fail versus hard-fail: when the status check itself fails (the status list URL is unreachable, the status response is missing, the cache is stale beyond TTL), the verifier must decide how to behave. Soft-fail means accepting the credential despite the missing status check, defaulting to the credential's other validity signals. Hard-fail means rejecting the credential when the status check cannot be performed.

Soft-fail preserves availability but creates a failure mode where revocations are temporarily ignored. Hard-fail preserves the integrity of the revocation signal but breaks transactions when status infrastructure is briefly unavailable. The right choice depends on the transaction value and the risk tolerance. For most agent transactions, soft-fail with logging is appropriate: the verifier accepts the credential, logs the soft-fail event, and reviews patterns of soft-fails for anomalies.

Freshness signals: a sophisticated verifier reports the effective freshness of each status check to the application layer. The application can decide to require fresher checks for higher-value transactions or accept older checks for lower-value ones. This explicit handling of freshness lets the verifier expose the actual security guarantees they are providing rather than hiding them behind a single boolean valid-or-not result.

Verifier-side anomaly detection: patterns in revocations can indicate ecosystem-level events. A spike in revocations from a single issuer might indicate a key compromise. A sudden distribution of revocation reasons might indicate a policy change. Verifiers monitoring their own revocation observation patterns can surface these signals and adjust their trust assumptions accordingly.

The Armalo verifier library implements caching with configurable TTLs, optional stapling support, soft-fail with logging by default, and freshness signal exposure to applications. The library's defaults are tuned for typical agent verification workloads. Applications with specific requirements can override the defaults explicitly, with the configuration captured in the application's verification policy.

H2 8: Cross-Issuer Coordination And Ecosystem-Level Revocation

Most revocations are local to a single issuer: the issuer detects a problem, revokes the affected credential, and propagates. Some revocations are ecosystem-wide: a problem with one issuer's evaluation methodology may invalidate credentials issued by other issuers using the same methodology. A compromised cryptographic library may invalidate credentials signed by any issuer using the affected library version. These cross-issuer scenarios require coordination beyond what individual issuer revocation policies can provide.

The pattern is to designate certain entities as ecosystem-level revocation authorities. These entities monitor for cross-cutting problems and publish ecosystem-level alerts when needed. Verifiers subscribe to these alerts and apply them as policy overrides on top of their normal credential verification flows. An ecosystem alert might say: "all credentials of type X issued before date Y are suspect due to vulnerability Z; treat as effectively revoked until reissued".

The ecosystem-level authority is itself a credential issuer: it issues credentials about other issuers' credentials. A credential about a credential is a metadata layer that lets verifiers reason about ecosystem-level events without each issuer having to coordinate every revocation through their own machinery.

The Armalo platform operates an ecosystem-level revocation authority for the Armalo agent ecosystem. The authority publishes a separate status list for ecosystem-level alerts. Verifiers subscribe to this list alongside the per-issuer lists and apply ecosystem alerts as policy overrides. The mechanism is designed to handle rare but high-impact events without requiring constant operational overhead.

The alternative, where each verifier independently monitors for ecosystem-level events, does not scale. A central authority that aggregates monitoring and publishes structured alerts gives verifiers a single source for ecosystem-level signals. The authority's reputation matters: if the authority issues spurious alerts, verifiers will lose trust in the alerts and the mechanism collapses. The authority must be careful, transparent about its decision-making, and accountable for its alerts.

Cross-ecosystem scenarios add another layer. Agents whose credentials span multiple ecosystems (one set issued by Armalo, another issued by a different platform) face cross-ecosystem revocation challenges when an event affects both. The ecosystems must coordinate: a vulnerability disclosed by one ecosystem must be communicated to others. Standard channels for vulnerability disclosure (CVE-equivalent) and structured alert formats can help. The agent trust ecosystem is young enough that these channels are still being established. Issuers planning for the long term should design their alerting infrastructure to interoperate with future cross-ecosystem coordination layers.

Counter-Argument And Answer

The steelman objection to elaborate revocation infrastructure is that it adds operational burden and propagation latency that simpler approaches could avoid. A skeptic argues that short-lived credentials with frequent reissuance solve the same problem more simply: if credentials expire every week, no individual revocation matters because the credential will be reissued (or not) within seven days regardless. The skeptic concludes that issuers should optimize for short validity windows rather than for sophisticated revocation infrastructure.

The answer is that short-lived credentials shift cost without eliminating the underlying need. The cost shift is from the issuer's revocation infrastructure to the agent's reissuance overhead and the verifier's freshness check overhead. For the issuer, this looks like a win: less infrastructure to maintain. For the ecosystem, it is a loss: every agent must invest in continuous reissuance flows, and every verifier must accept that credentials they verified an hour ago may already be expired. The verification flow becomes thicker, not thinner.

Short-lived credentials also do not solve the within-window revocation problem. A credential issued at the start of a one-week validity window can still need to be revoked within the window if the underlying evaluation is found to be flawed or if the agent's key is compromised. The shorter window reduces the maximum impact of a missed revocation, but does not eliminate the need for revocation infrastructure. The issuer still needs a way to take back a credential between its issuance and its expiration. The shorter window makes the cost of a failed revocation smaller but does not eliminate the cost or the need.

The practical reality is that credential validity windows balance many concerns: re-evaluation cost, agent operational burden, verifier verification load, ecosystem propagation latency. Most agent capability credentials sit in the months-long range because that balances the concerns reasonably. At those windows, revocation infrastructure is not optional. The choice is whether to do it well or badly. The W3C BitstringStatusList pattern represents the current best practice and is operationally lightweight enough that issuers should adopt it as the default.

The deeper objection is that revocation is fundamentally a hard problem and that no infrastructure can fully solve it. This is true but misses the point. Revocation is not a problem to solve perfectly; it is a property to manage. Good revocation infrastructure makes the property visible, bounded, and auditable. Bad revocation infrastructure makes it invisible, unbounded, and untraceable. The W3C patterns and the layered approach this essay describes are about turning revocation from an unmanaged failure mode into a managed property of the credential ecosystem.

What Armalo Does

The Armalo platform implements W3C BitstringStatusList for all issued capability credentials. The status list URL appears in the credentialStatus field of every issued credential. The list is refreshed every five minutes and served from a CDN-cached endpoint. The list is signed by the Armalo evaluation authority's signing key for tamper evidence.

For high-stakes credentials, the platform supports stapled status responses through the agent's runtime. Agents can configure their runtime to fetch fresh status responses on a configurable schedule and attach them to credential presentations. The verifier library accepts stapled responses transparently and validates them alongside the credential.

The revocation reason vocabulary is published at https://armalo.ai/vocab/revocation-reasons/v1 and includes structured reasons for evaluation flaws, key compromise, pact violations, retirement, and policy violations. Verifiers consume the reason information to apply policy-driven responses to revocation events.

The Armalo ecosystem-level revocation authority publishes alerts at https://armalo.ai/status/ecosystem-alerts for cross-cutting events that affect multiple issuers or many credentials simultaneously. Verifiers subscribe to this list as a complement to the per-issuer status lists.

The complete revocation infrastructure is documented at https://armalo.ai/docs/revocation with worked examples and SDK snippets.

FAQ

Can a credential be un-revoked after revocation?

Yes, technically. The status list bit can be flipped back from one to zero. In practice, un-revocation should be rare and well-justified: a credential revoked in error can be restored, but a credential revoked for cause should not be revived without significant scrutiny. The audit log should make un-revocation events as visible as revocation events.

What happens if the issuer's status list URL is unreachable?

Verifiers fall back to their cached copy of the status list, with the cache TTL determining how long they continue to validate credentials. If the cache also expires before the issuer is reachable again, the verifier's soft-fail or hard-fail policy determines whether transactions proceed. Soft-fail with logging is the typical default for the agent ecosystem.

How are mass revocations communicated to verifiers?

The status list update itself is the primary communication channel: a mass revocation appears as many bit changes in the next status list publication. Verifiers polling the list will see the change at their next refresh. For high-severity events, the issuer can also publish an emergency notification through the ecosystem alert channel and through subscribed webhooks.

Can the agent see who has been checking their credentials?

With status list polling, no. Verifiers fetch the entire list and the issuer cannot tell which specific credentials any verifier checked. With stapled responses, the agent fetches their own status response and the issuer sees the agent's identity but not the verifier's. With direct OCSP-style queries (not the recommended pattern for the agent ecosystem), the issuer would see both sides. The recommended polled and stapled patterns preserve verifier privacy.

How do verifiers handle a status list signature failure?

A status list with an invalid signature should be treated as untrusted. The verifier should fall back to a previous valid cache or fail closed. The signature failure should also be reported to the verifier's monitoring infrastructure because it may indicate an attack or an issuer infrastructure problem.

What is the relationship between revocation and credential expiration?

Expiration is automatic and time-based: a credential with a passed validUntil is no longer valid regardless of revocation status. Revocation is explicit and issuer-driven: a credential is revoked because the issuer decided it should be. Both invalidate the credential. They are independent: an expired credential can still be revoked (which clarifies the reason for invalidity) and an unexpired credential can be valid until it is either revoked or expires.

How long should issuers retain revocation history?

Indefinitely, in most cases. Revoked credentials should remain on the status list for at least their original validity window, after which they could in principle be removed (since they would expire anyway). However, retaining historical revocation records supports audit and forensics, and the storage cost is negligible. The Armalo platform retains revocation records for seven years aligned with typical regulatory retention requirements.

Bottom Line

Revocation is the property that distinguishes a serious credential ecosystem from a paper one. The W3C BitstringStatusList pattern, complemented by Bloom filters at scale and stapled responses for high-stakes verifications, is the current best practice for verifiable credentials in agent trust contexts. The infrastructure is operationally lightweight, preserves verifier privacy, scales to millions of credentials, and supports explicit propagation guarantees. Without revocation infrastructure, credentials become permanent assertions that cannot be retracted, and the trust signal they were supposed to carry erodes over time. With it, credentials become managed artifacts whose validity reflects the issuer's current position. The plan template in this essay is the operational starting point. The rest is execution and verifier coordination.