Internet-Draft OAN Resource Discovery June 2026
Xu, et al. Expires 11 December 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-xu-oan-resource-identity-discovery-00
Published:
Intended Status:
Informational
Expires:
Authors:
J. Xu
CAICT
B. Li
CAICT
R. Zhu
CAICT

Trust-Governed Resource Identity and Discovery Architecture for OpenAgenet

Abstract

Open agent ecosystems increasingly include heterogeneous resource products: callable agents, skills, Model Context Protocol (MCP) servers, ordinary tools, and application programming interfaces. A user or orchestrator often needs to discover such resources before it can decide which interaction protocol, credential, endpoint, or artifact to use. Discovery alone is not sufficient: the relying party also needs to know which resource identity was registered, which authority accepted it, whether the accepted package is current, and whether the Discovery service is authorized to expose it.

This document describes a trust-governed resource identity and discovery architecture for OpenAgenet (OAN). The architecture separates resource subjects, resource providers, Registrar Nodes, a Root Node, Discovery Nodes, content distribution, and resource consumers. It defines architectural roles, trust boundaries, resource identity expectations, Root-verified package semantics, registration and verification behavior, authorization-aware Discovery, and pre-use verification requirements.

The architecture can be profiled with Decentralized Identifier (DID) document concepts and credential-based assertions. This document does not define a new DID method, media type, URI scheme, transport protocol, ranking algorithm, blockchain protocol, agent invocation protocol, or product-native schema.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 December 2026.

▲

Table of Contents

1. About This Document

This note is to be removed before publishing as an RFC.

The OpenAgenet project includes open-source implementation work and related materials. The project repository set can be found at https://github.com/OpenAgenet.

The implementation is provided as running code and engineering feedback for this draft. It is not a substitute for the protocol requirements in this document, and implementation-specific APIs, repository layouts, database schemas, operational scripts, and deployment choices are not specified by this document. The intent of this draft is to describe interoperable behavior that can be implemented by independent implementations using different codebases, deployment models, and underlying technologies.

2. Introduction

Open agent ecosystems are moving beyond a single "agent service" abstraction. They can include callable agent services, reusable skills, MCP-compatible servers, ordinary HTTP or RPC tools, and domain-specific APIs. These resources may be implemented by different operators and may be invoked through different protocols. A relying party therefore needs a layer that can answer trust and discovery questions before product-specific interaction begins:

OpenAgenet (OAN) is an open architecture for resource identity, governed registration, trusted package publication, authorization-aware discovery, and pre-use verification. OAN is intentionally protocol-neutral at the interaction layer. After OAN checks pass, a consumer can use MCP, A2A, HTTP, RPC, a Skill runtime, or another product-native protocol. OAN does not replace those protocols; it supplies the trust path used to find and approach resources safely.

The central abstraction in this document is a discoverable resource, not only an agent. A discoverable resource is a product-shaped subject with a stable resource identifier, resource metadata, versioned package material, and verifiable Root acceptance. The initial resource types are:

This resource-first model allows OAN to support common agent ecosystem assets without forcing all of them into one runtime protocol or one artifact format.

2.1. Problem Statement

Closed platforms can combine account identity, approval workflow, search, artifact hosting, ranking, and invocation policy into one administrative system. In an open multi-operator environment, those functions need clearer boundaries. A Discovery result should not be trusted merely because it appears in a catalog. A CDN location should not become a trust anchor. A local ranking score should not override revocation state. A Registrar should not be able to register a resource whose subject key it never verified. A valid old package should not silently remain current after the Root has accepted a newer or revoked state.

The architectural gap is the lack of a common trust path that binds:

  • stable resource identity;

  • resource type and semantic metadata;

  • subject-control proof;

  • Registrar-issued registration evidence;

  • Registrar authorization state;

  • Root verification and package acceptance;

  • package, metadata, and identity-document hashes;

  • Discovery authorization scope;

  • signed Discovery response provenance; and

  • pre-use verification by consumers.

This document specifies that path at the architectural level.

2.2. Scope

This document specifies functional expectations for interoperable OAN deployments. A compliant implementation is expected to interoperate through the trust semantics described here, not through shared source code, a shared database, a single hosted service, or a single vendor-operated deployment. It covers:

  • architectural roles and their trust boundaries;

  • discoverable resource types and identity expectations;

  • common resource package semantics;

  • Root proof and hash-binding requirements;

  • registration and Root verification behavior;

  • infrastructure authorization and governance-state boundaries;

  • CDN distribution semantics;

  • authorization-aware Discovery behavior;

  • lifecycle, versioning, and consistency expectations;

  • pre-use verification by resource consumers; and

  • security and privacy considerations.

This document uses normative language to describe architectural requirements. It does not define a complete wire format. Future OAN profiles can define specific JSON schemas, media types, HTTP APIs, canonicalization algorithms, DID method syntax, or test vectors.

2.3. Open Interoperability Principles

OAN is intended to support an open multi-operator ecosystem. The architecture therefore follows these principles:

  • interoperability is based on verifiable protocol objects and role behavior, not on a single implementation, source repository, deployment operator, or hosted service;

  • storage, transport, database, programming language, and user-interface choices are deployment matters unless a future profile explicitly standardizes a wire protocol or object format;

  • open-source code can provide implementation experience and test material, but conformance is determined by observable behavior and verification results;

  • extensions are expected, but critical extensions need explicit criticality and failure behavior so that unsupported features do not silently weaken trust decisions;

  • local policy, ranking, semantic search, and review workflow can vary by operator, while the cryptographic verification path needs stable semantics; and

  • a Root Node is scoped to a trust domain. This document does not define a single global Root, require all deployments to use the same administrative authority, or prevent future federation profiles among trust domains.

2.4. Non-Goals

This document does not define:

  • a new DID method or identifier syntax;

  • a new URI scheme;

  • a new media type;

  • a new transport protocol;

  • a replacement for MCP, A2A, HTTP APIs, RPC, Skill packaging, or other interaction protocols;

  • a ranking, recommendation, reputation, or semantic retrieval algorithm;

  • a business ontology or product marketplace policy;

  • a blockchain protocol or smart contract interface;

  • a Root key-management ceremony;

  • a database schema, repository layout, or implementation language;

  • a requirement to use any particular open-source codebase or hosted service;

  • a user interface or operator review workflow; or

  • a mandatory artifact hosting model for Skill files, API specifications, MCP manifests, executable code, or other product-native payloads.

2.5. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Agent Service:

A callable business resource, represented as an OAN resource of type agent_service. It can expose an agent-to-agent endpoint, an HTTP endpoint, an RPC endpoint, an MCP-related binding, or another product-native interaction endpoint.

Capability Domain:

A governance-recognized domain used to determine whether a Discovery Node is authorized to expose a resource. Capability domains are distinct from local custom tags and ranking features.

CDN Service:

A content distribution service that stores and serves Root-published packages, identity documents, metadata, manifests, and related artifacts. A CDN Service is not a protocol trust authority in this architecture.

Discoverable Resource:

A resource that can be registered, Root-verified, distributed, indexed, discovered, and verified before use. Initial OAN resource types are agent_service, skill, mcp_server, and tool_api.

Discovery Node:

An infrastructure service that synchronizes Root-verified resource packages, verifies them, applies authorization-domain filtering, builds local indexes, and returns signed discovery responses.

Governance State:

The current authorization lifecycle state of an infrastructure subject, such as a Registrar Node, Discovery Node, or VC issuer. Governance state is separate from ordinary resource package lifecycle state.

MCP Server:

A resource of type mcp_server that describes an MCP-compatible server and its OAN-facing identity, endpoint, metadata, and verification material.

Registrar Node:

An infrastructure service that assists resource providers, checks candidate resource material, verifies subject control, issues registration evidence, and submits complete registration packages to the Root Node.

Resource Consumer:

A user agent, application, orchestrator, service, or other relying party that queries Discovery and verifies resource material before download, invocation, or other use.

Resource Identity Document:

The identity-facing document for a discoverable resource. A deployment can express it as a DID Document profile or another signed representation that provides equivalent identifier, key, endpoint or artifact-reference, metadata, and verification properties.

Resource Package:

A versioned Root-verified package that binds a resource identifier, resource type, package version, resource identity document, resource metadata, hashes, lifecycle state, and Root proof.

Resource Provider:

The subject, operator, or organization responsible for preparing and controlling a discoverable resource.

Root Node:

The trust anchor role for one OAN trust domain. It verifies Registrar submissions, accepts or rejects resource packages, signs Root proofs, publishes package facts, maintains or consumes infrastructure authorization state, and coordinates downstream distribution. A Root Node is not assumed to be globally unique across all OAN deployments.

Skill:

A resource of type skill that describes a capability. A Skill can refer to one or more Agent Service, MCP Server, or Tool/API implementations. The Skill artifact itself can be hosted outside OAN, provided that OAN metadata includes verifiable references.

Tool/API:

A resource of type tool_api that describes a callable tool, API, function gateway, enterprise connector, or similar interface.

3. Architecture Overview

OAN separates governance, registration, Root acceptance, distribution, Discovery, and product-native use. The high-level relationship is:

Resource Provider
   | prepares resource identity, metadata, package, hashes
   v
Registrar Node
   | verifies subject control and issues registration evidence
   | submits signed upstream request
   v
Root Node
   | verifies Registrar authorization, evidence, hashes, package
   | signs Root proof and queues publication
   v
CDN Service
   | distributes Root-published packages and metadata
   v
Discovery Node
   | verifies packages, enforces authorized domains, signs responses
   v
Resource Consumer
   | verifies Discovery response and selected package before use
   v
Product-native protocol or artifact retrieval

The architecture has several important invariants:

3.1. Role Responsibilities

3.1.1. Root Node

Within its trust domain, the Root Node is responsible for:

  • verifying Registrar-origin resource submissions;

  • verifying signed upstream envelopes, timestamp freshness, nonce uniqueness, and body-hash binding;

  • verifying registration evidence, issuer authorization, and subject-control binding;

  • verifying resource identity document structure, resource type consistency, package hashes, metadata hashes, and package versions;

  • creating Root proofs over accepted package claims;

  • preserving versioned resource package history;

  • publishing or queuing packages for CDN distribution;

  • notifying or enabling Discovery synchronization;

  • issuing or validating infrastructure authorization credentials when the deployment profile uses them; and

  • enforcing current governance state for infrastructure subjects.

The Root Node MUST NOT treat CDN location, Discovery ranking, local search signals, or Registrar policy recommendation as a substitute for Root verification.

3.1.2. Registrar Node

A Registrar Node is the onboarding and submission gateway for resources. It is responsible for:

  • assisting resource providers with draft resource identity documents and metadata;

  • validating resource type, resource identifier, metadata, package version, hashes, and hash algorithm fields;

  • verifying that the applicant controls the resource subject key material;

  • issuing registration evidence after successful policy review and subject-control verification;

  • preserving local evidence for audit and resubmission; and

  • submitting complete resource packages to the Root Node with a signed upstream envelope.

A Registrar Node MUST NOT issue authoritative registration evidence for a resource subject unless the subject-control proof or an equivalent verified binding has succeeded. A Registrar Node SHOULD fail closed for Root-facing authoritative submission when its own infrastructure authorization credential or current governance state is missing, stale beyond policy, suspended, revoked, expired, or unknown.

3.1.3. Discovery Node

A Discovery Node is responsible for:

  • synchronizing Root-verified resource packages from approved distribution locations;

  • verifying Root proofs, package hashes, metadata hashes, identity-document hashes, and lifecycle state;

  • enforcing its authorized capability domains;

  • maintaining accepted and rejected package state;

  • building local indexes over accepted packages; and

  • returning signed Discovery responses.

Discovery Nodes MAY use local ranking, semantic matching, reputation, or operator policy after package verification and authorization filtering. These local signals MUST NOT cause a resource to be exposed outside the Discovery Node's authorized domains, override Root revocation state, or hide verification failures.

3.1.4. CDN Service

The CDN Service is a distribution layer. It stores and serves Root-published resource packages, identity documents, metadata, manifests, and related artifacts. The CDN Service is not an OAN trust authority, is not necessarily a chain-governed infrastructure subject, and does not decide whether a resource is accepted.

Relying parties MUST verify Root proofs and package hashes after fetching content from a CDN Service. A manifest entry, storage location, URL, or CDN identity MUST NOT be treated as sufficient proof of resource trust.

3.1.5. Resource Provider

A Resource Provider prepares the resource identity document, metadata, endpoint descriptors, artifact references, package version, and hash material. The provider is responsible for controlling the corresponding subject key material and for maintaining product-native endpoints or artifacts. OAN does not require Discovery Nodes or CDN Services to host provider-native Skill files, OpenAPI specifications, MCP manifests, executables, or other external payloads.

3.1.6. Resource Consumer

A Resource Consumer queries Discovery and verifies selected candidates before use. It is responsible for checking the Discovery response signature, Root proofs, hashes, lifecycle state, endpoint or artifact-reference binding, resource type consistency, and any product-specific credential requirements. After these checks pass, the consumer can use the relevant product-native protocol or retrieve the referenced artifact.

4. Resource Identity Model

An OAN resource identity model separates stable identity, package version, protocol version, and endpoint or artifact version.

The stable resource identifier identifies the resource subject. It SHOULD NOT encode a package version, endpoint version, protocol version, cryptographic algorithm, mutable URL, or mutable descriptive metadata.

The package version identifies a Root-verified release of resource identity and metadata. A resource can publish multiple package versions under the same stable resource identifier. A new resource identifier SHOULD be used when the controller boundary, trust boundary, or core product semantics change enough that treating the change as a new package version would mislead relying parties.

The protocol or interface version identifies a product-native interface such as an MCP version, HTTP API version, A2A profile, Skill format version, schema version, or endpoint contract version. OAN can record these versions as metadata, but it does not define their native semantics.

4.1. Resource Types

An OAN deployment that implements this document SHOULD support the following initial resource types:

Table 1
Resource Type Product Form Typical OAN Material
agent_service Callable agent service endpoint, supported protocols, capabilities
skill Capability description or package artifact URI, digest, semantics, implementations
mcp_server MCP-compatible server endpoint, transport, protocol hints, tools summary
tool_api Tool or API endpoint or schema reference, auth mode, policy

Resource-type-specific data SHOULD be represented in typed extension fields or profile-specific objects rather than by creating unrelated package formats.

4.2. Resource Identifier and Type Consistency

When a deployment uses a DID-based identifier profile, the resource identity document SHOULD make the product form explicit in its OAN metadata. A deployment MAY use subject-code conventions, method-specific syntax, or another profile mechanism to distinguish resource types. When such a mechanism is used, the following values MUST be mutually consistent:

  • the public resource identifier;

  • the resource type declared in the registration submission;

  • the resource type declared in OAN metadata; and

  • the resource type bound by the Root proof.

Registrars, Root Nodes, Discovery Nodes, and SDKs MUST reject or quarantine resource packages where the resource identifier profile and declared resource type conflict, unless a future OAN profile explicitly defines an alias or migration rule.

4.3. Resource Identity Document Expectations

A Resource Identity Document SHOULD contain or reference:

  • the stable resource identifier;

  • verification methods and verification relationships needed by the profile;

  • controller or provider information;

  • resource type and product-form metadata;

  • semantic metadata used for discovery;

  • capability tags or capability domains;

  • endpoint descriptors for service resources;

  • artifact references for resource types that use external artifacts;

  • credential references or registration evidence references;

  • package version information;

  • lifecycle-state information or references; and

  • extension fields, with clear criticality semantics where supported.

The document MUST NOT be trusted merely because it resolves or parses. It is trusted only when it is bound to a verified package, Root proof, and acceptable current lifecycle state.

4.4. Capability Metadata

Capability metadata has two components:

  • governance-recognized capability domains; and

  • custom tags, local labels, search hints, embeddings, examples, or other descriptive fields.

Only governance-recognized capability domains can expand Discovery authorization scope. Custom tags MAY refine local search after authorization has succeeded, but they MUST NOT cause a Discovery Node to expose a resource outside its authorized domains.

Unknown non-critical extension fields MAY be ignored. Unknown critical fields MUST cause rejection by a verifier that does not understand them.

4.5. External Artifact References

Some resources, especially skill, can reference external artifacts. Examples include Skill files, MCP manifests, OpenAPI descriptions, source archives, schemas, or executable packages. OAN does not require these artifacts to be hosted by a Discovery Node or CDN Service.

An external artifact reference SHOULD include:

  • URI;

  • media type or profile identifier;

  • expected version;

  • digest algorithm;

  • digest value;

  • retrieval policy where applicable; and

  • the identity or package claims that bind the artifact to the resource.

The Root proof can make the reference and digest trustworthy as accepted metadata. It does not make the remote artifact host trustworthy. Consumers MUST verify the artifact digest after retrieval when the artifact is used for a trust-sensitive purpose.

5. ResourcePackage and Root Proof Model

The ResourcePackage is the common Root-verified registry object. It binds a resource identity document, normalized metadata, version information, hashes, lifecycle state, and Root proof.

A ResourcePackage SHOULD include:

The Root proof over an accepted package MUST bind at least:

The proof SHOULD also bind Registrar identity, registration evidence reference, publication cursor, and any critical extension fields that affect verification.

5.1. Hash and Canonicalization Requirements

OAN relies on hash binding. A deployment profile MUST define deterministic canonicalization rules for every object whose bytes are hashed or signed. Objects that require stable canonicalization include:

  • resource identity documents;

  • normalized resource metadata;

  • registration evidence;

  • signed upstream envelopes;

  • ResourcePackage payloads;

  • Root proof claims;

  • Discovery response payloads; and

  • trusted invocation or access envelopes, when used.

Hashes MUST identify their algorithm. A bare digest value without an algorithm identifier is insufficient for interoperable verification.

5.2. Version and Lifecycle Binding

Package-version lifecycle is distinct from resource-identifier lifecycle. A package version can be superseded, suspended, expired, or revoked while the stable resource identifier remains active. If the resource identity itself is deactivated, the resource subject is inactive even if older package files are still reachable from caches.

Discovery Nodes SHOULD return the latest active package version by default. When a Discovery Node returns a historical version, the response MUST indicate the exact version, package hash, metadata hash, Root proof reference, lifecycle state, and whether the version is recommended for new use.

6. Trust and Governance Layers

OAN separates governance review, credential issuance, subject-control proof, runtime verification, and resource package lifecycle.

6.1. Governance Review

Operator review, legal review, organizational checks, contact validation, or manual approval can be useful before a Registrar, Discovery Node, VC issuer, or ordinary resource is admitted. These processes are policy decisions. They are not protocol proofs by themselves.

Email addresses, phone numbers, SMS codes, web account login, and similar account-centric factors MAY be used in private review workflows. They MUST NOT be required as OAN protocol trust primitives for cross-network interoperability.

6.2. Credential Issuance

After review and cryptographic checks succeed, an authorized issuer can issue a credential or credential-like assertion. A registration credential binds the issuer, subject resource identifier, credential type, claims, issuance time, expiration time if present, and proof.

The credential is the protocol-facing result of review. It does not replace Root acceptance, package verification, or current lifecycle-state checks.

6.3. Subject-Control Proof

Subject-control proof prevents a Registrar from issuing registration evidence for a resource identifier whose key material the applicant does not control. The proof SHOULD be challenge-response based and bind:

  • challenge identifier;

  • resource identifier;

  • Registrar identifier;

  • identity-document hash or equivalent stable representation hash;

  • proof purpose;

  • verification method;

  • nonce;

  • issuance time; and

  • expiration time.

The Registrar MUST verify subject-control proof before issuing authoritative registration evidence. Root verification MUST ensure that registration evidence remains bound to the subject-control process and target resource identifier.

6.4. Infrastructure Governance State

Infrastructure subjects, such as Registrar Nodes, Discovery Nodes, and future third-party VC issuers, can have lifecycle state governed by a bulletin, committee process, on-chain event source, or another deployment-specific governance mechanism.

This infrastructure governance state is separate from ordinary resource package state. It governs whether an infrastructure subject is active, suspended, revoked, expired, unknown, or otherwise inactive. It does not by itself create a resource package, validate a DID Document, host an artifact, or make a Discovery result trustworthy.

Where an OAN deployment uses Root-issued infrastructure authorization credentials, effective infrastructure authorization is the conjunction of:

  • a valid Root-issued authorization credential for the infrastructure subject; and

  • latest governance-derived state showing that the same subject and role are active within the applicable scope.

If either condition is missing, stale beyond policy, suspended, revoked, expired, or unknown, infrastructure peers SHOULD fail closed for trust-sensitive operations.

6.5. On-Chain Governance Profile

An OAN deployment MAY use on-chain governance as the publication mechanism for infrastructure lifecycle outcomes. In such a profile, blockchain contract events can provide an auditable source of governance results for infrastructure subjects such as Registrar Nodes, Discovery Nodes, and future VC issuers.

The on-chain governance profile is an infrastructure-governance profile. It does not make the blockchain a storage system for resource identity documents, ResourcePackages, credentials, external artifacts, or product-native payloads. It also does not require ordinary Resource Providers, Resource Consumers, or lightweight SDKs to subscribe to blockchain events.

An on-chain governance event is not, by itself, an OAN service credential. For trust-sensitive infrastructure interactions, the effective authorization decision still depends on the combination of current governance-derived state and protocol-verifiable authorization material, such as a Root-issued infrastructure authorization credential.

This document does not define a blockchain protocol, blockchain contract interface, transaction format, consensus mechanism, governance voting procedure, or chain-specific event schema. Those choices are deployment or future-profile matters. The interoperability requirement here is that relying infrastructure can determine the current governance state that is relevant to a trust decision and can combine that state with OAN protocol evidence.

6.6. Bulletin Boundary

A governance bulletin can publish infrastructure authorization outcomes, package publication events, or other deployment-specific facts. A profile MAY implement the bulletin as an append-only signed log, an on-chain event stream, a committee-approved record, or a combination of these mechanisms.

The bulletin MUST NOT be assumed to store complete resource identity documents, full credentials, private credential material, resource packages, external artifacts, or product-native payloads unless a future profile explicitly defines such storage. In the architecture described here, resource package trust remains based on Root verification, Root proof, hashes, package state, and Discovery verification.

7. Registration and Root Verification

The standard OAN registration flow is:

  1. The Resource Provider prepares a resource identity document, metadata, package version, hashes, endpoint descriptors, or artifact references.

  2. The Registrar validates resource type, resource identifier consistency, identity-document shape, metadata, hashes, and hash algorithm fields.

  3. The Resource Provider proves control of the resource subject key material.

  4. The Registrar applies local policy and issues registration evidence.

  5. The Registrar creates a complete registration submission.

  6. The Registrar signs an upstream request envelope and submits it to Root.

  7. Root verifies infrastructure authorization, request integrity, freshness, replay protection, registration evidence, subject-control binding, hashes, and package semantics.

  8. Root accepts or rejects the package.

  9. On acceptance, Root archives the version, creates a Root proof, and queues package publication and Discovery synchronization.

Create and update operations SHOULD use a complete-document path. Root SHOULD verify a complete new resource identity representation rather than applying ambiguous partial patches.

7.1. Signed Upstream Envelope

Registrar-to-Root submissions and other trusted upstream writes MUST be authenticated and integrity protected. A signed upstream envelope SHOULD cover:

  • request identifier;

  • protocol version or profile identifier;

  • request purpose;

  • HTTP method or equivalent operation;

  • path or target operation name;

  • audience identifier;

  • signer identifier;

  • timestamp;

  • nonce;

  • body hash;

  • canonicalization algorithm; and

  • proof.

Receivers MUST verify the sender's authorization state, proof validity, body hash, timestamp freshness, nonce uniqueness, audience binding, and expected operation before processing the body.

7.2. Root Verification Requirements

Root verification MUST be deterministic and auditable. At a minimum, Root MUST verify:

  • the Registrar is currently authorized for the requested operation;

  • the upstream envelope signature is valid;

  • the request timestamp is fresh according to policy;

  • the nonce has not been replayed within the replay window;

  • the body hash matches the received body;

  • the resource identifier syntax or profile is valid;

  • the identity document is bound to the submitted resource identifier;

  • the declared resource type is consistent across submitted objects;

  • the identity-document hash matches the submitted identity document;

  • the metadata hash matches normalized metadata;

  • the package hash and hash algorithm are valid;

  • registration evidence is issued by an authorized Registrar;

  • registration evidence is bound to the target resource identifier;

  • subject-control proof or an equivalent verified binding is present; and

  • the requested lifecycle transition is valid.

Root MUST reject a submission if a required verification step fails. Silent partial acceptance is unsafe because downstream consumers can treat Root acceptance as evidence that the complete trust path succeeded.

7.3. Registration Outcome

On successful verification, Root SHOULD:

  • archive the accepted identity document and metadata;

  • assign or confirm the package version;

  • create Root proof claims over required package fields;

  • create or update the latest-version index;

  • record publication state or cursor information;

  • queue CDN publication or equivalent distribution; and

  • make Discovery synchronization possible.

A successful Root response indicates Root acceptance of a specific package version. It does not prove product quality, endpoint liveness, ranking value, or suitability for a particular task.

8. Distribution Model

OAN distribution has two layers:

The CDN Service belongs to the Root-to-Discovery distribution path. It can serve ResourcePackages, identity documents, metadata, manifests, and package indexes. It does not make bytes trustworthy.

Provider-to-consumer artifact distribution remains outside the OAN core. A Skill file, MCP manifest, OpenAPI document, source archive, executable, or other artifact can be hosted by the provider, a repository, object storage, an institutional website, or another distribution service. OAN verifies the reference, digest, package binding, publisher identity, and Root proof; it does not require OAN infrastructure to host the artifact.

Discovery Nodes and consumers MUST verify fetched package material before using it. Verification includes Root proof, package hash, metadata hash, identity-document hash, resource type, lifecycle state, and applicable bulletin or publication facts.

9. Authorization-Aware Discovery

Discovery has three separate outputs:

These outputs MUST NOT be conflated. A resource can be valid but not highly ranked. A response can be signed by a Discovery Node but still contain only local ranking decisions. A high local score does not make an unverifiable or revoked package trusted.

9.1. Synchronization

Discovery synchronization SHOULD follow this order:

  1. identify the Root trust anchor or Root endpoint for the deployment;

  2. obtain current Root or bulletin facts needed by the profile;

  3. resolve distribution locations from verifiable Root-controlled material when available;

  4. fetch manifests or package indexes;

  5. fetch resource packages;

  6. verify identity-document hash, metadata hash, package hash, and Root proof;

  7. verify lifecycle state and current-version expectations;

  8. enforce Discovery authorized domains;

  9. persist accepted packages into the query index; and

  10. persist rejected packages with inspectable reasons.

Discovery MUST NOT index packages that fail verification as trusted candidates. Discovery SHOULD keep accepted and rejected package state separate so operators can distinguish missing publication, verification failure, authorization-domain mismatch, and query mismatch.

9.2. Authorized Domains

A Discovery Node's authorized domains limit which resources it may expose. Profiles can express these domains through a capability tree, tags, policy attributes, or another governance-recognized mechanism.

A Discovery Node MUST NOT expose a resource as trusted unless the resource is eligible under the Discovery Node's authorized domains. Custom tags, semantic embeddings, local labels, or ranking features MUST NOT expand the authorized domain set.

9.3. Query Model

A Discovery query MAY include text, capability tags, resource type, protocol binding, provider identifier, endpoint type, version requirement, package hash, authorization domain, lifecycle state, or other profile-specific filters.

Discovery SHOULD return the latest active package version by default. If a consumer asks for an exact version, version constraint, or package hash, Discovery MUST NOT silently substitute a different package version unless the response clearly indicates the substitution and the consumer policy allows it.

9.4. Signed Discovery Response

A Discovery response SHOULD be signed by the Discovery Node. The signed payload SHOULD include:

  • Discovery Node identifier;

  • response timestamp;

  • query echo or query hash;

  • candidate identifiers;

  • package versions and package hashes;

  • Root proof references;

  • lifecycle states;

  • matched fields or explanation metadata when provided;

  • nonce or correlation identifier where useful; and

  • proof.

The Discovery signature proves response provenance from that Discovery Node. It does not prove product quality, endpoint liveness, user suitability, or business trustworthiness.

10. Pre-Use Verification

Before downloading, invoking, composing, or otherwise relying on a discovered resource, a Resource Consumer SHOULD verify:

For service resources, an SDK or client SHOULD construct the product-native client only after OAN verification has passed. For Skill resources, a client SHOULD verify the referenced Skill file or manifest before resolving and invoking implementation resources.

OAN verification is a pre-use guard. After it succeeds, control moves to the product-native protocol or artifact format. Product-native behavior remains outside this document.

11. Lifecycle, Versioning, and Consistency

OAN uses multiple lifecycle scopes. Implementations MUST keep them distinct.

11.1. Registrar Draft State

Registrar draft state is local onboarding workflow state. Example states can include draft, challenged, control-verified, credentialed, submitted, accepted, or rejected. Draft existence MUST NOT imply Root acceptance or Discovery visibility.

11.2. Resource Package State

Resource package state is Root-governed version state. Example states include accepted, published, active, superseded, suspended, expired, and revoked. These states apply to a versioned package, not necessarily to every historical package or to every local Discovery index row.

Root MUST avoid ambiguous current-version state for the same resource identifier. Discovery Nodes SHOULD suppress revoked, suspended, expired, or otherwise inactive package versions from default trusted query results.

11.3. Discovery Index State

Discovery index state is local to a Discovery Node. Example states include fetched, accepted, indexed, rejected, quarantined, or stale. These states describe Discovery-local processing outcomes. They do not modify Root package lifecycle state.

11.4. Infrastructure Authorization State

Infrastructure authorization state applies to Registrar Nodes, Discovery Nodes, and future infrastructure issuers. It is separate from ordinary resource package state. Revoking a Registrar does not automatically revoke all historical resource packages that Registrar helped onboard, unless the Root or profile defines such a consequence. However, a revoked Registrar MUST NOT be accepted for new authoritative submissions.

11.5. Asynchronous Publication

Root acceptance, CDN publication, Discovery synchronization, and query visibility can be asynchronous. A newly accepted package may not be immediately queryable. This is acceptable if implementations expose enough state for operators and consumers to distinguish publication delay, verification failure, authorization-domain filtering, and query mismatch.

Discovery MUST NOT compensate for staleness by accepting unverifiable packages. If synchronization is stale beyond policy, Discovery SHOULD fail closed for trust-sensitive results or clearly mark the response freshness state.

12. Relationship to Other Protocols

OAN is an identity, registration, package, and discovery trust layer. It can be used before or around product-native protocols.

MCP:

OAN can discover and verify an mcp_server resource, then allow an MCP client to connect using MCP semantics. OAN does not define MCP tool behavior.

A2A or Agent Interaction Protocols:

OAN can discover and verify an agent_service resource and provide identity and package evidence before the agent interaction protocol begins. OAN does not define the full task conversation.

HTTP or RPC APIs:

OAN can discover and verify a tool_api resource, endpoint descriptor, and schema or artifact reference. The API's business semantics remain native to that API.

Skills:

OAN can discover and verify a skill resource and its external artifact reference. Skill package format, execution, and composition semantics remain outside the OAN core.

13. Protocol Object Expectations

Future OAN profiles are expected to define concrete object schemas. This document identifies the expected objects and minimum semantic requirements.

13.1. Registration Submission

A registration submission SHOULD contain:

  • Registrar identifier;

  • resource identifier;

  • resource type;

  • complete resource identity document;

  • normalized metadata;

  • package version;

  • identity-document hash;

  • metadata hash;

  • package hash;

  • hash algorithm;

  • registration evidence;

  • subject-control proof or equivalent binding; and

  • signed upstream envelope.

13.2. Registration Evidence

Registration evidence SHOULD contain:

  • issuer identifier;

  • subject resource identifier;

  • credential or evidence type;

  • issued-at time;

  • expiration time where applicable;

  • registration purpose;

  • identity-document hash;

  • subject-control proof hash or equivalent reference;

  • verified verification method; and

  • proof.

13.3. Discovery Candidate

A Discovery candidate SHOULD contain:

  • resource identifier;

  • resource type;

  • package version;

  • package hash;

  • metadata hash;

  • identity-document hash;

  • lifecycle state;

  • endpoint descriptors or artifact references;

  • matched capability domains or tags;

  • Root proof reference; and

  • product-native protocol hints where applicable.

14. Error Taxonomy

Precise errors improve interoperability and operations. Implementations SHOULD distinguish at least the following categories:

Table 2
Category Example Expected Behavior
syntax malformed object reject before trust checks
crypto bad signature reject and audit signer
authorization inactive Registrar reject as unauthorized
freshness stale timestamp reject as expired
replay repeated nonce reject and audit
binding wrong resource identifier reject as mismatch
hash metadata hash mismatch reject or quarantine
scope out-of-domain package do not index
state revoked package suppress from trusted results
artifact digest mismatch do not use artifact

External error messages MAY avoid exposing sensitive operator details, but internal logs SHOULD preserve enough information for audit and debugging.

15. Security Considerations

This document follows the general guidance for protocol threat analysis in [RFC3552].

Malicious Registrar:

A Registrar can attempt to register resources without verifying subject control or after losing authorization. Root MUST verify Registrar authorization, signed upstream envelopes, freshness, replay protection, registration evidence, and subject-control binding.

Subject-control failure:

An applicant can try to register a resource identifier controlled by another party. Registrars MUST verify subject-control proof before issuing authoritative registration evidence, and Root MUST verify that the evidence remains bound to the target resource.

Tampered CDN content:

A CDN or intermediary can serve modified packages or stale manifests. Discovery Nodes and consumers MUST verify Root proofs and all relevant hashes after retrieval.

Overbroad Discovery exposure:

A Discovery Node can expose resources outside its authorized domains. Discovery implementations MUST enforce authorized-domain filtering before indexing or returning trusted candidates.

Ranking as authorization:

Local ranking, semantic search, or reputation features can be mistaken for trust decisions. Implementations MUST apply ranking only after Root package verification and Discovery authorization filtering.

Stale lifecycle state:

A stale cache can return superseded or revoked resources. Discovery Nodes SHOULD track freshness and fail closed for trust-sensitive results when lifecycle state is stale beyond policy.

Replay attacks:

Attackers can replay upstream submissions or signed invocation envelopes. Signed envelopes MUST bind timestamp, nonce, audience, operation, and body hash. Receivers MUST enforce freshness windows and nonce uniqueness.

Wrong-target invocation:

A request prepared for one resource can be redirected to another endpoint. Consumers and service resources SHOULD bind signed access or invocation envelopes to the selected target identifier and verified endpoint metadata.

External artifact substitution:

A Skill file, MCP manifest, API description, or executable can be replaced at its external host. Consumers MUST verify artifact digests and package binding before use.

Canonicalization mismatch:

Independent implementations can compute different hashes for the same logical object. Profiles MUST define canonicalization rules and SHOULD provide test vectors.

Root key compromise:

A compromised Root signing key can undermine a trust domain. Deployments SHOULD define key rotation, compromise response, revocation, and recovery procedures. Higher-assurance deployments SHOULD consider threshold signing or other operational controls.

Denial of service:

Attackers can submit many registrations, trigger expensive verification, or overload Discovery queries. Registrars, Root Nodes, CDN Services, and Discovery Nodes SHOULD apply rate limits, quotas, backpressure, input size limits, and monitoring.

16. Privacy Considerations

OAN metadata can reveal provider identities, service endpoints, capability areas, business relationships, policy requirements, and organizational structure. Deployments SHOULD minimize public metadata and avoid publishing private endpoint details, unnecessary internal schemas, private credentials, or sensitive operational information.

Discovery queries can reveal user or enterprise intent. Discovery Nodes SHOULD provide transport confidentiality, access control where appropriate, retention limits, privacy-preserving logs, and clear operator policies for query data.

External artifact references can leak which users or organizations retrieve a Skill, API description, or package from a third-party host. Consumers SHOULD consider retrieval privacy and artifact caching policies for sensitive deployments.

17. IANA Considerations

This document makes no IANA requests.

Future OAN profiles that define media types, URI schemes, HTTP fields, well- known URIs, registries, or protocol parameter values are expected to include their own IANA considerations.

18. Implementation Status

This section is to be removed before publication as an RFC.

A research implementation of OAN has been developed with separate Root, Registrar, Discovery, and CDN services; resource-oriented registration; did:oan resource identifiers; first-class resource types for Agent Service, Skill, MCP Server, and Tool/API; subject-control proof; Registrar-issued registration evidence; Root-verified ResourcePackage objects; signed upstream envelopes; Root-to-CDN package publication; Discovery package verification; authorized-domain filtering; signed Discovery responses; and pre-use verification examples.

The open-source project is available at https://github.com/OpenAgenet. The repository set is expected to evolve as the implementation and draft are refined. The existence of this code is intended to support experimentation, review, and interoperability feedback; it is not required for conformance.

Implementation details such as repository layout, programming language, database backend, HTTP route names, local file paths, and operator tooling are not specified by this document.

19. Conformance Checklist

An implementation or deployment can be reviewed against the following checklist:

20. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3552]
Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, , <https://www.rfc-editor.org/rfc/rfc3552>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

Appendix A. Example ResourcePackage (Informative)

The following JSON fragment illustrates a ResourcePackage. It is not a mandatory wire format.

{
  "resourceDid": "did:oan:AG:example-translator",
  "resourceType": "agent_service",
  "packageVersion": "3",
  "lifecycleState": "active",
  "didDocumentHash": "sha256:012345...",
  "metadataHash": "sha256:abcdef...",
  "packageHash": "sha256:789abc...",
  "hashAlgorithm": "sha256",
  "metadata": {
    "name": "Example Translator",
    "capabilityTags": ["translation", "translation.zh-en"],
    "customTags": ["legal-contract-translation"],
    "protocolBindings": ["https"]
  },
  "registrarDid": "did:oan:REG:registrar-01",
  "rootProof": {
    "type": "ExampleDataIntegrityProof2026",
    "verificationMethod": "did:oan:ROOT:root-01#key-1",
    "packageClaims": {
      "resourceDid": "did:oan:AG:example-translator",
      "resourceType": "agent_service",
      "packageVersion": "3",
      "didDocumentHash": "sha256:012345...",
      "metadataHash": "sha256:abcdef...",
      "packageHash": "sha256:789abc...",
      "lifecycleState": "active"
    },
    "proofValue": "..."
  }
}

Appendix B. Example Skill Artifact Reference (Informative)

The following JSON fragment illustrates an external artifact reference for a Skill resource. It is not a mandatory wire format.

{
  "resourceDid": "did:oan:SK:invoice-review",
  "resourceType": "skill",
  "packageVersion": "1.0.0",
  "artifact": {
    "uri": "https://example.org/skills/invoice-review.skill.json",
    "mediaType": "application/example-skill+json",
    "version": "1.0.0",
    "digest": "sha256:13579b...",
    "retrievalPolicy": "public-read"
  },
  "implementedBy": [
    {
      "resourceDid": "did:oan:MC:accounting-mcp",
      "resourceType": "mcp_server"
    }
  ]
}

Appendix C. Example Discovery Response (Informative)

The following JSON fragment illustrates a signed Discovery response. It is not a mandatory wire format.

{
  "discoveryDid": "did:oan:DIS:discovery-01",
  "issuedAt": "2026-06-06T08:01:00Z",
  "queryHash": "sha256:2468ac...",
  "results": [
    {
      "resourceDid": "did:oan:AG:example-translator",
      "resourceType": "agent_service",
      "packageVersion": "3",
      "packageHash": "sha256:789abc...",
      "metadataHash": "sha256:abcdef...",
      "lifecycleState": "active",
      "matchedTags": ["translation.zh-en"],
      "rootProofRef": "root-proof:4812"
    }
  ],
  "proof": {
    "type": "ExampleDataIntegrityProof2026",
    "verificationMethod": "did:oan:DIS:discovery-01#key-1",
    "proofValue": "..."
  }
}

Appendix D. Acknowledgements

The authors thank participants in discussions on open agent networks, resource identity, trusted discovery, and cross-protocol agent interoperability.

Authors' Addresses

Jinliang Xu
CAICT
No. 52, Huayuan North Road
Beijing
Haidian District, 100191
China
Bingqi Li
CAICT
No. 52, Huayuan North Road
Beijing
Haidian District, 100191
China
Runkai Zhu
CAICT
No. 52, Huayuan North Road
Beijing
Haidian District, 100191
China