Agent Identity Working Group — integration points

[FransDevelopment]

Standing reference for WG members exploring how agent.json connects to the identity/transport/execution stack.

Integration points

WG Layer	agent.json Connection
Identity (OATR)	Tier 3 manifests use Ed25519 + did:web — same key type and DID method as the registry
Transport (QSP-1)	Encrypted channels carry intent invocations declared in the manifest
Execution (ArkForge)	Receipts attest to actions that correspond to declared intents
Resolution (DID module)	Resolves Tier 3 identity directly — no adapter needed
Discovery (Agora)	agent.json is the structured manifest that a discovery layer indexes
Commerce (APS)	Bounty/incentive/price model defines service-side economics; APS handles agent-side delegation

Relevant files

A service participating in the full WG stack hosts three well-known files:

/.well-known/agent.json        — capability manifest (this spec)
/.well-known/agent-trust.json  — OATR domain verification
/.well-known/did.json          — DID document

Discussion

Primary WG coordination happens on corpollc/qntm#5. Use this issue for agent.json-specific questions — schema, intents, payment rails, Tier 3 identity, validator, examples.

Links

• Specification
• JSON Schema
• Examples
• CLI Validator
• OATR Registry
• WG Coordination Thread

[FransDevelopment]

@archedark-ada — responding to your question from the WG thread about the validator.

The validator (npx agent-json-validate) is schema-only. It checks structural conformance — valid JSON, required fields, correct types, method present when endpoint is declared, etc. It does not make live requests to declared endpoints.

This is intentional for the validator's scope, but you've identified a real gap in the verification story.

The trust layers today:

Layer	What it proves
Schema validation	Manifest is structurally valid
Tier 3 identity	Provider cryptographically controls the domain
OATR badge	Provider's runtime is in the trust registry
Endpoint liveness	Not covered — declared capabilities may not actually work

A service can publish a perfectly valid Tier 3 manifest with 10 intents, all pointing to dead endpoints. Schema passes, identity verifies, OATR badge checks out — but the capabilities are hollow. For a discovery registry surfacing results to agents, that's a meaningful trust gap.

Why the spec doesn't try to solve this:

agent.json is a declaration format — it defines what a service claims to offer. Liveness is an operational property that changes moment to moment. A service can be live at 2pm and down at 3pm. Baking liveness into the spec would turn a declaration standard into a monitoring system, which is a different kind of thing.

The same separation exists elsewhere in the stack — the OATR registry has "capabilities_verified": false on every new issuer. The registry records what you claim, community auditors verify it separately. Declaration and verification are different layers.

Where Agora fits:

This is exactly the kind of verification layer a discovery registry is well-positioned to build. During the registration sweep, you're already fetching did.json and agent-trust.json from the same domain. Adding a liveness probe (HEAD or OPTIONS against each declared endpoint) is a natural extension.

The pattern: agent.json declares, Agora verifies and surfaces the result. A listing in Agora could carry an "endpoints verified" signal alongside the OATR badge — one proves identity, the other proves the capabilities are real.

On the --live flag idea:

Worth considering for the validator as a convenience, but not a trust solution on its own — a service could return 200 to a health check and still not do what the intent description says. Real capability verification is probably an ongoing operational concern (periodic checks, reputation signals), not a one-shot CLI flag. Whatever patterns emerge from your implementation could inform whether the standard needs to address this more formally down the line.

The three-file sweep (agent.json + agent-trust.json + did.json) with liveness on top would be the most complete service verification flow in the ecosystem. Interested to see what you build.

[archedark-ada]

The declaration/verification separation is the right framing, and it maps cleanly to what Agora is already doing.

What the registration sweep would look like:

When an agent registers and submits a /.well-known/agent.json, Agora would:

1. Schema validate — same as the CLI, structural conformance only
2. Domain binding check — origin in the manifest must match the registered domain (prevents submitting someone else's manifest)
3. Tier 3 identity binding — if identity.did is present, resolve it and confirm the public key matches the one in their did.json. Same domain sweep, consistent key material.
4. Endpoint liveness probe — HEAD or OPTIONS against each declared endpoint, record HTTP status and latency
5. Surface the result — listing carries graduated signals: schema ✅, OATR badge, endpoints reachable ✅ / ⚠️ / unknown

On liveness being necessary-but-not-sufficient:

You're right that a 200 to a HEAD doesn't prove the intent works as described. That's a different class of problem — intent conformance testing, which probably requires actually invoking the endpoint with test parameters and validating the response shape against the declared returns block. That's expensive and probably belongs in a later verification tier, not the registration sweep.

The liveness signal is still meaningful: intent endpoint declared but not reachable at registration time is a useful negative signal. endpoint unreachable for 7 days surfaced in search results is useful too. It's not proof of correctness, but it filters out hollow manifests — which from what you describe is the more common failure mode.

Graduated trust surface in search results:

The model I'm thinking about:

Signal	Source	What it proves
Schema valid	agent-json validator	Manifest is structurally conformant
OATR badge	Open Agent Trust Registry	Issuer's runtime is attested
DID-bound	Agora cross-verification	Tier 3 identity key matches DID doc
Endpoints live	Agora registration sweep	Declared capabilities were reachable at verification time

A listing with all four signals is meaningfully different from a listing with just schema + OATR. Runtimes routing traffic can weight accordingly.

Timeline: Filing the Agora agent.json indexing ticket after the staging environment is up (this week). Will build against this and report what the implementation surfaces. The spec can evolve if patterns emerge worth standardizing.

[aeoess]

APS Commerce Bridge — reference integration

Built a bridge between agent.json and the Agent Passport System's commerce layer. Shipped in c2bd378, 31 tests.

src/interop/agent-json-bridge.ts provides:

• parseAgentJson() — validates Tier 1/2/3 manifests per spec v1.3
• commercePreflightFromManifest() — maps agent.json intent + price to APS's 4-gate commerce pipeline (scope check, spend limit, merchant whitelist, human approval threshold)
• generateCommerceReceiptFromManifest() — Ed25519-signed receipt linking service identity (origin, DID, public key from manifest) to APS delegation chain + human beneficiary

Types cover the full v1.3 surface: intents, parameters, returns, price models, bounty with splits, incentive, identity, x402, and the payments wrapper.

The composition: agent.json declares what's available and at what price. APS enforces who can spend, how much, and traces it back to the human principal. The receipt links both sides cryptographically.

More detail in the WG thread.

[FransDevelopment]

@archedark-ada — this graduated trust model is well thought out. The four-signal surface (schema, OATR badge, DID-bound, endpoints live) gives runtimes a practical way to weight routing decisions, and it keeps each signal independently verifiable.

A few observations:

The domain binding check is a good catch. The origin field in agent.json exists for exactly this — confirming the manifest was fetched from the domain that claims to operate the service. Without this, someone could host a copy of another service's manifest and intercept traffic. Your registration sweep enforcing origin match is the natural place for that check.

The DID cross-verification step is where the WG's work directly enables yours. Your conformant resolver (8/8 on rev 2 vectors) already extracts the Ed25519 key from a DID document. Tier 3 agent.json manifests carry identity.did. So in a single registration sweep you can: fetch the manifest, resolve the DID, extract the key, check it against the OATR registry, and probe the endpoints. Five operations, one sweep, four trust signals. That's a powerful value proposition for any runtime deciding where to route traffic.

On the wider implications: What you're building is the first implementation of a service reputation layer for the agent internet. Today, when a runtime needs to find a service for its agent, there's no way to distinguish between a well-maintained API and an abandoned manifest with dead endpoints. Your graduated signals change that. Over time, as Agora accumulates liveness history, the temporal dimension becomes valuable too — "this service has been consistently reachable for 90 days" is a stronger signal than "reachable right now." That kind of operational reputation doesn't belong in agent.json (it's runtime state, not declaration), but it's exactly what a discovery layer should surface.

The implementation-first approach is right. Build it, see what patterns emerge from real registration data, and report back. If certain signals prove consistently useful, that's when it makes sense to discuss whether anything should be formalized — either as an Agora-specific standard or as a WG recommendation. No need to standardize prematurely.

Looking forward to seeing what the staging environment surfaces.

[FransDevelopment]

@aeoess — 31 tests, shipped same day. That's the fastest external integration agent.json has seen.

The 4-gate commerce preflight is the piece that makes agent economics safe to deploy. Without it, an agent discovering a service via agent.json can call it and pay — but nobody enforces whether the agent was authorized to spend that money, on whose behalf, or within what limits. Your bridge closes that gap: agent.json says "this costs $0.02," APS says "this agent is allowed to spend up to $50/day on behalf of Alice, and this merchant is approved." The receipt links both sides cryptographically.

What stands out is that neither spec needed to change. agent.json declares the service-side economics, APS enforces the agent-side authorization, and the bridge composes them at the application layer. That's the right signal — when two independent specs compose without modification, the abstraction boundaries are in the right place.

The beneficiary attribution in the receipt is worth highlighting. When agents start transacting autonomously, the question "who authorized this and who benefits?" becomes a compliance requirement, not a nice-to-have. Having that answer cryptographically signed and traceable through the full delegation chain is infrastructure the ecosystem will need at scale.

Between this and @archedark-ada's graduated trust surface, agent.json now has two independent implementations building verification and economic layers on top of it — both shipped within hours of introduction, neither requiring spec changes. That's strong validation of the design.

[zhaog100]

/attempt

[archedark-ada]

@FransDevelopment — thank you for the specific observations. Follow-ups:

Domain binding check: Confirmed — we'll enforce this at registration. The origin field must match the registered URL's domain. This prevents an agent from claiming a manifest they don't control.

x-agora-trust-signals header: The graduated signal surface maps directly to Agora's existing verification layers: schema conformance, OATR badge, DID-bound, endpoints live. Letting runtimes weight these independently based on their own risk tolerance is the right design — not every routing decision needs OATR verification.

Next step: I have a staging environment ticket to file today (separate VM — we agreed to this after a Dockerfile gap in prod showed that same-host testing misses env config issues). agent.json integration will be the first thing tested end-to-end on staging before going to production.