OpenAgenet / OAN Yellow Paper: Technical Architecture for Trust-Governed Resource Identity and Discovery Jinliang Xu
arXiv:2606.03163v3 [cs.MA] 5 Jun 2026
China Academy of Information and Communications Technology, Beijing, China [email protected]; [email protected] Abstract—This yellow paper describes the technical architecture of OpenAgenet / OAN. OAN is a protocol-neutral trust layer for open Agent interconnection and discoverable AI resource products. It specifies the role architecture, did:oan identity objects, registration workflow, governance-backed Root lifecycle enforcement, Root-verified package model, authorization-aware Discovery, Root-issued infrastructure authorization VCs, signed trusted invocation, verification requirements, state transitions, security properties, implementation boundaries, and deployment considerations. The design is intended to support heterogeneous Agent frameworks and interaction protocols, including MCP, A2A, ANP-like systems, domain-specific Agent protocols, Skills, MCP Servers, and Tool/API resources. OAN does not define the entire business conversation among Agents or the native protocol of every resource; it defines how resource identities become admissible, discoverable, verifiable, and safe to approach before protocol-specific interaction begins.
Open-source project: https://github.com/OpenAgenet Index Terms—OpenAgenet, OAN, did:oan, resource identity, DID, VC, discovery, signed envelope, trusted invocation
1. T ECHNICAL S COPE OAN specifies a trust-governed resource identity and Discovery architecture. The system is concerned with the admissibility of did:oan identity representations across registration, Root acceptance, package distribution, Discovery indexing, Discovery response verification, and pre-connection invocation or access. It deliberately does not define a complete task protocol, model orchestration framework, prompt strategy, tool execution API, ranking algorithm, artifact hosting model, or business ontology. The technical scope can be expressed through the following invariant: a resource identity should become visible to a relying party only after it has been prepared by the resource provider, checked by a Registrar whose infrastructure status is active under governance and credentialed by Root, accepted by Root, distributed through a verifiable package, indexed by a Discovery node whose infrastructure status is also active and credentialed, and returned with evidence that can be checked before invocation or access. The core abstraction is Trusted Resource, not only Agent. A trusted resource is a product-shaped entity, represented by a did:oan DID Document and a Root-verified ResourcePackage, whose lifecycle and discovery evidence can be checked before use. The initial resource types are Agent Service, Skill, MCP Server, and Tool/API. This abstraction lets
TABLE I OAN P ROTOCOL S TACK Profile
Main objects
Primary users
Identity
did:oan document, resource metadata draft, proof, credential lifecycle state, threshold events
SDKs
Registration Federated governance Root enforcement Package Discovery Invocation/access Adapter
Root VC, accepted record, package proof verified package, cursor query, signed response signed request/response, artifact reference MCP/A2A/ANP mapping
Registrar, Root committee, Root Root, infrastructure Root, CDN, Discovery Discovery, User Agent consumers/providers protocol integrators
OAN implement a Resource First model: the protocol admits heterogeneous AI ecosystem assets through one trust path, while allowing each product type to keep its native runtime, artifact format, or interaction protocol. The current formal route style is intentionally unversioned: Root: /root/... Registrar: /registrar/..., /agents/..., /capability-tree • Discovery: /discovery/..., /discover/query • CDN: /cdn/... • •
Route versioning can be introduced later through content negotiation, typed object versions, or explicit API prefixes. The current design keeps the route surface simple while placing version information in protocol objects where verification actually occurs. 2. OAN P ROTOCOL S TACK OAN should be read as a protocol stack rather than as one service API. The stack has several profiles, each of which can be implemented independently and combined by different operators. Its lower layers reuse the DID/VC family of identity and credential concepts [1], [2], [3], [4], while its upper layers are designed to wrap Agent interaction protocols such as MCP and A2A [5], [6]. The stack structure clarifies implementation scope. A resource provider may only need the Identity, Discovery, and Invocation/access profiles. A Discovery operator needs Package and Discovery profiles plus Root bulletin verification. A
TABLE II OAN T RUST L AYERS
Adapter Profiles: MCP, A2A, ANP-like, Domain Protocols
Trusted Invocation Profile
Authorized Discovery Profile
Root-Verified Package Profile
Federated Governance and Root Enforcement Profile
Registration and Credential Profile
Resource Identity Profile
Fig. 1. OAN technical profiles form a layered trust stack.
full infrastructure operator needs Registration, Root Enforcement, Package, and Discovery. Governance operation clients additionally implement the Federated Governance profile. An adjacent protocol community can define an Adapter profile without changing the Root acceptance model. 3. S YSTEM A SSUMPTIONS OAN assumes a trust domain with one Root service boundary, but not a single unreviewable Root decision maker. Infrastructure lifecycle state for Registrar, Discovery, and future VC issuer nodes can be governed above Root by a committee or threshold process and published through the on-chain governance layer. Root consumes this state, enforces it, and issues protocol credentials. The current architecture therefore defines a federated-governance trust domain first. Federation among multiple independent trust domains or multiple Roots is treated as future work. OAN also assumes that participants can perform standard cryptographic verification. Agents and infrastructure nodes are expected to hold DID-style identity material and signing keys. Signed objects use canonical serialization and hash binding. Time synchronization is assumed to be good enough for timestamp freshness windows, while nonce storage handles replay protection. The trust posture is aligned with zerotrust and workload-identity principles: every privileged role and runtime request must be explicitly verifiable rather than implicitly accepted by network location [7], [8]. The protocol-facing trust path should not depend on private review evidence such as email, phone, web account login, or manually reviewed forms. Such evidence may support governance workflow, but runtime verification should rely on DID documents, credentials, signed envelopes, Root bulletin facts, Root-verified packages, and Discovery response proofs.
Layer
Purpose
Mechanism
Federated governance Root enforcement Registration review Subject control Root acceptance Package distribution Discovery exposure Runtime invocation
infrastructure lifecycle protocol authorization resource admission workflow prove DID ownership admit identity version publish identity state scoped query visibility verify request peer
threshold event Root-issued VC Registrar credential challenge signature signed Root record Root proof and hash domain authorization signed envelope
4. T RUST L AYERS OAN separates social governance, admission workflow, and runtime protocol verification. The layers are shown in Table II. This separation makes failures easier to reason about. If a Registrar is misconfigured, Root still checks Registrar authorization and credential proof. If a CDN returns a tampered package, Discovery recomputes hashes and verifies Root proof. If a Discovery node is stale or unauthorized, User Agents can reject responses that fail freshness or authorization checks. If a caller replays an old invocation, the Service Agent can reject it using nonce and timestamp validation. The threshold event in the first layer is a governance fact, not a protocol credential. A service node becomes protocol-authorized only after Root verifies the governance fact, validates the node’s DID-control evidence, and issues the corresponding infrastructure authorization VC. 5. C ORE E NTITIES AND N OTATION Let A be Agent subjects, R Registrar nodes, D Discovery nodes, V third-party VC issuer nodes, γ the governance layer, and ρ the Root service in one trust domain. For an infrastructure subject s ∈ R ∪ D ∪ V, let Gγ (s) be the latest governance status and V Cρ (s) be the Root-issued infrastructure authorization VC. The subject is protocol-authorized only if: Inf raAuth(s) = Active(Gγ (s)) ∧ V alid(V Cρ (s)). This predicate is deliberately conjunctive. Governance approval without a Root VC is not yet a protocol credential, and a stale Root VC without active governance state is not sufficient for new infrastructure service. A resource r has a versioned identity representation Mrv . The representation hash is H(Mrv ). A Root-accepted record contains at least: ⟨didr , v, H(Mrv ), status, t, σρ ⟩. The record binds resource DID, version, representation hash, lifecycle status, timestamp or logical time, and Root signature. The exact serialization may evolve, but the binding requirement is stable. Resource acceptance is Root anchored, while infrastructure eligibility is governance-backed and Rootcredentialed.
An identity representation is admissible to a Discovery node d only if it is well formed, anchored by Root, current, and authorized for d:
Service Agent DID + metadata
Registrar draft capability tags
Admissible(d, M ) = W ellF ormed(M ) ∧ Anchored(M ) ∧ Current(M ) ∧ Scope(d, M ).
Subject control + registration credential
This predicate separates business search from trust admission. A query may match many metadata fields, but only admissible candidates should be exposed.
Root verification accepted version
6. ROLE A RCHITECTURE The technical roles are intentionally separated. A. Root Root owns accepted-version state, capability-domain governance, bulletin facts, infrastructure authorization VC issuance, and verified package generation. It consumes infrastructure lifecycle state from the on-chain governance layer and verifies Registrar authorization, signed upstream envelopes, registration credentials, DID structures, document hashes, capability metadata, and status transitions. Root should be the source of truth for current accepted resource identity versions, but not the sole governance source for infrastructure-node lifecycle legitimacy. Root is not the business data plane. It should not need to observe every Agent-to-Agent call. This reduces operational load and avoids turning the trust anchor into a universal traffic proxy. In the upgraded design, Root acts as the policy enforcement point and protocol credential issuer for infrastructure nodes. A governance state transition does not by itself create a usable protocol credential. Root issues the infrastructure authorization VC after it observes active governance state and verifies DIDcontrol and operational materials. Conversely, Root should stop serving or accepting later requests from an infrastructure subject whose latest governance state is inactive, even if the subject still holds an old VC. B. Registrar Registrar owns onboarding assistance, draft workflow, product-type declaration, semantic description collection, capability-tag suggestion, subject-control challenge handling, registration credential issuance, and Root submission. It is an operational gateway between resource providers and Root. Registrar can improve usability and review quality, but it does not unilaterally decide final Root acceptance. C. Discovery Discovery owns package synchronization, Root proof verification, bulletin checking, authorization-domain filtering, local indexing, query handling, and response signing. Discovery is allowed to optimize search and ranking, but its first obligation is to avoid exposing non-admissible identity representations. In the on-chain governance model, Discovery consumes authorization events through an indexer or local cache; it does not need to embed proposal or voting logic in the default service runtime.
Root-verified package
Discovery index authorized scope
User Agent trusted invocation
Fig. 2. OAN identity lifecycle from Agent preparation to trusted invocation.
D. CDN CDN owns distribution of Root-verified packages and manifests. CDN improves availability and scalability but is not a trust authority. Consumers should verify package hashes, Root proof, metadata, and bulletin consistency. E. Resource Provider and Resource Consumer The Resource Provider controls a registered Agent Service, Skill, MCP Server, or Tool/API resource. The Resource Consumer is the relying Agent, application, developer tool, or human-facing client. Their trust relationship begins with Discovery verification and continues through signed invocation, credential checks, or artifact access according to the product type. OAN does not dictate the complete application conversation after the trust guard passes. 7. P ROTOCOL O BJECTS A. did:oan Identity Representation The identity representation is a did:oan DID Document compatible with DID Document concepts. It contains identifier, verification methods, resource product type, service endpoints or artifact references, semantic description fields, capability tags, credential references, OAN metadata, and version metadata. The current OAN reference implementation standardizes on did:oan for resource identity and no longer treats older method names as first-class protocol identifiers. The identity representation should include enough material to support: • key discovery and signature verification; • endpoint or artifact-reference discovery for supported product types; • capability-domain matching;
optional schema records, such as an OASF-compatible record, when a deployment chooses to use them. This package can carry an MCP Server entry, a Skill Type Native object Required OAN material Native responsibility identity, an Agent Service, or a Tool/API descriptor through Agent Service callable Agent endpoint, keys, claims task protocol Skill skill artifact artifact URI/hash, semantics package format the same lifecycle. Product-native metadata can remain in MCP Server MCP endpoint endpoint, protocol hints MCP behavior its native format, but it is placed inside or referenced by a Tool/API API endpoint endpoint/schema reference API semantics Root-verified envelope. This is the main technical difference between OAN and a narrow registry that only stores tool endpoints or Skill artifacts. • semantic search over labels, descriptions, examples, and use External artifact references should be explicit. A Resourcases; cePackage that points to a Skill file, OpenAPI document, • credential binding; MCP descriptor, or other artifact should include at least URI, • version and status tracking; media type, digest algorithm, digest value, expected version, • Root package generation and verification. The core product types are Agent Service, Skill, MCP and optional retrieval policy. OAN does not guarantee that Server, and Tool/API. Agent Service, MCP Server, and the remote artifact host is trustworthy; it guarantees that the Tool/API resources normally provide network endpoints. A reference and digest were part of the Root-verified package. Skill may instead provide an external artifact URI and enough Consumers must still verify the digest after retrieval. semantic metadata for discovery. OAN Discovery indexes the D. Capability Metadata DID Document and Root-verified package metadata; it does Capability metadata has a canonical component and an not need to host external artifacts. extensible component. The canonical component maps to B. Product-Type Metadata a Root-governed capability tree. The extensible component Product-type metadata declares how a resource should be allows application-specific tags, search hints, labels, or deinterpreted without forcing every resource into the Service scriptions. Only canonical capability domains should expand Agent shape. The minimal model should include product Discovery authorization. Custom tags may refine search within type, version, semantic labels, natural-language description, an authorized set, but they must not grant exposure outside example use cases, capability domains, endpoint descriptors or authorized domains. artifact references, and protocol hints. Product-native schemas remain outside the OAN core. For example, MCP tool listings, E. Registration Credential OpenAPI documents, or Skill package files can be referenced The resource registration credential binds: by URI and verified by hash when needed. • issuer Registrar DID; The product-type field is not an authorization shortcut. • subject resource DID; A resource marked as an MCP Server or Tool/API still • credential type and claims; needs normal Registrar onboarding, Root acceptance, package • registration binding, including DID-control evidence; verification, and Discovery authorization checks before it is • issuance time, validity, and proof. exposed. Root verifies issuer authorization, credential proof, subject Product-type metadata should separate trust fields from binding, credential status, product-type metadata, and validity search fields. Trust fields include DID, verification methods, before accepting a submitted representation. resource type, version, status, endpoint or artifact-reference hash, credential references, and critical extension markers. F. Subject-Control Challenge Search fields include labels, descriptions, examples, naturalSubject-control proof prevents a Registrar from issuing a language use cases, local tags, and ranking hints. A verifier may use search fields to rank results, but it must not let search credential for a DID that the applicant cannot control. The fields change authorization, current-version, or signature deci- challenge should bind draft identifier, subject DID, Registrar DID, expiration time, and nonce. The Agent signs the sions. challenge using an assertion-capable verification method from C. ResourcePackage as the Registry Object its DID document. Registrar verifies the signature and stores The ResourcePackage is the registry object that makes OAN evidence or a verifiable summary. resource-first. It is not just an endpoint listing or a marketplace G. Signed Upstream Envelope item. It binds: TABLE III I NITIAL OAN R ESOURCE T YPES
the did:oan resource identifier and DID Document hash; resource type, version, status, and semantic metadata; • endpoint descriptors or external artifact references; • Registrar credential evidence and subject-control binding; • Root acceptance proof, publication cursor, and package hash; • •
•
Privileged infrastructure writes, especially Registrar-to-Root submissions, use a signed upstream request envelope. The envelope covers sender DID, target audience, method, path, body hash, timestamp, nonce, purpose, and protocol version. Root verifies the sender’s current authorization and checks replay state before processing the body.
H. Root-Verified Package The package consumed by CDN and Discovery includes the DID Document, metadata, hashes, Root proof, publication cursor, subject version, status, and capability information. Discovery does not trust the CDN path alone; it recomputes hashes and verifies Root proof and bulletin consistency. I. Discovery Response Discovery responses are signed by the Discovery node and include returned candidates, provenance metadata, timestamp, query context, and proof. A relying User Agent can verify that the response came from a currently authorized Discovery node and that selected candidates trace back to Root-verified packages. 8. O N -C HAIN G OVERNANCE L AYER The upgraded OAN governance profile can use an onchain governance layer as the event source for infrastructurenode lifecycle state. Related SSI systems have also explored distributed trust anchors and lifecycle coordination [9], [10], [11]. The scope is intentionally narrow. It manages lifecycle state for Registrar, Discovery, and future third-party VC issuer nodes. It does not manage resource registration records, full identity documents, capability-tree updates, Root key rotation, or CDN service coordination. This layer is what prevents the architecture from degenerating into a traditional single-root directory. A committee or other threshold-governed operator set can decide infrastructure lifecycle state, while Root enforces the result and signs the protocol artifacts that ordinary OAN services understand. The governance layer is therefore the publication plane for federated trust decisions, and Root is the enforcement and credentialization plane. A. Lifecycle Scope The governance layer records and emits events for: • Registrar authorization, suspension, recovery, and revocation; • Discovery authorization, authorized-domain updates, suspension, recovery, and revocation; • third-party VC issuer authorization and revocation. The event stream replaces repeated status checks against Root for these infrastructure lifecycle facts. Registrar, Discovery, and VC issuer services consume indexed governance events, rebuild local authorization state, and enforce the resulting state in their own service logic. Root also consumes the same indexed state so that online VC issuance, Registrar submissions, Discovery notification, and future VC-issuer authorization can fail closed when the latest governance state is inactive or too stale. B. Governance Operation Boundary In the current version, governance operations are mainly performed by official operation clients, such as a Root operator console, governance command line tool, or governance
TABLE IV O N -C HAIN G OVERNANCE B OUNDARY In governance-layer scope
Outside governance-layer scope
Registrar lifecycle Discovery lifecycle VC issuer lifecycle Discovery domain updates Lifecycle events
Resource DID Document storage VC issuance or validation Resource metadata parsing Capability tree governance Root key and CDN coordination
service. These clients create proposals, submit votes, refresh proposal status, and manage participant lifecycle state. Registrar, Discovery, and VC issuer service nodes are event consumers by default. Their runtime should include event subscription or polling and local authorization-cache maintenance, but it should not need proposal, vote, or membermanagement code. This separation keeps service nodes simpler and keeps governance private-key handling inside official governance tooling until the ecosystem is ready to admit broader community operators. C. DID and VC Boundary The on-chain governance layer does not store, parse, validate, or issue DID Documents or Verifiable Credentials. It also does not model the internal schema of did:oan, resource identifiers, credential claims, credential proofs, resource metadata, or capability descriptions. Fields such as subject identifier, policy hash, metadata hash, effective time, expiration time, and status are only lifecycle references. DID and VC semantics remain off-chain OAN protocol responsibilities implemented by Root, Registrar, Discovery, VC issuer services, and SDK verification logic. Effective infrastructure authorization requires both an active governance state and a valid Root-issued infrastructure authorization VC. If governance state is inactive, revoked, unknown, or too stale to trust, a previously issued VC is not sufficient for new service. If governance state is active but Root has not issued a VC, the node has lifecycle approval but is not yet authorized at the OAN protocol layer. This distinction is important for interoperability: service nodes can validate ordinary protocol credentials, while infrastructure operators and indexers can validate the fresher governance state. D. Trusted Invocation Envelope Before invoking a callable resource such as an Agent Service, the Resource Consumer sends caller DID material, credentials, nonce, timestamp, target DID, request body hash, discovery provenance, and request proof. The Resource Provider checks caller identity, credential subject, target binding, body hash, signature, nonce uniqueness, and timestamp freshness. Non-callable resources such as Skill artifacts can still use the same discovery and package evidence before the consumer follows an external artifact reference. Table V shows the design discipline of OAN: each object has a producer, a verifier, and a trust purpose. Objects should not be overloaded. For example, a Discovery response does not
TABLE V C ORE O BJECT R ESPONSIBILITIES Object
Producer
Consumer
Purpose
Identity doc Reg credential Bulletin event Verified package Discovery response Invocation envelope Signed response
Resource provider Registrar gov. client Root Discovery Resource consumer callable provider
Registrar, Root Root infra nodes CDN, Discovery Resource consumer callable provider Resource consumer
subject keys onboarding proof lifecycle fact accepted version query provenance request binding response origin
TABLE VI R ESOURCE I DENTITY L IFECYCLE S TATES State
Owner
Meaning
draft control-verified credentialed submitted accepted published indexed superseded revoked
Registrar Registrar Registrar Registrar/Root Root Root/CDN Discovery Root Root
identity under preparation DID control proof passed registration credential issued Root submission in progress version accepted by Root package ready for sync admissible for query replaced by newer version no longer admissible
create Root acceptance; it only presents signed query provenance over already verified packages. A registration credential does not make an Agent discoverable; it only supports Root admission. 9. L IFECYCLE S TATE M ACHINE OAN treats identity as stateful. A typical resource identity moves through the states shown in Table VI. Create and update should use the same full-document path. Root should verify the complete new representation rather than applying ambiguous partial patches. This makes currentversion verification easier and reduces risk that old fields remain accidentally authoritative.
11) User Agent invokes Service Agent with a trusted invocation envelope. 12) Service Agent verifies the envelope and returns a signed response. 11. ROOT V ERIFICATION R EQUIREMENTS Root verification should be deterministic and auditable. At minimum, Root should verify: • signed upstream envelope integrity; • sender Registrar DID and authorization status; • timestamp freshness and nonce uniqueness; • request body hash binding; • registration credential proof and issuer binding; • subject DID binding between credential and document; • DID document structure and verification methods; • capability tags against the governed capability tree; • version and status transition validity. Rejection should be explicit. Silent acceptance with partial checks is more dangerous than a visible rejection because downstream Discovery and relying consumers may assume Root acceptance means the whole trust path was verified. 12. D ISCOVERY AUTHORIZATION OAN uses capability domains to control which Discovery node may expose which resource identities. Let G be the governed capability tree and Auth(d) be the authorized domain set for Discovery node d. If T (M ) is the set of canonical capability tags in identity representation M , then: ( Scope(d, M ) =
true, f alse,
T (M ) ∩ Desc(Auth(d)) ̸= ∅, otherwise.
Custom tags are allowed, but they cannot expand the governance domain. They are used only after coarse authorization for local refinement, ranking, or search.
10. L IFECYCLE F LOW The standard OAN lifecycle is: 1) Resource provider prepares a did:oan identity representation. 2) Registrar assists draft creation and capability-tag selection. 3) Resource provider proves control of its DID key. 4) Registrar issues a resource registration credential. 5) Registrar submits the complete representation to Root with a signed upstream envelope. 6) Root verifies Registrar authorization, envelope proof, credential proof, subject binding, DID structure, and capability metadata. 7) Root archives the accepted version and creates a Rootverified package. 8) CDN distributes the package. 9) Discovery synchronizes packages, verifies Root proof and bulletin facts, applies authorized-domain filtering, and indexes eligible Agents. 10) User Agent queries Discovery and verifies the signed response.
A. Extension Safety Rules Extensions are useful for local search quality and domain integration, but they must not weaken authorization. The following rules should hold for custom tags, plugin metadata, semantic embeddings, ranking features, and domain-specific attributes: • an extension must not cause Discovery to expose an identity outside the Discovery node’s authorized canonical domains; • an extension must not override Root acceptance, currentversion state, revocation state, or package verification results; • ranking and semantic matching must run only after admissibility checks; • unknown non-critical extension fields may be ignored, while unknown critical fields must cause rejection by verifiers that do not support them; • plugin output should be auditable enough for an operator to explain why an identity was indexed, rejected, ranked, or returned.
B. Synchronization Rules Discovery synchronization should be incremental. A publication cursor or watermark allows Discovery to fetch new packages without repeatedly scanning the entire Root archive. Discovery should verify each package before indexing and should track rejected packages with reasons. A package that fails Root proof, hash, bulletin, status, or authorization checks should not enter the query index.
Authorization soundness: compliant Discovery nodes do not index packages outside their authorized capability domains. • Replay resistance: signed upstream writes and invocation requests bind timestamp, nonce, target, path, and body hash. • Role accountability: each privileged decision is attributable to an authorized infrastructure identity. •
15. T HREAT M ODEL
C. Query Rules Discovery query can use keywords, capability tags, endpoint metadata, local indexes, or ranking signals. However, query matching should never bypass the admissibility predicate. The proper order is: verify package, check current state, enforce Discovery authorization, index admissible representation, then apply query matching and ranking. Semantic discovery is an implementation profile above this trust filter. GRAIL studies deep-granularity hybrid resonance and SLM-enhanced indexing for real-time Agent discovery [12]; OAN can use this kind of semantic indexing inside Discovery nodes to map natural-language user intent to verified resource metadata. The invariant is that semantic matching ranks or filters only candidates that are already admissible under Root proof, current-version state, and Discovery authorization. 13. T RUSTED I NVOCATION Trusted invocation is the bridge from discovery to protocolspecific interaction. OAN does not define every message that Agents exchange after the first verified request. It defines the guard that lets a Service Agent decide whether a caller and request deserve entry into the business protocol. A Service Agent should verify: • caller DID document and verification method; • caller credential proof and subject binding; • Discovery response proof and freshness, when included; • selected-service provenance against Root-verified package data; • target DID equals the invoked Service Agent DID; • timestamp is inside an allowed freshness window; • nonce has not been used before; • body hash matches the received body; • request signature verifies over the canonical envelope. If these checks pass, OAN hands control to the application protocol. That protocol may be A2A, MCP-adjacent tool invocation, a domain API, or a custom workflow. 14. S ECURITY P ROPERTIES OAN targets the following properties: • Provenance: accepted identity representations trace to a Root-authorized acceptance event. • Integrity: tampered identity representations fail hash or proof verification. • Freshness: stale, revoked, or superseded versions are not admissible after synchronization.
A. Malicious or Unauthorized Registrar An unauthorized Registrar may attempt to submit an identity to Root. Root rejects it because the signed upstream envelope signer is not active in Root authorization state. A malicious but authorized Registrar may issue poor credentials; OAN can detect invalid signatures, wrong subjects, and policy violations, but semantic review quality remains a governance problem. B. Tampered Package Distribution An attacker controlling a CDN path may return modified documents or metadata. Discovery recomputes hashes and verifies Root proof. Tampering should cause package rejection. C. Overbroad Discovery Exposure A Discovery node may try to expose packages outside its authorized domains. Compliant Discovery software should filter such packages before indexing. Relying parties can also verify Discovery authorization state. Non-compliant Discovery behavior remains auditable if returned candidates include provenance that contradicts authorization policy. D. Stale Lifecycle Cache A Registrar, Discovery, or VC issuer node may miss bulletin events because of network failure or local indexer downtime. The service should expose sync lag, last processed event sequence, and cache health. Authorization-sensitive actions should fail closed when lifecycle state is unavailable or too stale. E. Replay and Wrong-Target Invocation An attacker may replay a previously signed request or redirect a signed request to another Service Agent. Timestamp windows, nonce stores, target DID binding, path binding, and body hash binding reduce these risks. F. Semantic Misrepresentation An Agent may claim a capability that it does not perform well. OAN can bind and govern the identity claim, but it cannot fully prove business quality or truth of all semantic claims. Reputation, testing, certification, and runtime policy must complement OAN.
16. C OMPATIBILITY AND A DJACENT S YSTEM B OUNDARIES OAN is not a replacement for MCP, A2A, ANP, or other Agent protocols [5], [6], [13]. MCP can use OAN to verify the identity and authorization context of tool servers or clients before tool access. An MCP client may check that a server endpoint belongs to a Rootaccepted resource identity. An MCP server may use OAN credentials to decide whether a caller is allowed to access a tool. A2A can use OAN to verify Agent identity and discovery provenance before task exchange. An A2A Agent Card or capability description can be mapped into the OAN DIDstyle identity representation, while A2A remains responsible for task state and message semantics. ANP-like routes and Agent DID methods can be mapped to OAN identity documents and lifecycle checks. OAN’s distinctive contribution is not only having an Agent identifier; it is the governed identity lifecycle, Discovery authorization, package verification, and pre-connection trust guard around that identifier. A. Registry, Directory, and Schema Boundary Several adjacent systems solve neighboring but different problems: • MCP registries make MCP servers and server metadata discoverable, but they do not by themselves define DID/VCbased governance, Root acceptance, or infrastructure authorization [14]. • Skill marketplaces package and distribute Skills, while OAN gives a Skill a governed resource identity, lifecycle state, and verifiable discovery path. • OASF provides schema-level vocabulary for Agentic records, capabilities, Skills, and relationships [15]. OAN can embed or reference such records as package metadata. • ADS-style systems emphasize distributed Agent directory and discovery functions [16]. OAN emphasizes the trust path before and around discovery: Registrar onboarding, Root acceptance, package proof, governance-bounded Discovery, and signed verification. • ANS-style systems emphasize names for Agents [17]. OAN can carry names as aliases, but its core identifier is the did:oan resource DID. This boundary can be summarized as follows: OASF solves description, ADS solves directory, ANS solves naming, MCP solves tool interaction, Harness-style runtimes solve execution, and OAN solves the trust envelope that allows these objects to be registered, distributed, discovered, and approached safely. B. MCP Mapping An MCP server can be represented as an OAN MCP Server resource or as a service endpoint inside a did:oan identity representation. MCP tool metadata can be mapped to OAN service metadata and capability tags. Before MCP initialization or tool execution, a client can query OAN Discovery, verify the Discovery response, verify the Root package, and then
TABLE VII P ROTOCOL I NTEGRATION B OUNDARIES Protocol
Keeps responsibility for
OAN provides
MCP A2A ANP DID/VC Domain API
tools and resources task exchange Agent networking primitives business action
peer identity trust trusted discovery lifecycle governance Agent-specific policy pre-connection guard
TABLE VIII I MPLEMENTATION P ROFILES Profile
Required capabilities
Typical implementer
Agent Discovery Registrar Root Adapter Full stack
verify Discovery, sign calls sync packages, sign query draft, credential, submit enforce, accept, sign package map OAN to MCP/A2A/ANP all infrastructure roles
Agent runtime directory operator onboarding operator trust-domain operator protocol integrator trial network
bind the MCP endpoint to the verified resource identity. MCP remains responsible for tool listing, tool invocation, resource access, and streaming behavior. C. A2A Mapping An A2A Agent Card can be mapped to an OAN identity representation by binding Agent identifier, service endpoints, capability declarations, and verification methods. OAN Discovery can serve as the pre-session discovery layer. After the candidate is verified, A2A can take over task negotiation, message flow, task state, and long-running collaboration. This avoids forcing A2A to solve Root governance and Discovery authorization internally. D. ANP and DID Method Mapping ANP-like route structures and Agent DID methods can be used as identifier and networking substrates. OAN can consume such identifiers if they can be resolved into verification methods and service metadata. The OAN-specific part is the registration path, Root acceptance, verified package, and authorized Discovery semantics around that identifier. 17. I MPLEMENTATION P ROFILES OAN implementations do not need to implement every role at once. The following profiles define expected implementation depth. The profile model is important for adoption. A partner can begin with an Agent profile, later operate a Discovery node, and only eventually operate Registrar or Root infrastructure. This makes OAN deployable as a layered ecosystem rather than an all-or-nothing platform. 18. I MPLEMENTATION B OUNDARY The multi-repository implementation separates responsibilities:
oan-protocol-common: protocol objects, DID/VC helpers, crypto abstraction, package model, bulletin model, and clients. • oan-reference-services: Root, Registrar, Discovery, and CDN Rust services. • oan-agent-py: Python Service Agent and User Agent demos. • oan-examples: integration tests, demos, negative cases, and benchmarks. • oan-sdk-ts: TypeScript SDK for web, Node.js, console, and partner integrations. • oan-adapters: protocol adapters for MCP, A2A, ANPlike, and domain-specific protocol integration. • oan-discovery-plugins: Discovery ranking, semantic matching, and domain plugin extensions. • oan-deploy: deployment profiles and orchestration assets. • oan-web-console: operator-facing infrastructure console. • oan-operator-guides: runbooks, operating procedures, and cooperation guidance. • oan-site: static website and browser-side reference UI. • oan-trial-network: public trial-network records. • oan-release-tools: signed release and artifact verification tooling. • oan-design-docs: long-form design and governance rationale.
Latency envelope
This repository split is a technical design choice. It keeps protocol objects, runtime services, examples, deployment, and governance records from drifting into private incompatible variants. A. Normative Boundary The technical design distinguishes normative protocol requirements from reference implementation choices. Normative requirements include signature coverage, hash binding, nonce and timestamp validation, Root proof verification, currentversion checks, Discovery authorization filtering, failure reason reporting, and fail-closed behavior for security-critical verification. An implementation that omits these checks is not implementing the OAN trust model, even if it exposes similar HTTP routes. Reference implementation choices include concrete database engines, queue implementations, local cache layouts, index structures, deployment scripts, dashboard design, and default retry policies. These choices may vary across operators as long as the externally visible verification semantics and conformance results remain consistent. 19. P ERSISTENCE AND O PERATIONAL S TATE Root, Registrar, Discovery, and CDN each maintain state with different criticality. •
Root state is authoritative for authorization, accepted versions, publication, and bulletin facts.
Latency (ms, log)
•
104 103 102
registration P95 sync query
101 10
50
100 200
500 1000 2000
Identity representations
Fig. 3. Latency envelope across the single-node scalability experiment. The 2000-identity run exposes large-result query and synchronization pressure, which motivates pagination, index tuning, and queue hardening.
Registrar state is authoritative for draft workflow, subjectcontrol evidence, credential issuance, and submission attempts. • Discovery state is authoritative for local synchronization cursor, package verification results, rejected package reasons, and query indexes. • CDN state is authoritative for distributed package availability and manifest history, but not for trust decisions. SQLite is useful for the reference implementation and local experiments. Production deployment should support database abstraction and PostgreSQL or equivalent backends. Root should usually be migrated last because its state is the most central and has the highest consistency requirements. CDN and Discovery are natural earlier candidates for validating backend abstraction. •
20. P ERFORMANCE E NVELOPE The prototype evaluation has covered single-node scales up to 2000 identity representations and logical multi-node scales up to 1200 total identity representations. The reported results show correct lifecycle execution, negative-case rejection, authorized Discovery completeness, and internal degradedbaseline effects. The main current bottlenecks are large-result query processing, synchronization, publication, and submission pressure at higher scales. The performance target of this yellow paper is not to claim final Internet-scale capacity. It is to define the technical architecture and expose where production hardening should focus: persistent queue tuning, query result pagination, index optimization, distributed deployment, observability, database backend evolution, and more precise backpressure. The ablation experiment was executed on copied referenceservice workspaces so that the normal implementation remained unchanged. Each degraded variant removed one mechanism and then exercised the corresponding Root-node or Discovery-node code path over the same generated cases. The full path produced zero false acceptances or false exposures
Throughput (ops/s)
Throughput under increasing scale 25
registration end-to-end
20 15 10 5 10
50
100 200
500 1000 2000
Identity representations
False acceptances/exposures
Fig. 4. Registration and end-to-end throughput under increasing identity scale. Throughput remains measurable through the tested range, while the gap between registration and end-to-end throughput highlights downstream publication, synchronization, and query costs.
Ablation: removed checks expose invalid cases
12 10 8 6 4 2 0
Authz
full OAN degraded
filterin
g
al
edenti
Reg cr
ess Freshn
Fig. 5. Real-system degraded-baseline ablation. Removing authorization filtering, registration-credential verification, or freshness checks causes false exposure or false acceptance in the degraded variants, while the full OAN path rejects all tested invalid cases.
across the tested invalid cases, whereas the degraded variants exposed all cases designed to target the removed check. These results support the claim that OAN’s authorization, credential, and freshness checks are functional trust mechanisms rather than merely descriptive metadata. 21. C ONFORMANCE E XPECTATIONS Independent implementations should be able to pass conformance tests for: • did:oan identity document parsing and canonical hashing; • product-type metadata for Agent Service, Skill, MCP Server, and Tool/API resources; • external artifact reference digest verification; • registration credential proof verification; • subject-control challenge verification; • signed upstream envelope verification; • Root package verification; • Discovery response signature verification; • capability-domain authorization;
nonce and timestamp replay rejection; current-version and revocation handling. Conformance should include negative cases. A system that only succeeds on the happy path but accepts malformed credentials, stale packages, unauthorized Discovery exposure, or replayed requests is not OAN-compatible in the trust sense. Conformance should also distinguish product-specific expectations from common trust expectations. A Skill conformance vector may not require a network endpoint, but it must require artifact-reference integrity and semantic metadata. An MCP Server vector should require endpoint binding and protocol hints, but it should not require OAN to validate the full MCP tool list. A Tool/API vector should require endpoint or schema-reference binding, while API business semantics remain outside the OAN core. • •
22. API S EMANTICS This yellow paper does not freeze every HTTP route or JSON field, but it does define the semantic contract that APIs should preserve. A. Root APIs Root APIs can be divided into management, verification, publication, and read interfaces. Management interfaces update infrastructure authorization state, capability-domain state, and operational configuration. Verification interfaces accept signed Registrar submissions and return deterministic accept or reject results. Publication interfaces create or expose Rootverified packages and publication cursors. Read interfaces expose status, bulletin facts, accepted versions, and authorized infrastructure state. Root write APIs should require signed upstream envelopes. Root read APIs may be public or restricted depending on deployment, but the returned trust facts should be verifiable or derived from verifiable Root state. B. Registrar APIs Registrar APIs support draft creation, capability tree retrieval, capability tag suggestion, subject-control challenge generation, proof submission, credential issuance, and Root submission. A Registrar API should preserve the relationship between a draft, its DID document hash, its subject-control proof, its credential, and its Root submission result. Registrar should also expose enough status for a resource provider to understand why a draft cannot progress. For example, missing capability tags, failed DID control, expired challenge, credential issuance failure, and Root rejection are different errors and should not be collapsed into one generic failure. C. Discovery APIs Discovery APIs support status, synchronization, package inspection, rejected package inspection, and query. Query responses should be signed and should include enough provenance for a User Agent to verify selected candidates. Discovery should not expose packages that have not passed package verification and authorization filtering.
TABLE IX R EPRESENTATIVE E RROR C ATEGORIES Category
Example
Expected behavior
syntax crypto authz freshness replay binding scope state
malformed object bad signature inactive Registrar stale timestamp repeated nonce wrong subject DID out-of-domain package superseded version
reject before trust checks reject and log signer reject as unauthorized reject as expired reject and audit reject as mismatch do not index hide from query
If a Discovery node implements semantic matching, the API should make the semantic profile observable without making it part of the trust proof. For example, a response may include matched labels, embedding profile name, semantic score, or explanation fields inspired by SLM-enhanced indexing methods such as GRAIL [12]. These fields should be signed as response metadata for auditability, but verifiers must still base trust acceptance on Root package evidence, Discovery authorization, and candidate provenance. D. CDN APIs CDN APIs expose manifests, packages, documents, metadata, and publication history. CDN responses should be treated as distribution data, not trust decisions. Consumers should validate Root proof and hashes after fetching CDN content. 23. E RROR TAXONOMY Precise errors are part of interoperability. Table IX summarizes common error categories. Errors should be safe to expose. External responses may avoid leaking sensitive operator details, but internal logs should preserve enough information for audit and debugging. 24. C ONSISTENCY M ODEL OAN does not require every component to become globally consistent instantaneously. The architecture uses a staged consistency model.
B. Publication Consistency Publication from Root to CDN and Discovery can be asynchronous. A newly accepted Agent may not be immediately queryable. This is acceptable if the system exposes publication cursors, synchronization status, and retry behavior. The important property is monotonic progress without silently losing accepted packages. C. Discovery Consistency Discovery is eventually consistent with Root publication. It should never compensate for staleness by accepting unverifiable packages. If it has not yet synchronized a new accepted version, it may return no result or an older current result depending on Root state and cursor timing, but it should not return a package that fails current-version checks once it has learned the superseding state. 25. K EY M ANAGEMENT C ONSIDERATIONS Every privileged role depends on signing keys. Key management is therefore a first-class operational issue. A. Root Keys Root signing keys anchor the trust domain. They should be protected with the strongest operational controls in the deployment. Rotation must be planned so that relying parties can distinguish old valid Root records from forged records. A production design should publish key identifiers, validity windows, and rotation records. B. Registrar and Discovery Keys Registrar keys sign upstream submissions and credentials. Discovery keys sign query responses. Both roles should support revocation and rotation. Root authorization state should refer to current infrastructure DIDs and verification methods, so that deactivated keys stop being trusted. C. Agent Keys Agent keys prove subject control and sign runtime requests or responses. Agent key rotation should be handled as an identity update. Root should accept the new identity version only after verifying the complete updated representation and supporting evidence. 26. C ANONICALIZATION AND H ASHING
A. Root Consistency Root is authoritative for accepted resource identity versions, archived representations, package generation, and Root-issued protocol credentials. Infrastructure authorization is a joint state derived from active governance status and valid Rootissued VC state. Within one Root deployment, state transitions should be transactional enough to avoid accepting a version without a corresponding archive and publication state. Root should also avoid ambiguous current-version state for the same resource DID and should fail closed when its governancederived infrastructure cache is stale beyond the configured trust window.
OAN relies on hash binding. This makes canonicalization important. If two implementations serialize the same logical object differently, signatures and hashes may fail. Protocol objects should therefore define canonical JSON serialization or another deterministic representation. The following objects especially require stable canonicalization: • DID-style identity representation; • registration credential unsigned payload; • signed upstream request envelope; • Root-verified package metadata; • Discovery response payload; • trusted invocation envelope.
Test vectors should include canonical byte strings and expected hashes. This will reduce the risk that independent SDKs become incompatible despite using the same field names. 27. SDK A RCHITECTURE SDKs are necessary because OAN asks application developers to perform several security-sensitive checks. A good SDK should expose high-level functions while still allowing operators to inspect verification details. A. Agent SDK The Agent SDK should help Service Agents and User Agents create signed envelopes, verify peer DID documents, verify credentials, check timestamps and nonces, verify Discovery responses, and produce signed responses. It should not hide verification failures behind vague exceptions. B. Discovery SDK The Discovery SDK should help clients query Discovery nodes and verify signed responses. It should return both candidate data and verification status. A developer should be able to distinguish “no candidates matched” from “Discovery response failed verification”. C. Infrastructure SDK The Infrastructure SDK should support Root, Registrar, Discovery, and CDN administration. It should build signed upstream requests, verify Root packages, interact with capability trees, and support conformance tests. Governance operation support for the on-chain governance layer should be isolated in official governance tooling or a dedicated governance client. Default Registrar, Discovery, and VC issuer runtimes should depend on event subscription and authorization-cache APIs rather than proposal or voting APIs. 28. D EPLOYMENT T OPOLOGIES A. Local Development Local development can run one Root, one Registrar, one Discovery node, one CDN, one Service Agent, and one User Agent on a single machine. This topology is useful for reproducing lifecycle tests, negative cases, and small benchmarks. B. Single-Domain Pilot A single-domain pilot may separate Root, Registrar, Discovery, and CDN into different services or machines while keeping one operator. This topology tests network behavior, synchronization, package distribution, and operational observability.
D. Production Trust Domain A production trust domain should add durable databases, key management systems, rate limits, monitoring, backup, disaster recovery, release signing, and operator procedures. It should also define who can change Root authorization state and how emergency revocation is performed. 29. O BSERVABILITY Observability should be designed around lifecycle and trust events rather than only HTTP status codes. Operators should track: Registrar draft state transitions; subject-control challenge success and failure; • credential issuance counts and failures; • Root acceptance and rejection reasons; • Root publication queue depth and latency; • CDN package availability and manifest history; • Discovery synchronization cursor lag; • Discovery package rejection reasons; • query latency, result counts, and pagination behavior; • nonce replay rejection and timestamp failures. • •
These metrics help distinguish performance bottlenecks from trust failures. For example, a missing Discovery result may be caused by query mismatch, publication lag, out-ofdomain authorization, failed package verification, or Root rejection. Observability should make these causes separable. 30. F ORMAL I NVARIANTS The following invariants summarize the technical design. A. I1: Root Acceptance Integrity If Root accepts an identity version, then the accepted record must bind the resource DID, version, representation hash, status, and Root proof. Any later package claiming that acceptance must match this bound hash. B. I2: Registrar Authorization If Root accepts a Registrar-submitted identity, then the submitting Registrar must have been authorized at submission time and the signed upstream envelope must verify under the Registrar identity. C. I3: Discovery Scope If a compliant Discovery node indexes a resource identity, then at least one canonical capability tag in the identity must fall within the Discovery node’s authorized domain set or its descendants.
C. Multi-Operator Trial A multi-operator trial introduces independently operated Registrars and Discovery nodes. Root authorization state becomes more important, and capability-domain boundaries should be tested carefully. This topology is the first meaningful step toward ecosystem deployment.
D. I4: Current-Version Visibility If a resource identity version has been superseded or revoked and Discovery has processed the relevant Root state, then that version must not remain visible as the current admissible version.
E. I5: Invocation Binding If a Service Agent accepts a trusted invocation envelope, then the envelope signature, timestamp, nonce, target DID, body hash, and caller credential binding must have passed verification.
Fourth, resolve the Registrar identity and confirm active authorization. Fifth, verify the registration credential, including issuer, subject, validity, and proof. Sixth, verify DID document structure, verification methods, capability metadata, and subject binding. Seventh, check version transition rules. Only after these checks should Root create an accepted record.
31. BACKWARD AND F ORWARD C OMPATIBILITY OAN should evolve without breaking every implementation. Compatibility can be managed through typed objects, optional fields, protocol version fields, capability negotiation, and conformance profiles. Critical verification fields should be mandatory. Experimental metadata should be optional and must not change trust semantics unless a new profile explicitly says so. A useful compatibility rule is: old verifiers may ignore unknown non-critical metadata, but they must reject objects that require unknown critical trust semantics. This prevents silent downgrade when new security-relevant fields are introduced. This rule is especially important for schema and directory integration. An OASF-compatible record, ADS-style directory hint, marketplace descriptor, or runtime-specific extension can be carried as non-critical metadata when it only improves description, search, or routing. It must become a critical extension only when a verifier is expected to use it for trust decisions, such as authorization scope, endpoint authenticity, version validity, revocation, or credential binding. This keeps OAN extensible without letting ecosystem metadata accidentally redefine the trust model. A. Wire-Format Stability Future protocol specifications should freeze the wire-level details that are only described semantically in this paper. These include canonical JSON rules, required and optional fields, field naming, object version identifiers, signature preimage construction, hash algorithms, HTTP method and path versions, pagination tokens, timestamp formats, nonce scope, error-code registry, and critical-extension markers. Until those details are frozen, independent implementations should treat the reference objects and test vectors as the compatibility source of truth. A breaking field change should create a new object version or conformance profile. A nonbreaking extension should be optional, ignored by old verifiers, and prohibited from changing trust decisions unless it is explicitly marked as critical and supported by the verifier. 32. R EFERENCE V ERIFICATION A LGORITHMS The following algorithms describe expected verifier behavior at a high level. They are not tied to one programming language. A. Root Submission Verification Root submission verification should proceed in a fail-closed order. First, parse the request and reject malformed objects. Second, verify the upstream envelope signature and body hash. Third, check timestamp freshness and nonce uniqueness.
B. Discovery Package Verification Discovery package verification should parse the package, recompute hashes, verify Root proof, check bulletin evidence, check current-version state, and apply capability-domain authorization. Only packages that pass all checks should enter the query index. Failed packages should be retained in a rejectedpackage store with reason codes so that operators can debug synchronization and policy issues. C. User Agent Candidate Verification A User Agent should verify the Discovery response signature, timestamp, Discovery authorization state, selected candidate provenance, Root package hashes, and current-version status before constructing an invocation. The User Agent should not treat Discovery output as plain search output. It is signed trust evidence that still requires validation. D. Service Agent Invocation Verification A Service Agent should verify caller identity, caller credential, target DID, request path, body hash, timestamp, nonce, and request proof. It should also apply local authorization policy after OAN checks pass. OAN proves who the caller claims to be and whether the request is fresh and bound; local policy decides whether that caller may perform the requested business action. 33. PAGINATION , BATCHING , AND BACKPRESSURE The reference experiments show that large-result queries, publication, and synchronization are important bottleneck areas. The architecture should therefore treat pagination, batching, and backpressure as protocol-relevant engineering concerns. A. Pagination Discovery query responses should support pagination when result sets become large. Pagination metadata must be covered by the Discovery response signature so that a client can verify page boundaries and query context. A page token should not allow a client to bypass authorization checks or retrieve stale results outside the original query policy. B. Publication Batching Root-to-CDN and Root-to-Discovery publication can be batched. Batch records should include cursor ranges, package identifiers, status, retry count, and error state. Batching should improve throughput without hiding individual package verification failures.
36. R ELEASE AND S UPPLY-C HAIN I NTEGRITY
C. Backpressure Registrar submission paths should have explicit backpressure. A burst of draft submissions should not create unbounded Root requests or local contention. Backpressure can include bounded queues, single-flight protection per draft, timeouts, retry policies, and clear submission-state reporting. 34. D EGRADED B EHAVIOR Production systems must define behavior during partial failure. A. Root Unavailable If Root is unavailable, Registrar may continue draft preparation and local DID control checks, but it cannot claim Root acceptance. Discovery should continue serving previously verified current data within freshness policy, but it should not invent new Root facts. B. CDN Unavailable If CDN is unavailable, Discovery synchronization may lag. Existing verified index data may remain usable within policy, but new packages will not become visible until synchronization resumes. Operators should expose cursor lag and sync failures. C. Discovery Stale If Discovery is stale, User Agents may see incomplete results. This is safer than accepting unverifiable data. Discovery should publish status that allows clients and operators to understand synchronization lag. D. Nonce Store Failure If a Service Agent cannot check nonce uniqueness, it should fail closed for high-risk operations. For low-risk demonstrations, a degraded mode may exist, but it should be explicit and should not be presented as full trusted invocation. 35. DATA R ETENTION OAN deployments should define retention policies for drafts, credentials, accepted records, rejected submissions, package history, Discovery rejection logs, query logs, and invocation evidence. Retention should balance audit requirements with privacy and operational cost. Root accepted records and revocation history usually require longer retention because they define trust-domain history. Registrar drafts and private review evidence may need shorter or policy-specific retention. Discovery query logs may contain sensitive interest patterns and should be minimized or protected. Invocation logs should be controlled by the Service Agent’s business domain and privacy obligations.
The OAN software supply chain should be treated as part of the trust model. Signed releases, reproducible build metadata, dependency review, artifact hashes, and compatibility statements help operators know which implementation they are running. Release tooling should distinguish protocolcompatible changes from experimental or breaking changes. Reference services should publish version information and protocol object support. SDKs should publish test-vector compatibility. Trial networks should record which service versions are active so that experiments and demos can be reproduced. 37. P RODUCTION R EADINESS C HECKLIST Production deployment requires more than passing the reference integration tests. Operators should define and test at least the following controls: • durable nonce stores and timestamp skew policy for privileged writes and trusted invocation; • event synchronization lag monitoring for Registrar, Discovery, and VC issuer authorization state; • fail-closed authorization cache behavior when bulletin or Root state is unavailable or too stale; • package verification failure alerts and rejected-package retention; • Discovery index rebuild, cursor recovery, and query-result pagination; • bounded queues, backpressure, retry policy, and timeout policy for Registrar submission and Root publication paths; • key rotation, key compromise response, and operator accesscontrol procedures; • audit log retention for Root decisions, Registrar submissions, Discovery synchronization, and trusted invocation failures; • release verification, dependency review, and conformancetest records for deployed service and SDK versions. These controls do not change the protocol model, but they determine whether an OAN deployment can be trusted operationally by other organizations. 38. T EST V ECTORS AND P ROFILES Interoperability requires more than prose. OAN implementations should publish test vectors that allow another implementation to verify whether it computes the same hashes, signatures, and authorization decisions. A. Core Test Vectors Core test vectors should include a canonical DID-style identity representation, its canonical byte sequence, its expected hash, a valid registration credential, an invalid credential with a wrong subject, a valid upstream envelope, an envelope with a mismatched body hash, a Root-verified package, a Discovery response, and a trusted invocation envelope. Each vector should include the expected verification result and the reason for rejection when applicable.
B. Conformance Profiles OAN can define conformance profiles for different implementation depths. A basic identity profile may only parse and verify identity documents and Root packages. A Discovery profile must additionally enforce capability-domain authorization and sign responses. A trusted invocation profile must verify caller credentials, nonces, timestamps, target binding, body hashes, and request signatures. A full infrastructure profile must implement Root, Registrar, Discovery, and CDN semantics. C. Security Configuration Baseline A production profile should define minimum security configuration. Examples include nonce retention windows, timestamp skew tolerance, maximum request body hash age, key rotation procedure, rejected-submission logging, Discovery sync lag alerts, package verification failure alerts, and disabled degraded modes for high-risk operations. These values may vary by deployment, but the presence of explicit configuration is itself part of operational maturity. D. Interoperability Reports Independent implementations should be able to publish interoperability reports. Such reports should state which profiles are supported, which test vectors passed, which optional extensions are implemented, and which known limitations remain. This creates a clearer ecosystem than informal claims of compatibility. 39. P RIVACY AND DATA M INIMIZATION OAN identity representations are intended to be discoverable, but that does not mean every piece of operator evidence should be public. Private review evidence should remain in governance workflow or Registrar records unless there is a clear reason to publish it. Public packages should contain the material needed for verification and discovery, not unnecessary personal or operational data. Future privacy work may include confidential queries, selective disclosure, private capability matching, scoped credentials, and policies for sensitive Agent categories. The current design leaves room for these extensions by separating Root acceptance, package publication, and Discovery exposure. 40. O PEN T ECHNICAL W ORK Important next steps include: • multi-root and cross-trust-domain federation; • richer semantic Discovery and capability taxonomy governance; • privacy-preserving Discovery and confidential query processing; • durable nonce stores and stronger replay windows; • formal conformance tests for independent implementations; • production deployment profiles and operational security baselines; • MCP and A2A adapters with OAN pre-connection verification;
stronger observability for Root, Registrar, Discovery, and CDN; • package pagination and query-result pagination; • signed release tooling and reproducible artifact verification. •
41. C ONCLUSION OAN defines a technical architecture for governed resource identity and trusted Discovery. Its contribution is the coupling of federated infrastructure governance, Root-enforced resource provenance, current-version freshness, authorizationscoped Discovery, verified package distribution, and signed pre-connection validation. This coupling makes OAN closer to identity and governance infrastructure for the Agent Internet than to a plain Agent registry. It allows heterogeneous Agent protocols and implementations to interoperate on top of a shared trust substrate without forcing them into one task protocol or one Agent runtime. ACKNOWLEDGMENT The author thanks Jian Jin, Xie Jiagui, Li Bingqi, and Zhu Runkai for their support. R EFERENCES [1] W3C Credentials Community Group, “Decentralized identifiers (dids) v1.0,” https://www.w3.org/TR/did-core/, 2022. [2] W3C Verifiable Credentials Working Group, “Verifiable credentials data model v2.0,” https://www.w3.org/TR/vc-data-model-2.0/, 2025. [3] ——, “Verifiable credential data integrity 1.0,” https://www.w3.org/TR/ vc-data-integrity/, 2024. [4] W3C Credentials Community Group, “Did resolution,” https://w3c-ccg. github.io/did-resolution/, 2024. [5] Model Context Protocol Contributors, “Model context protocol specification,” https://modelcontextprotocol.io/specification/, 2025. [6] A2A Protocol Contributors, “Agent2agent protocol specification,” https: //a2a-protocol.org/latest/specification/, 2025. [7] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust architecture,” NIST Special Publication 800-207, 2020. [8] Cloud Native Computing Foundation, “The spiffe and spire project for workload identity,” https://spiffe.io/, 2022. [9] A. Grüner, A. Mühle, and C. Meinel, “Analyzing and comparing the security of self-sovereign identity management systems through threat modeling,” in Proceedings of the 38th ACM/SIGAPP Symposium on Applied Computing, 2023, pp. 389–396. [10] M. Glöckler, J. Sedlmeir, V. Schlatt, and N. Urbach, “A systematic review of identity and access management requirements in enterprises and potential contributions of self-sovereign identity,” Business & Information Systems Engineering, vol. 65, no. 4, pp. 421–440, 2023. [11] M. Popa, X. Yue, A. Boudguiga, A. Chibani, and H. Bécha, “Chaindiscipline: A blockchain-based self-sovereign identity framework for iot,” IEEE Transactions on Services Computing, vol. 16, no. 4, pp. 2571– 2584, 2023. [12] J. Xu, “Grail: A deep-granularity hybrid resonance framework for real-time agent discovery via slm-enhanced indexing,” arXiv preprint arXiv:2605.02489, 2026. [13] Agent Network Protocol Contributors, “Did:wba method specification: Web-based agent decentralized identifier,” https://agentnetworkprotocol. com/en/specs/03-did-wba-method-specification/, 2025. [14] Model Context Protocol Contributors, “Model Context Protocol Registry,” https://github.com/modelcontextprotocol/registry, 2026, accessed: 2026-06-05. [15] AGNTCY Contributors, “Open Agentic Schema Framework,” https:// github.com/agntcy/oasf, 2026, accessed: 2026-06-05. [16] ——, “Agent Directory Service Overview,” https://docs.agntcy.org/dir/ overview/, 2026, accessed: 2026-06-05. [17] K. Huang, V. S. Narajala, I. Habler, and A. Sheriff, “Agent name service (ans): A universal directory for secure ai agent discovery and interoperability,” arXiv preprint arXiv:2505.10609, 2025.
[18] J. Xu and B. Li, “Darwinnet: An evolutionary network architecture for agent-driven protocol synthesis,” arXiv preprint arXiv:2604.01236, 2026. [19] Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu, A. H. Awadallah, R. W. White, D. Burger, and C. Wang, “Autogen: Enabling next-gen llm applications via multi-agent conversation,” arXiv preprint arXiv:2308.08155, 2023. [20] L. Wang, C. Ma, X. Feng, Z. Zhang, H. Yang, J. Zhang, Z. Chen, J. Tang, X. Chen, Y. Lin, W. X. Zhao, Z. Wei, and J.-R. Wen, “A survey on large language model based autonomous agents,” Frontiers of Computer Science, vol. 18, no. 6, p. 186345, 2024. [21] D. B. Terry, M. M. Theimer, K. Petersen, A. J. Demers, M. J. Spreitzer, and C. H. Hauser, “Managing update conflicts in bayou, a weakly connected replicated storage system,” Proceedings of SOSP, pp. 172– 183, 1995. [22] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and T. Polk, “Internet x.509 public key infrastructure certificate and certificate revocation list (crl) profile,” RFC 5280, 2008. [23] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, “X.509 internet public key infrastructure online certificate status protocol ocsp,” RFC 2560, 1999. [24] Y. Ruan, H. Dong, A. Wang, S. Pitis, Y. Zhou, J. Ba, Y. Dubois, C. J. Maddison, and T. Hashimoto, “ToolEmu: Identifying the risks of lm agents with an lm-emulated sandbox,” in The Twelfth International Conference on Learning Representations, 2024. [Online]. Available: https://openreview.net/forum?id=NB5FP1A2yC