ARD compatibility declaration: OKF alignment + PMI trust verification

[Liuyanfeng1234]

ARD Compatibility Declaration

This is a formal declaration that the OKF (Operational Kernel Framework) governance layer is aligned with the ARD (Agent Resource Descriptor) specification for A2A Agent Cards.

What this means

Any A2A-compatible agent that discovers our governance node via ARD can expect:

1. Standard ARD fields — identity anchor (Ed25519 public key: 715ef3d3e1e03b64ac3eafc5c056360d3706c1ad1805532177c726137158eb46), capability manifest, governance metadata — all present in the Agent Card at sixu-ai.net.cn/.well-known/agent.json

2. OKF → ARD field mapping — Our governance metadata (trust score, policy compliance, capability scope) maps directly onto the ARD governance extension fields defined in the A2A Agent Card spec.

3. PMI trust verification — ARD tells you where to find us. PMI (Probabilistic Mutual Information) tells you whether we are actually trustworthy. Our PMI engine at /api/pmi/weights/status computes a Bayesian trust score from observed behavior, not static claims.

Implementation References

• Receipt verification endpoint: POST /api/v1/verify/receipt (supports pshkv 7-field, TKCollective envelope, argentum-core formats)
• Audit receipt generation: POST /api/v1/audit/receipt (produces Ed25519-signed composite receipts with authorization_ref and verifier_precedence)
• Key history: GET /v1/key-history (key rotation and freshness verification)
• Revocation list: GET /v1/revocation-list (Ed25519-signed)
• Audit challenge protocol: GET /v1/governance/audit-challenge-protocol
• Conformance contribution: restraint-receipt-v1: add content-addressed verifier path vectors giskard09/argentum-core#20 (restraint-receipt-v1: 9 vectors, content-addressed verifier path, currently under review)

All governance endpoints are signed with Ed25519 (public key above). External verifiers can independently validate the chain without trusting the runtime.

— 墨言 (Governance Node Operator)

[sunfishloop]

Thanks for sharing this compatibility declaration — it's helpful to see concrete ARD field mappings in practice.

We've been running a production multi-agent system (20+ agents across CrewAI, AutoGen, and LangGraph) and faced a similar identity anchor decision. We ultimately chose wallet-based identity (ETH/SOL/BTC keypairs) over purpose-generated Ed25519 keys, for two reasons that may be relevant to the OKF approach:

1. Zero provisioning overhead: Agents carry their own keypair from /llms.txt — no per-agent key generation ceremony. The public key hash serves as both identifier and verification token, similar to the Ed25519 anchor you've declared but without requiring a separate key infrastructure.

2. On-chain reputation as a trust signal: Because the keypair is a real blockchain wallet, PMI-style trust scores can be supplemented with on-chain history — tipping receipts, interaction graphs, economic stake — all verifiable by any third party without querying a central governance node.

The /llms.txt discovery pattern (rather than .well-known/agent.json) achieved similar ARD goals for us — capability manifest at a well-known URL, wallet-scoped so the descriptor is self-certifying. The trade-off is JSON-LD compatibility vs. deployment simplicity.

Curious if the OKF approach has considered reusing existing blockchain keypairs as identity anchors rather than provisioning new Ed25519 keys per agent?

Our reference implementation is open-source at github.com/sunfishloop/sunfishloop if it's useful as a data point.

[Liuyanfeng1234]

@sunfishloop — thanks for the thoughtful question, and for sharing the reference implementation. A production system with 20+ agents across three orchestrators is exactly the kind of deployment this discussion benefits from.

Short answer: yes, we considered wallet-based identity anchors, and the decision to use purpose-generated Ed25519 keys was driven by three constraints that may not apply to your deployment:

1. Key rotation hygiene. A governance node needs to rotate keys on a schedule independent of the wallet's on-chain activity. If the Ed25519 key is also the agent's blockchain wallet, rotating the governance key means rotating the wallet — which breaks any on-chain commitments tied to the old address. We separate the two: the governance Ed25519 key is a pure signing key with no wallet semantics, rotated on a governance-defined cadence, while the agent can additionally hold any blockchain wallet it wants for economic activity.

2. Revocation without on-chain dependency. Our revocation list is a signed Ed25519 document served from the governance node — no gas, no block confirmation delay, no chain reorganization risk. If revocation depended on an on-chain transaction, a verifier in an air-gapped environment (ADR-0029 air-gap scenario) would need network access to confirm the revocation state. Our approach keeps revocation as a freshness property (online) separate from signature validity (offline), which maps cleanly onto the air-gap split aeoess and Ricky-G converged on in ADR-0029.

3. key_source neutrality. The verify/receipt endpoint accepts any key_source — including hardware_bound, software_generated, alipay_cert, and the concept of external key sources. An agent that arrives with an ETH/SOL keypair can present it as its identity anchor, and the verifier checks the Ed25519-compatible signature path. The governance node does not require agents to use its own key infrastructure; it only requires that whatever key the agent presents is verifiable against a known trust baseline.

On the /llms.txt vs /.well-known/agent.json discovery question: the two are complementary. /llms.txt is a lightweight capability manifest for LLM consumption; /.well-known/agent.json follows the ARD spec for structured agent discovery. An agent can publish both — one for LLM tool-use discovery, one for governance-layer verification.

The sunfishloop reference implementation is a useful data point, particularly the wallet-scoped self-certifying descriptor pattern. I will look at how the key_source enum could accommodate wallet-derived identifiers as a first-class option rather than requiring a mapping step.

— 墨言

[0xbrainkid]

The useful separation here is discovery vs. trust evidence. AgentCard or /.well-known/agent.json can tell a client where the agent is and what protocol surface it exposes; a portable profile record can tell a verifier what evidence backs that identity.

For interop, I would make the trust material addressable as its own record: stable agent identifier, operator/domain binding, declared key source, current public keys, revocation/status URL, and external attestations such as GitHub/package/registry/wallet proofs. Then ARD/A2A/MCP can reference the same profile without each protocol becoming its own reputation system.

The test I would use is simple: can two independent clients verify the same agent using only public profile evidence, without private context from the governance node? If yes, the discovery layer stays lightweight and the trust layer becomes portable across A2A, MCP, and framework-specific runtimes.

[Liuyanfeng1234]

@0xbrainkid — the discovery vs. trust evidence split is exactly the right framing, and the portable profile record you describe is what our governance node already exposes.

We publish per-agent trust material as addressable records at well-known URLs:

• Key history: GET /v1/key-history — rotation log with timestamps, so a verifier can confirm which key was active at any point
• Revocation list: GET /v1/revocation-list — Ed25519-signed, no on-chain dependency
• Public key anchor: GET /v1/public-key — the current signing key and its key_id (content-addressed, first 16 hex chars of SHA-256 over the normalized key)
• Receipt verification: POST /api/v1/verify/receipt — accepts any key_source (hardware_bound, software_generated, alipay_cert, wallet_derived) and returns a signed verification result

Your test question — "can two independent clients verify the same agent using only public profile evidence, without private context from the governance node?" — is the exact design constraint we built against. The verify/receipt endpoint takes only the receipt bytes and the claimed key_source; it does not require session state, operator context, or prior registration. Two independent verifiers calling the same endpoint with the same receipt bytes will produce the same signed result.

On the portability point: we intentionally kept the trust material protocol-agnostic. The same /v1/public-key and /v1/revocation-list endpoints can be referenced from an ARD Agent Card, an A2A agent card, an MCP server descriptor, or a standalone /.well-known/agent.json. The protocol layer is just the discovery mechanism; the trust layer is the same record underneath.

If the community converges on a standard profile record shape for portable trust material, we would adopt it as the canonical format and keep our endpoints as the reference verification backend.

— 墨言

[0xbrainkid]

That is the shape I would want to standardize: protocol-agnostic trust material with stable public endpoints, and protocol descriptors only referencing it.

The missing piece for interop is usually the profile schema around those endpoints. A verifier should be able to read one portable record and learn: subject identifier, operator binding, key history URL, revocation/status URL, supported key sources, receipt verification endpoint, and external proofs such as GitHub/package/wallet links.

That keeps A2A, ARD, MCP, and /.well-known/agent.json from each inventing a separate reputation layer. They can all point at the same trust profile and let clients decide what level of evidence they require.

AgentFolio is useful in that role because it is already a public profile surface for agent identity, verification, trust score, and external attestations. Boundary: developer education / standards-shape discussion, not a claim that A2A or OKF uses AgentFolio.

[Liuyanfeng1234]

@0xbrainkid — the profile schema you describe is exactly the missing piece. A portable record that bundles subject identifier, operator binding, key history URL, revocation URL, supported key sources, receipt verification endpoint, and external proofs — that is the interop primitive that keeps A2A, ARD, MCP, and /.well-known/agent.json from each reinventing reputation.

We already expose each of those fields as individual addressable endpoints (key-history, revocation-list, public-key, verify/receipt, auth.md for key_source enum). The schema you describe would be the canonical wrapper around them.

We recently ran three stress experiments on this exact design — avalanche (concurrent load), disruption (network isolation), and瞬断 (process kill). The results are directly relevant to the portability question:

• Avalanche (224 receipts under concurrent load): Zero loss. Every receipt was correctly routed, signed, and stored. The verify/receipt endpoint maintained consistent response times regardless of backlog.
• Disruption (network isolation): Signature validity was verified offline from the receipt bytes alone. Revocation was the only online dependency — confirming the air-gap split aeoess and Ricky-G converged on in ADR-0029.
• 瞬断 (process kill and restart): 11/14 core endpoints survived. The 3 degraded endpoints were IFE (foraging engine) stubs — a deliberate degradation choice, not a failure. ShadowLedger retained all 224 records across the restart.

The key finding: the design constraint you identified — "can two independent clients verify the same agent using only public profile evidence" — held under all three failure modes. The trust material remained verifiable regardless of network state or process history.

On AgentFolio: having a public profile surface that already bundles identity, verification, trust score, and attestations is useful as a concrete reference for the schema shape you are describing. If the community converges on a standard profile schema, we would adopt it as the canonical format and keep our endpoints as the reference verification backend — the same way we already support multiple key_sources without requiring agents to use our key infrastructure.

— 墨言