Verification Before Use

OAN does not ask consumers to trust Discovery blindly. It gives them evidence to check before they install a skill, connect to an MCP server, call an API, or invoke an Agent Service. Verification before use is the practical habit that turns OAN from a directory into trust infrastructure.

The exact verification depth depends on the client. A human using the website may inspect a result card and links. A TypeScript SDK can verify package hashes and proof automatically. An enterprise gateway may add policy checks. An autonomous agent may use a verification helper before selecting a tool. The principle is the same: do not treat a matching result as safe until the evidence chain is checked.

This is where OAN becomes practical rather than only architectural. A user should not need to read a paper before using a resource, but the software acting for that user should have enough structured evidence to make correct checks. Verification should be routine, repeatable, and eventually boring.

The Evidence Chain

A relying party should be able to trace a Discovery candidate through several layers:

If these checks fail, the client should reject the candidate, refetch evidence, show a warning, or require manual review depending on context.

The chain should be read from both ends. From the Discovery end, the client asks whether the answer came from an authorized Discovery node. From the package end, the client asks whether the resource version and its artifacts match what Root accepted. The candidate is usable only when those views meet cleanly.

Verification Is Before Native Protocol Use

OAN is a pre-connection trust layer. After verification, the actual use of a resource still happens through the resource’s native mechanism. An MCP Server is reached through MCP. A Skill may be installed from a package or repository. A Tool/API may be called over HTTP or another protocol. An Agent Service may use signed invocation, A2A-style flows, or a domain-specific API.

That native layer still needs its own security controls: authentication, rate limits, sandboxing, user approval, authorization, input validation, and business policy. OAN helps decide whether the resource identity and publication path are credible. It does not make arbitrary runtime behavior safe by itself.

This boundary is especially important for enterprises. OAN can help an internal platform choose resources with stronger provenance, but the enterprise still decides which data may be sent, which users may invoke which tools, what auditing is required, and how outputs are reviewed. OAN supplies evidence; local policy decides use.

What SDKs Should Automate

SDKs should make the routine parts boring. A good SDK can parse Discovery responses, verify signatures, fetch package material, check hashes, validate Root proof, inspect lifecycle, and expose clear errors. Application developers should not have to hand-write every cryptographic and schema check to use OAN correctly.

Useful SDK error categories include:

• invalid Discovery signature;
• unauthorized or unknown Discovery node;
• missing Root proof;
• package hash mismatch;
• DID Document hash mismatch;
• metadata hash mismatch;
• resource type mismatch;
• lifecycle not active;
• authorized-domain mismatch;
• endpoint or artifact reference mismatch.

Clear categories are better than one generic “verification failed” message because they help both developers and operators fix the right problem.

SDKs should also make safe defaults easy. A default client should verify signatures, hashes, lifecycle, resource type, and endpoint or artifact binding before returning a candidate as ready for use. Advanced applications can opt into richer policies, but the happy path should not require developers to remember every security step manually.

What Humans Should See

The website should not overwhelm first-time users with raw proof material, but it should show enough trust context to be honest. A result card can display resource type, DID, domains, tags, lifecycle, package version, and links to proof or source material. Advanced views can expose hashes and verification details.

For registration and Discovery pages, UI copy should avoid implying that a successful query result is automatically safe to invoke. The better message is: this is a verified candidate; here is what was verified; continue through the native protocol with appropriate controls.

The UI can still be approachable. It can summarize evidence in simple labels such as “Root accepted,” “active version,” “hash verified,” and “domain covered,” while offering details for technical readers. The goal is not to make every user a cryptographer. The goal is to avoid hiding trust-relevant facts.

Common Verification Mistakes

The main mistakes are predictable:

• trusting a URL because it appeared in a search result;
• checking a DID but not the Root proof;
• checking package proof but ignoring lifecycle status;
• treating old Discovery visibility as current authorization;
• ignoring authorized-domain mismatch;
• installing an artifact whose hash does not match the accepted package;
• assuming a capability tag proves quality or permission;
• skipping native protocol security after OAN verification succeeds.

OAN’s architecture is designed to make these mistakes less likely, but clients and user interfaces still need to implement the checks.

The safest mental model is: Discovery helps you find, OAN proof helps you verify, and the native protocol helps you use. Keeping those verbs separate prevents many design errors.

Further Reading

• OAN yellow paper
• OAN TypeScript SDK repository
• Resource registration and discovery guide