Security and Verification
OAN provides evidence. Relying parties still need to verify it. This is the central security habit: use Discovery to find candidates, then check identity, package proof, lifecycle, domain scope, and endpoint binding before installing, connecting, or invoking.
The architecture is deliberately layered so that no single convenient signal becomes over-trusted. A high semantic score is not proof. CDN availability is not proof. Endpoint uptime is not proof. An old credential is not current authority. A capability tag is not domain authorization.
This page is not a complete formal security proof. It is the operating security model that clients, SDKs, and reviewers should apply. Most practical failures come from trusting the right object at the wrong layer: using a search score as authorization, using a URL as identity, or using a historical proof as current status.
What Must Be Verified
| Layer | Evidence | Typical check |
|---|---|---|
| Identity | did:oan DID Document and keys |
DID shape, subject match, verification methods. |
| Publication | ResourcePackage and Root proof | Root proof, package hash, metadata hash, DID Document hash. |
| Lifecycle | Current package and status | Active, not revoked, not superseded for current use. |
| Governance | Node authorization state | Registrar or Discovery is current and in scope. |
| Discovery | Signed Discovery response | Response signature, freshness, candidate package references. |
| Invocation | Native protocol details | Endpoint binding, schema, auth, policy, sandboxing. |
Verification should be implemented in SDKs and reusable libraries wherever possible. A UI can show a simplified view, but the underlying evidence should stay available.
For security-sensitive applications, the verification record should be retained. It is useful to know which Discovery node answered, which DID was selected, which package version and hashes were checked, which lifecycle state was current, and which native endpoint was finally used.
Security Is Boundary Discipline
Most OAN security mistakes come from crossing boundaries:
- treating Registrar acceptance as Root acceptance;
- treating Discovery ranking as safety;
- treating capability tags as authorization;
- treating a CDN URL as proof;
- treating an endpoint response as DID control;
- treating an old node credential as current governance state;
- treating OAN verification as a replacement for API or MCP runtime controls.
The system is safer when every component keeps its limited authority.
This boundary discipline also makes incident response easier. If a package hash fails, investigate package distribution or package preparation. If a Discovery signature fails, investigate the Discovery endpoint. If a node status is stale, investigate governance indexing. One vague “trust failure” is much harder to repair.
OAN Does Not Replace Native Security
After OAN verification succeeds, the resource’s native protocol still matters. MCP clients still need MCP safety. API clients still need authentication and rate limits. Skill installations still need permissions and sandboxing. Agent Service calls still need data-sharing policy and user approval where appropriate.
OAN moves the trust decision earlier. It gives a client better evidence before the native protocol begins.
The phrase “before” matters. OAN does not inspect every future tool call, API response, prompt, or model output. It helps a client decide whether to begin interaction with a resource and what evidence should be attached to that decision.
Practical Verification Outcomes
A client should be able to produce clear outcomes:
- verified and usable under local policy;
- relevant but not verified;
- verified but lifecycle not active;
- verified but outside local policy;
- rejected because proof, hash, identity, domain, or endpoint checks failed;
- inconclusive because status or governance state is stale.
These outcomes are more useful than one vague “safe” label.
Avoid using a single green badge for everything. “Verified publication evidence” and “approved under local policy” are different states. A resource can pass OAN proof checks and still be disallowed by enterprise policy. A resource can be relevant and still fail verification.