Verification Checklist

This checklist is the practical form of OAN’s trust model. It is written for SDK users, application developers, and reviewers who need to decide whether a discovered resource should be used. A candidate is not ready for use just because it matched a query.

Use this checklist before installation, connection, API call, or agent-service invocation.

The checklist is intentionally ordered from Discovery provenance to native invocation. If an earlier step fails, later steps should not be used to excuse it. A well-authenticated API endpoint does not repair a missing Root proof. A valid Root proof does not remove the need for API authentication.

Verification loop

1. Check Discovery Provenance

Confirm that the Discovery response came from the intended Discovery endpoint. Verify response signature and freshness if the response carries signed material. Check that the Discovery node is currently authorized for the relevant domain if your verification profile requires infrastructure-state checks.

If Discovery provenance fails, do not treat the candidates as OAN-trusted results.

If a product still wants to show the result for user awareness, label it as unverified or informational. Do not let an unverified Discovery response flow into automatic tool selection.

2. Check Resource Identity

Verify:

  • the resource DID uses valid did:oan syntax;
  • the DID Document id matches the resource DID;
  • verification methods are present and consistent;
  • resource type matches the expected type;
  • service or artifact references match the type;
  • the DID Document hash matches the Root-accepted package facts.

Identity checks prevent subject confusion, type confusion, and endpoint substitution.

Endpoint substitution is a common risk. A candidate may describe one DID and proof set but point the user toward a different endpoint, repository, or artifact. The client should confirm that the target it will actually use is bound to the verified identity material.

3. Check Package and Proof

Verify ResourcePackage facts:

  • package version;
  • package hash;
  • metadata hash;
  • DID Document hash;
  • artifact or schema hashes where relevant;
  • Root proof;
  • Root identity or accepted proof context;
  • package reference returned by Discovery.

If any hash fails, reject or refetch. Do not “repair” a mismatch by ignoring the field that failed.

Also check that hash algorithms are explicit and expected. A bare hex string without algorithm context can create ambiguity. SDKs should prefer formats such as sha256:<hex> or another agreed canonical representation.

4. Check Lifecycle and Domains

Confirm that the resource is current enough for your use. Active current version is usually required. Superseded versions may be acceptable only for historical audit. Revoked or suspended resources should not be used for normal workflows.

Check authorizedDomains separately from capability tags. A tag that looks domain-like is not authorization. Make sure the resource domain fits the intended context and, when needed, the Discovery node’s scope.

For cached results, check freshness. A previously active package may now be superseded or revoked. A previously authorized Discovery node may now be suspended. Local caches should never become a way to bypass current status.

5. Check Invocation Binding

Before using the native protocol, confirm that the endpoint, manifest, schema, repository, or artifact you are about to use is the one bound to the verified package material. Then apply native security:

  • MCP initialization and tool permission checks;
  • API authentication, authorization, and rate limits;
  • skill installation policy and sandboxing;
  • Agent Service data-sharing policy;
  • enterprise approval and logging.

OAN verification should happen before these native steps, not replace them.

For request-signing profiles or future trusted invocation flows, also check timestamp freshness, nonce uniqueness, target binding, path binding, body hash, and request signature. Those checks address replay and wrong-target risks after resource selection.

6. Record the Decision

For applications and enterprises, record what was verified: DID, package version, proof reference, hash values, lifecycle state, Discovery endpoint, and native endpoint. This makes future audits and incident investigations far easier.

The record should also include the outcome. “Rejected due to package hash mismatch” is more useful than “failed.” “Verified but blocked by local policy” is different from “not verified.” Clear outcomes help automation and human review converge.

Further Reading