Revocation and Status
OAN authority is current-state dependent. A historical credential, old configuration file, cached package, or stale Discovery result should not override current suspended, revoked, expired, inactive, or unknown governance state. This applies to infrastructure nodes and to resource lifecycle decisions.
The practical rule is simple: check current status before relying on old evidence.
This rule is what makes OAN different from a static directory. A static listing can remain online after trust has changed. OAN’s model expects services and clients to keep asking whether the identity, node, package, and lifecycle state are still valid for current use.
Node Status
Infrastructure node status can include active, suspended, recovered, revoked, expired, stale, or unknown. The exact labels may vary by service version, but the behavior should be conservative.
| Status | Meaning | Expected behavior |
|---|---|---|
| Active | Governance and authorization currently allow the role. | Accept role-specific actions within scope. |
| Suspended | Temporarily not authorized for normal operation. | Reject or pause trust-sensitive actions. |
| Recovered | A previous suspension has been lifted. | Resume only after current state is confirmed. |
| Revoked | Authority has been removed. | Reject authoritative actions. |
| Expired | Time-bound authorization is no longer valid. | Treat as not active. |
| Unknown or stale | Current state cannot be confirmed. | Fail closed for sensitive operations. |
Node uptime is not the same as node authority. A revoked node may still be online. An active node may be temporarily down. Status pages should avoid mixing these meanings.
The same split should appear in dashboards and APIs. Reachability answers whether a service responded. Authority answers whether it is allowed to perform the role. Freshness answers whether the current-state view is recent enough to trust. These are related but not interchangeable.
Resource Status
Resources also have lifecycle state. A resource may be submitted, accepted, published, indexed, active, superseded, suspended, or revoked. A Discovery result from a cache should not make a revoked or superseded resource look active. Clients should prefer current active versions unless they intentionally need historical verification.
This matters for skills and APIs that update frequently. A package accepted months ago may still be useful for audit, but not suitable for current installation.
For fast-moving skills, superseded is often the normal state rather than a failure. Consumers may still verify old versions for reproducibility, but default Discovery and installation flows should prefer the current active version.
Why Revocation Must Propagate
Revocation is only effective if services use current state. Root should enforce revoked Registrar status when accepting submissions. Discovery should stop exposing resources or node outputs that are out of current scope. SDKs should reject candidates whose lifecycle or proof state fails. Websites should distinguish “service online” from “authority current.”
Trust Indexer helps by projecting governance events into current operational state. Services still need to consume that state correctly.
Propagation should be designed defensively. If Root cannot confirm current Registrar state, it should not accept high-trust submissions as if everything were normal. If Discovery cannot confirm current authorization or package lifecycle, it should avoid serving stale active candidates.
Cached Data and Long-Lived Clients
Long-lived clients should be careful with cached Discovery results and package material. A result that was valid yesterday may not be valid today. Local caches should have freshness rules and verification routines. If the client cannot confirm current status, it should choose a conservative behavior for sensitive actions.
This does not mean every historical package becomes useless after status changes. Historical evidence may still be valuable for audit and reproducibility. It simply should not be used as current authority.
Long-lived agents are a special concern. An agent may cache a tool choice, keep an MCP connection profile, or remember an API endpoint. Before reusing that choice later, it should refresh OAN evidence or apply a freshness policy appropriate to the risk.
Public Status Surfaces
Public status views should help users answer two separate questions:
- Is the service reachable?
- Is the node or resource currently authorized and active?
Combining those into one green indicator is misleading. OAN’s trust story is stronger when status is precise.
A good public status view might show “reachable,” “governance active,” “Root authorization current,” “domain scope,” and “last indexed event” as separate facts. That gives users and operators a real diagnostic surface instead of a comforting but vague green light.