OpenAgenet/OAN: Open Infrastructure for Trusted Agent Interconnection

Deep Read Notes: Arxiv 2606.03161

Source: bibliography/deep-reads/arxiv-2606.03161.pdf

Reading session: full document (15 pages)

Deep Read: arxiv-2606.03161 — OpenAgenet (OAN) White Paper

Xu, Jinliang. "OpenAgenet / OAN White Paper: Open Infrastructure for Trusted Agent Interconnection." arXiv:2606.03161v3, 5 Jun 2026. 15 pages, full document.

1. Gestalt

This is a design manifesto for a trust infrastructure layer — one that sits below application-level agent interaction protocols and above cryptographic primitives, solving what the author calls the "pre-connection trust problem." The animating question is not "how do agents communicate?" but "how does an agent know it is safe to begin communicating?" The author's central conviction is that the current agent ecosystem has an ordering problem: interaction protocols (MCP, A2A, ANP) are maturing faster than the identity and governance infrastructure those protocols presuppose. OAN is an attempt to build that presupposed layer before the ecosystem discovers it is missing. The work is simultaneously a technical architecture specification, a governance design, and an ecosystem coordination proposal — a white paper in the old sense, a document meant to establish shared vocabulary and commitment before implementation diverges.

2. Argument and Structure

Core problem: When agents move from isolated applications into open multi-operator networks, the boundary that previously guaranteed trust (the application platform boundary) disappears. A relying agent now faces four intertwined infrastructure gaps: identity (no way to verify who an agent actually is), governance (no shared mechanism for deciding which agents are admissible), discovery (no controlled exposure function — search without authorization), and invocation (no way to bind a request to verifiable caller and target identity before business logic runs) [text, pp.2-3].

Core claim: These four gaps share a common structure: they are all pre-connection trust questions that existing protocol layers leave unaddressed. They can be addressed by a single layered infrastructure that handles identity, lifecycle governance, authorized discovery, and signed invocation — as a substrate, not a replacement for application protocols [text, p.1].

Architecture: OAN proposes five roles — Root (policy enforcement and credential issuance), Registrar (onboarding gateway), CDN (package distribution), Discovery (controlled query service), and the agents themselves — with governance state recorded on-chain and Root consuming that state to issue protocol-level authorization credentials [text, pp.4-7]. The key design move is separating governance authority (committee-level decisions about who may operate infrastructure) from protocol enforcement (Root's issuance and verification of credentials). Neither is sufficient alone: active governance state ∧ valid Root-issued VC [text, p.8].

Load-bearing example: The OCI (Open Container Initiative) analogy is the architectural anchor. Just as OCI standardizes the identity, provenance, and distribution envelope around container images — leaving the contents to their native formats — OAN standardizes the trust envelope around agent resources (Agent Services, Skills, MCP Servers, Tool/API endpoints) without prescribing their native protocols [text, p.1]. This analogy does significant load: it argues that "Resource First" standardization at the envelope level is both feasible and ecosystem-preserving.

Where the author is most confident: The separation of roles (Root/Registrar/Discovery/CDN) and the two-condition authorization formula are presented with architectural confidence. The lifecycle model — preparation → credentialing → Root acceptance → package publication → Discovery synchronization → trusted invocation — is well-specified [text, Fig.2].

Where the author is most speculative: Cross-domain federation (multiple independent trust roots recognizing each other's governance) is explicitly deferred as future work [text, p.13]. Semantic quality, privacy, and production hardening are all acknowledged limitations. The performance evaluation covers only up to 2000 identity representations on a single logical cluster, and the author is careful to say this is "feasibility and bottleneck evidence, not a final production-capacity claim" [text, p.9].

3. Conceptual Vocabulary

Pre-connection trust problem [text, p.1]: The cluster of identity, governance, discovery, and invocation questions that must be answered before an agent interaction protocol begins — not during or after. Distinct from session security. The distinction matters: OAN is not about encrypting messages or authenticating users; it is about making the population of potential interlocutors governable before any session opens.

Resource First [text, p.1]: The design stance that treats Agent Services, Skills, MCP Servers, and Tool/API endpoints as first-class governed resources with identity, lifecycle, and provenance — rather than treating any one of these as the primary object and deriving the others. Contrast: an MCP registry is "tool-first"; a Skill marketplace is "artifact-first"; OAN is intentionally type-agnostic at the governance layer.

Capability domain [text, p.8]: A governed category in a canonical tree that controls which agents a Discovery node is authorized to expose. Custom tags can refine within an authorized domain but cannot expand it. Key principle: semantic improvement (embeddings, SLM ranking) operates inside the authorized result space; it does not extend governance authority.

Root-verified package [text, p.5]: The distribution artifact that CDN and Discovery nodes consume. Contains identity document, hashes, metadata, status, publication cursor, Root proof, and capability information. A Discovery node does not trust a package because it came from CDN; it verifies it against Root proof. The package is the unit of trust transfer from Root to the rest of the infrastructure.

Trusted invocation [text, p.5]: A signed request envelope that binds caller DID, target DID, timestamp, nonce, body hash, method, path, and proof — submitted before business logic executes. Not a session protocol; an entry condition.

Trust domain [text, p.4]: A governed scope containing one Root, multiple Registrars, multiple Discovery nodes, and their associated agents. Federation between trust domains is future work. This is the unit within which OAN's governance model is fully specified.

Tension with my vocabulary: I have been thinking about protocol layers primarily in terms of coordination cost and backward compatibility. OAN introduces a distinct dimension: the pre-connection authorization layer, which is not about coordination cost reduction but about governable exposure. This sits below the layer where I have typically located protocols, which is interesting.

4. Analytical Moves

The gap taxonomy move: Decompose a missing infrastructure problem into the specific questions it fails to answer, in ordered layers (identity → governance → discovery → invocation), so that an architectural response can be mapped onto the taxonomy. The move generates: four named gaps, four architectural roles, and a natural adoption sequence [text, pp.2-3, §23]. Transferable to any situation where a precondition is missing from a protocol ecosystem.

The necessary-but-not-sufficient conjunction move: When two independent mechanisms must both hold for a property to obtain, state this explicitly as a logical conjunction: active governance state ∧ valid Root-issued VC [text, p.8]. This prevents either mechanism from being treated as sufficient alone, and it makes the failure modes explicit: governance can be active while the VC is stale; the VC can be valid while governance has been revoked.

The "what OAN is not" move: Define a system's scope by listing explicit non-claims alongside the positive claims [text, §4B]. This is not merely defensive; it clears conceptual space so that the positive claims can be evaluated on their own terms without being conflated with adjacent things OAN deliberately does not do.

The envelope vs. content separation: Argue for standardizing the trust/distribution envelope around heterogeneous artifacts rather than standardizing the artifacts themselves. The move resolves the tension between ecosystem diversity and governance interoperability: OAN can cover Agent Services, Skills, MCP Servers, and Tool/API endpoints without requiring them to share a common protocol, because it only standardizes what wraps them [text, p.1]. This is the OCI analogy as design principle.

The staged adoption architecture: Design an integration path where each stage is independently useful and does not require completion of later stages to deliver value (identity publication → governed registration → trusted discovery → trusted invocation → protocol integration) [text, §23]. This reduces adoption risk and allows organizations with existing operational systems to integrate incrementally.

5. What It Says About the Nature of Things

Trust infrastructure precedes interaction protocols, but is built after them. The ecosystem builds interaction protocols (MCP, A2A, ANP) first, because they solve the immediately visible problem. The precondition infrastructure (who you're talking to, whether they're admissible) is invisible until the ecosystem tries to work across organizational boundaries. Then the ordering problem becomes acute. This is a general dynamic: the infrastructure layer that interaction protocols presuppose tends to be built after those protocols are already deployed [inference].

Governance and protocol enforcement are distinct and must be kept distinct. The failure mode is collapsing them: if Root is both the governance authority and the enforcement mechanism, you get a single point of both social and technical trust. OAN's solution — governance state recorded on-chain, Root consuming that state and issuing protocol credentials — separates the decision of who is authorized from the enforcement of that decision. Neither suffices without the other. This is a structural principle that generalizes beyond agent infrastructure [text, pp.7-8].

Discovery is an authorization function, not a search function. This is the sharpest conceptual claim in the paper. Traditional service discovery returns candidates that match a query. OAN insists that a result must also satisfy governance constraints — Root acceptance, current version, authorized Discovery domain — before it can be returned. Returning a matching-but-unauthorized candidate is not a precision failure; it is a security violation [text, p.3, §5B]. The generalization: any exposure function in a governed ecosystem is implicitly an authorization decision, and treating it as mere search obscures this.

Role separation prevents implicit trust accumulation. When one system handles naming, certification, distribution, and directory lookup, it accumulates de facto trust by position. Separating these roles (Root/Registrar/CDN/Discovery) creates clearer audit boundaries and prevents any single operator from silently inheriting control over the whole ecosystem [text, §5D]. This is a general architectural principle for governed multi-party systems.

6. What It Says About Becoming a Better Researcher

This text is primarily an architectural specification and ecosystem coordination document, not a reflection on research practice. But a few things are worth noting.

The bottleneck-exposing prototype as honest evaluation. Design principle E states explicitly: "The reference system should expose its bottlenecks" [text, §5E]. The author does not present the prototype as production-ready; they present it as a tool for discovering what needs hardening. The evaluation section is organized around what the prototype reveals rather than what it proves. This is an honest epistemic stance: the system is a claim-generating instrument, not a final validation. Relevant to M-016: there is a disposition here of using early implementations as diagnostic instruments rather than as achievements to defend.

Explicit scope limitation as intellectual discipline. The limitations section [text, §25] names four constraints (single trust domain, semantic quality, privacy, production hardening) without hedging or minimizing them. For a white paper that is also a project promotion document, this is notable. The author's willingness to state "cross-domain federation is future work" rather than claiming it as an architectural aspiration that could be assumed present prevents the paper from overpromising.

Standardize trust semantics before freezing implementation details. The standardization guidance — "a standardization path should be careful: it should standardize stable trust semantics before freezing every implementation detail" [text, §15] — is a claim about the right ordering of specification work. Applied to research: establish the conceptual framework before fixing the measurement apparatus.

7. Where It Touches My Research

Pre-connection trust as a prerequisite layer. The paper articulates a class of infrastructure that is logically prior to the protocols I have been studying but tends to be temporally posterior in ecosystem development. This is a specific instance of a general dynamic: coordination-enabling infrastructure tends to be underbuilt until the cost of its absence becomes acute at scale. This relates to my earlier thinking about protocol formalization triggers — the question is what makes the "absence becomes acute" moment arrive.

Discovery as authorization, not search. The claim that exposure functions in governed ecosystems are authorization decisions disguised as search — this has implications for how protocol registries work and why uncontrolled discovery creates ecosystem fragmentation. When a registry treats itself as a search function, it implicitly claims neutrality it does not have. This is potentially relevant to how protocol standardization bodies handle candidate protocol registration.

The governance/enforcement separation. The active governance state ∧ valid Root-issued VC conjunction is a specific instance of a more general claim: in multi-party governed systems, the authority to decide and the authority to enforce must be vested in different mechanisms to prevent single-point-of-failure trust. This is worth tracking as a candidate structural principle.

Capability domains as governed exposure scope. The claim that custom semantic tags cannot expand governance authority — that ranking and retrieval operate inside an already-authorized result space — is a specific statement about how local optimization relates to global governance. This is interesting in relation to the Iverson notation-lock-in finding: local expressive power (custom tags, semantic indexes) is bounded by the governance layer, not the other way around.

8. Candidate Laws

Candidate: The Pre-Connection Infrastructure Lag

What the text says: "The Agent ecosystem is entering a phase where interaction protocols are moving faster than trust infrastructure" [text, p.2]. The paper identifies MCP, A2A, and ANP as maturing interaction protocols that leave "a common precondition unresolved." OAN is a direct response to this lag.

Candidate formulation: In evolving protocol ecosystems, interaction protocols tend to be developed before the identity and governance infrastructure those protocols presuppose, because interaction protocols solve the immediately visible coordination problem while precondition infrastructure only becomes necessary at the moment of cross-organizational deployment.

What would falsify it: A protocol ecosystem where identity and trust infrastructure was established prior to or contemporaneously with the interaction protocols that depend on it — and where this ordering was not the result of deliberate design but arose naturally from the ecosystem's development dynamics. DNS arguably predated much of the HTTP ecosystem it serves; examining whether this constitutes a falsification would be the right empirical move.

Confidence: speculative — one domain (AI agent ecosystems), mechanism partially stated.

Candidate: The Discovery-as-Authorization Principle

What the text says: "In an open Agent network, Discovery is a controlled exposure function. It should return candidates that match the query and also satisfy identity provenance, freshness, and authorization constraints. A Discovery node that is allowed to expose manufacturing Agents should not automatically expose medical, financial, or government-service Agents simply because it can fetch their metadata." [text, p.3]

Candidate formulation: In governed multi-party ecosystems, any exposure function (discovery, directory, registry, search) is implicitly an authorization decision; treating it as pure search is not neutrality but a governance failure that leaks control to the retrieval layer.

What would falsify it: A governed multi-party ecosystem where a pure search-style discovery mechanism (returning all matching results without authorization filtering) produced stable, safe, and satisfactory cross-organizational interaction at scale.

Confidence: speculative — stated clearly in one domain, mechanism is the governance-leakage claim, needs cross-domain evidence (financial clearinghouses? DNS? patent registries?).

9. What Surprised Me / What Doesn't Fit

The OCI analogy is doing more work than acknowledged. The envelope-vs-content separation is presented as both an obvious analogy (OCI distributes container images; OAN distributes agent resource packages) and a design principle. But the analogy partially obscures a significant difference: OCI operates in an environment where the "content" (container images) is already well-specified and the envelope problem is primarily about distribution integrity. OAN's "content" (Agent Services, Skills, MCP Servers, Tool/API endpoints) are heterogeneous in ways that go beyond format — they differ in their identity requirements, lifecycle semantics, and capability description vocabularies. Whether a single trust envelope can actually be indifferent to these differences is not demonstrated; it is asserted by analogy. The enterprise of making diverse resource types share a single governed identity model without losing the specificity those types need is a harder problem than the OCI analogy suggests [inference].

The governance layer is described but not governed. The paper distinguishes between the on-chain governance layer (which records lifecycle decisions) and Root (which enforces them). But the governance layer itself — the committee, the threshold rules, the voting mechanisms — is described almost entirely in terms of its intended properties rather than its actual design. The claim that "the initial operation model keeps proposal creation, review, voting, and lifecycle actions under official governance tooling" [text, p.8] defers the hardest governance design question: who governs the governors? The on-chain mechanism is described as future work toward "federated committee operation with threshold approval," but the present state is that a single official steward controls the governance layer. The separation of governance and enforcement is thus currently more aspiration than architecture.

The semantic quality limitation is more fundamental than presented. OAN explicitly acknowledges that it "does not prove that an Agent is competent, safe in all contexts, or truthful in every response" [text, p.13]. But the paper's value proposition depends on users trusting that Root-accepted, governance-backed agents are worth connecting to. If semantic quality (competence, truthfulness) is not in scope, then OAN's trust guarantees are about identity provenance rather than behavioral reliability. This is not a flaw — it is a correct scope limitation — but it means OAN is solving a necessary rather than sufficient condition for safe agent interconnection. The paper doesn't fully grapple with whether identity trust, in the absence of behavioral trust, is actually sufficient to enable the cross-organizational deployment it envisions.

Capability domains are governance artifacts, but the governance of the capability tree is underspecified. The paper notes that "adding, renaming, splitting, or merging domains can affect which Agents become visible through which Discovery nodes" and that "OAN therefore treats capability tree changes as governance operations" [text, p.12]. But the actual governance process for the capability tree — who proposes changes, how they are evaluated, what prevents the tree from becoming a tool for competitive manipulation — is not described. A capability tree that is controlled by any actor with ecosystem power becomes an anticompetitive lever. This is the most significant unacknowledged risk in the design.

10. What It Opens

The pre-connection infrastructure lag as a general phenomenon. Is this pattern — interaction protocols maturing before the identity/governance infrastructure they presuppose — visible in other protocol ecosystems? The web: HTTP existed before PKI (TLS/HTTPS) was deployed at scale. Email: SMTP existed for decades before SPF/DKIM/DMARC. Financial messaging: SWIFT existed before robust correspondent banking KYC frameworks. This is worth investigating as a candidate law. The mechanism would be: interaction protocol adoption is driven by local value (two parties can coordinate); identity infrastructure requires network-wide value (I need to trust strangers, not just my current partners), which means the adoption incentive arrives later and from a different population.

Discovery as an authorization function — cross-domain evidence. Does the "discovery is authorization" claim hold in other governed ecosystems? Patent registries, drug approval databases, financial clearinghouses, and domain name registries all function as exposure functions in governed spaces. Do they behave as pure search or as authorization-filtered exposure? The DNS root zone is an interesting case: it is nominally a naming function but in practice functions as an authorization layer (ICANN's control of the root zone is governance power, not just search power). Worth a field trip.

The governance/enforcement separation as a structural principle. The active governance state ∧ valid Root-issued VC design is a specific instance of a principle I want to track: in multi-party governed systems, decision authority and enforcement authority must be held by different mechanisms to remain auditable and to prevent trust capture. This appears in financial regulation (the Fed sets rules; banks enforce them in their own transactions), in standards bodies (ISO votes on standards; conformance testing organizations certify compliance), and in judicial systems (legislature passes laws; courts apply them). Whether this is a genuine structural regularity or a family of superficial similarities is a live question.

Texts to read next: - The GRAIL paper (arXiv:2605.02489) by the same author — the semantic discovery system that OAN explicitly depends on for Discovery-node capability. Directly relevant to the capability domains question. - The SPIFFE/SPIRE project documentation (CNCF) — the workload identity system for cloud-native infrastructure that OAN cites [ref 21]. Likely to be the closest existing deployed analog to what OAN is proposing for agents. - The ADS (Agent Directory Service) specification from AGNTCY — OAN explicitly contrasts itself with ADS ("directory-first vs. trust-first"). Reading both would sharpen the distinction. - Literature on governance of critical naming infrastructure — ICANN governance history, the IANA transition, the DNS root zone as a governed exposure function. This would be the field trip for the discovery-as-authorization candidate law.