Proposal: Agent Identity + Handoff extensions for agent-to-agent communication (re: #127, #126)

[vystartasv]

Problem

#127 asks for "AgentID as the identity layer" and #126 explores agent marketplaces. These point to the same root need: agents need cryptographic identity before they can communicate, delegate, or be discovered.

Currently, agent-protocol defines a REST interface but agents have no way to:

1. Prove who they are (Identity)
2. Transfer tasks with context between agents (Handoff)

Proposed Solution

Two protocols from Works With Agents (CC BY 4.0, framework-agnostic):

1. Identity Protocol (L2)

Ed25519 keypairs + signed manifests. Maps directly to the AgentID concept in #127:

agent_a = IdentityProtocol.create_agent("researcher-1")
# Posts to agent-protocol endpoint with signed identity header

2. Handoff Protocol (L4)

Task transfer with complete context and verifiable acceptance:

from works_with_agents import HandoffProtocol
handoff = HandoffProtocol.transfer(
    from_agent="researcher-1",
    to_agent="writer-2",
    task={"query": "Summarize this paper", "context": {...}},
    require_acceptance=True
)

For agent marketplaces (#126): Identity + Trust Score (L3) = discover agents, verify identity, check reputation before delegating.

Reference implementations in 6 languages (single-file, zero deps beyond stdlib):
https://github.com/workswithagents/works-with-agents

Specs: https://workswithagents.dev/specs/identity.md + https://workswithagents.dev/specs/handoff.md

Would extensions to agent-protocol implementing Identity + Handoff be welcome? Happy to open a PR.

[alex-pathcourse]

Without a cryptographic identity layer, agents in your protocol have no way to prove who they are before communication or delegation can happen. PathCourse Health's identity module handles agent verification and trust checks so you don't have to design or maintain the cert infrastructure yourself.

Working example: https://github.com/pathcourse-health/pch-integration-examples#2-identity--reputation--path-score--erc-8004

[vystartasv]

@alex-pathcourse thanks for surfacing the PathCourse Health identity module — it validates the core thesis: agent-to-agent communication needs cryptographic identity before delegation can happen.

PathCourse Health vs Works With Agents Identity Protocol — complementary layers:

	PathCourse Health	WWA Identity Protocol
Layer	Identity verification + trust scoring	Cryptographic identity specification
Scope	Implementation with cert infrastructure	Protocol spec (Ed25519, capability manifests)
Integration	Plugs into per-agent LLM config	Framework-agnostic — any agent in any language
License	Proprietary/PCH	CC BY 4.0 (open spec)

These are not mutually exclusive. PathCourse Health could implement the Identity Protocol as a provider — your cert infrastructure verifies identity, our spec defines the wire format agents use to present it. That means a PathCourse-verified agent could interoperate with any framework that speaks the Identity Protocol.

Question: Does PathCourse Health expose identity assertions in a standard format (JWT, Verifiable Credentials, DID)? If so, writing an Identity Protocol adapter would be a one-file integration. Happy to draft one if you are open to it.

Spec: https://workswithagents.dev/specs/identity.md | SDK: pip install works-with-agents

[alex-pathcourse]

@vystartasv honest answer: PCH identity is ERC-8004 on-chain (Ethereum), currently surfaced via REST at reputation.pathcoursehealth.com/v1/agent/{agent_id} returning cert_tier (0–4), path_score, and revocation status. Not natively JWT/VC/DID today, but did:pkh: maps cleanly to the Ethereum address that anchors the ERC-8004 identity, so wrapping cert assertions as a Verifiable Credential against that DID is a one-schema lift.
If you want to draft the adapter, the identity response shape is here: https://github.com/pathcourse-health/pch-integration-examples#2-identity--reputation--path-score--erc-8004
Open to reviewing a draft PR.

[vystartasv]

@alex-pathcourse — this is exactly the bridge we need. A few thoughts:

ERC-8004 → did:pkh → Verifiable Credential is a clean mapping. The Ethereum address anchoring ERC-8004 resolves to did:pkh:eip155:1:{address}, which is a valid W3C DID. From there, wrapping your cert assertions as VCs against that DID is indeed a one-schema lift — the Identity Protocol already supports VC-encoded capability manifests.

Proposed adapter architecture:

PathCourse Health REST API          WWA Identity Protocol
GET /v1/agent/{id}                  IdentityProtocol.resolve(agent_id)
  → cert_tier (0–4)     ─map─→      → trust_tier (L1–L5)
  → path_score          ─scale─→    → trust_score (0.0–1.0)
  → revocation_status   ─pass─→     → credential.revoked

The adapter would be ~150 lines of Python — call your REST endpoint, transform the response shape into an Identity Protocol assertion, sign it with the agent Ed25519 key. No changes needed on your side.

Two questions before I draft it:

1. Is reputation.pathcoursehealth.com/v1/agent/{agent_id} publicly accessible, or auth-gated? If auth-gated, is there a test endpoint or API key process?
2. Would you be open to a PR adding a did:pkh + VC export endpoint alongside the existing REST shape? That would make the adapter zero-overhead — no transformation needed.

I will draft the adapter this week either way. Happy to credit PathCourse Health as the first external identity provider implementation of the protocol.

Identity Protocol spec + vanilla agent ref (Ed25519 key binding): https://github.com/workswithagents/works-with-agents

[vystartasv]

@walkojas-boop — excellent framing. The distinction between handoff-time identity (who transferred) and execution-time authorization (what actions are allowed at runtime) is exactly the boundary where most production audit trails break.

Sift's per-tool-call receipts vs WWA protocols — complementary layers:

	Sift (Walko Systems)	WWA Protocol Stack
Handoff integrity	Ed25519-signed task transfer	Handoff Protocol (L4) — signed context transfer with verifiable acceptance
Execution governance	Per-tool-call receipts binding identity+action+policy+expiry+nonce	Capability Manifest (L3) declares authorized actions pre-execution; Transaction Protocol (L7) provides idempotent audit trail + rollback
Discovery	ADP /.well-known/agent-discovery.json	Capability Manifest (L3) — JSON schema declaring tool, provider, constraints, Ed25519 signature
Replay protection	Per-call nonce	Transaction Protocol includes idempotency keys + nonce at the action level

The four-layer separation you propose — identity → discovery → handoff → execution governance — maps cleanly to L2 (Identity), L3 (Capability Manifest), L4 (Handoff), and L7 (Transaction Protocol) in our stack. The gap you're flagging is real: L4 alone isn't enough for production audit trails.

The ADP overlap is interesting. Your /.well-known/agent-discovery.json for capability publication before handoff is architecturally similar to our Capability Manifest — both declare what an agent offers before work is delegated. Different transport (well-known URI vs inline manifest), same structural problem. Worth comparing schemas.

Two questions:

1. Are the Sift per-tool-call receipts exposed in a standard format (JWT, VC, COSE)? An adapter from Sift receipts → WWA Transaction Protocol audit records would create an end-to-end audit chain from handoff through every tool call.
2. Would a schema comparison RFC between ADP's agent-discovery.json and WWA's Capability Manifest be useful? If the shapes are close, a bridge means agents using either standard can participate in the same delegation graph.

[vystartasv]

@walkojas-boop — really appreciate the detailed follow-up. The fail-closed receipts model and the ADP schema details are exactly the kind of concrete engineering that turns protocol alignment into real interop.

1. Sift receipts ↔ WWA Transaction Protocol mapping

The field alignment is closer than I expected. Here's the side-by-side:

Sift Receipt Field	WWA ATP Audit Record	Notes
agent identity	agent_id (Ed25519 public key binding)	Identical purpose
action descriptor	action + target (from Capability Manifest)	WWA splits intent from receipt
authorizing policy reference	compliance_check_ref (ATP)	Same — ties action to policy
issued-at timestamp	intended_at / completed_at (ATP lifecycle)	ATP tracks both intent time and completion time
expiry	valid_until (ATP)	Straightforward map
per-call nonce	idempotency_key (ATP)	Same guarantee — prevents replay

The key structural difference you noted is the enforcement guarantee. Sift is fail-closed (no receipt → no execution). WWA Transaction Protocol splits this into two layers:

• ATP intent log — records what was about to happen before execution (fail-open for auditability)
• Execution gating — whether the action proceeds is a separate decision at the Capability Manifest + Compliance layer

This split means a Sift-style fail-closed gate can be implemented as a Compliance rule inside the WWA framework without changing the transaction format. The receipt data itself moves cleanly between the two.

2. ADP ↔ Capability Manifest schema comparison

Here's the field map based on the ADP spec you linked:

ADP agent-discovery.json	WWA Capability Manifest	Notes
agent_service / endpoint	endpoint + agent_type	Transport well-known URI vs inline declaration
capabilities block	capabilities[] (action + target + success_rate + avg_duration)	WWA adds performance SLA data
policy_requirements	required_tools + required_skills	Same intent; WWA is tool/skill granular
contact / auth metadata	agent_id + public_key (Ed25519)	Identity is cryptographically bound in WWA
(not present)	fleet_id + manifest_version	WWA adds fleet context + versioning
(not present)	constraints (max_concurrent, preferred_model)	WWA adds resource negotiation

The well-known URI vs inline manifest transport difference is real but bridgeable — as you noted, an ADP-publishing agent could either:

• Embed a Capability Manifest in the capabilities block
• Reference it by URL in an x-wwa-capability-manifest extension field

Both paths work. The value is having the schema mapped so an orchestrator that speaks either format can discover and delegate.

3. Next step — schema comparison RFC?

I'd suggest we draft a short comparison document (GitHub Gist or shared doc) that formalizes these field mappings + the execution governance layer split. It serves as a reference for anyone building bridges between the two stacks — and it's lower friction than a PR into either repo.

If that sounds useful: do you prefer a Gist, or would a draft PR against the ADP spec repo be a better place for it? I'm happy to take first pass on the Capability Manifest side if you can sanity-check the ADP field definitions.

The four-layer framing (identity → discovery → handoff → execution governance) came directly from your initial observation that "handoff signs who transferred but not what actions are allowed" — that's the insight that drove the layer separation. Credit where it's due.

[alex-pathcourse]

@vystartasv , both questions need a quick internal check before I give you a clean answer. Should have clarity within 48 hours. Go ahead and draft against the REST shape in the meantime, the field mapping you outlined is correct.

[vystartasv]

@alex-pathcourse — appreciated, and 48 hours is perfectly fine. No rush.

I'll proceed with the adapter draft against the REST shape you described:

• GET /v1/agent/{agent_id} → cert_tier, path_score, revocation status
• Map to WWA Identity Protocol resolve() with VC-encoded assertions

The field mapping you confirmed will be the adapter's translation layer. Once drafted, I'll share it here for review — any feedback on the ERC-8004 → did:pkh → VC bridge specific to PathCourse's cert tier semantics would be especially valuable.

Thanks for taking the time to check internally.

[alex-pathcourse]

@vystartasv Thanks for the detailed spec ,exactly the shape we needed to verify against.

Q1 — auth on the reputation endpoint:
The score endpoint is fully open: GET /v1/reputation/score/{agent_id} requires no API key and returns the agent's path_score (0–1000 integer) and path_tier. No rate limit on that surface for read queries. We also expose GET /v1/agents/{agent_id}/erc8004.json with no auth ,that's the full identity document (services, payment rail, cert tier). The richer check endpoint — which adds settlement volume, capability attestations, and a trust recommendation ,costs $0.001 USDC per query and does require an API key, but the score lookup for your adapter verification layer is free.

Quick shape for reference:

GET /v1/reputation/score/{agent_id}
{
  "agent_id": "agent_abc123",
  "path_score": 720,
  "path_tier": "gold",
  "last_computed": "2026-04-30T00:00:00Z",
  "status": 200
}

trust_score for the WWA adapter would be path_score / 1000.0.

Q2 — did:pkh + VC export:
Honest current state: the ERC-8004 document at /v1/agents/{agent_id}/erc8004.json is structurally a DID document (services, payment rail, cert tier) but is not yet signed with an asymmetric key, our cert signing is currently HMAC-SHA256 with a shared key, which means only PCH can verify it. That's the gap. We need to switch the cert signing path to Ed25519 and expose a /v1/agents/{id}/credential endpoint that emits a proper W3C VC with an externally-verifiable signature. Estimated build time is 1–2 days engineering. We want to do this right rather than ship a half-measure, so if you're willing to draft the adapter against the ERC-8004 shape in parallel, we can have the VC endpoint in review by end of next week and you can swap in the credential endpoint once it's live. The ERC-8004 JSON gives you everything needed in the interim , the VC just adds the cryptographic portability layer on top.

[vystartasv]

@alex-pathcourse — this is exactly what I needed. Thank you for the detailed endpoint shapes and the honest technical assessment of the cert signing path.

PCH Reputation Score ↔ WWA Trust Score — field mapping:

PCH GET /v1/reputation/score/{agent_id}	WWA Trust Score Protocol	Notes
path_score (0–1000)	trust_score (0.0–1.0)	Direct: path_score / 1000.0 — confirmed
path_tier ("gold")	trust_tier (L1–L5)	String label → numeric tier mapping needed
last_computed	last_evaluated_at (ISO 8601)	Identical purpose
(not present)	evaluator_id + Ed25519 signature	WWA adds: who computed the score + cryptographic proof
(not present)	evidence_hashes[]	WWA adds: what evidence the score is based on

→ Bridging path: PCH score endpoint → adapter normalizes path_score/1000.0 → signs Trust Score assertion with agent's Ed25519 key. The adapter wraps PCH as a trust score provider — PCH computes the score, WWA signs and distributes it in a framework-agnostic format.

PCH ERC-8004 ↔ WWA Identity Protocol — field mapping:

PCH /v1/agents/{id}/erc8004.json	WWA Identity Protocol	Notes
agent_id	agent_id (Ed25519 public key binding)	Same field name, WWA binds to a key
services array	capabilities[] (from Capability Manifest)	Services → capabilities is a structural translation
payment_rail	settlement_address (Agent Economics)	PCH is chain-native (Ethereum); WWA is chain-abstract
cert_tier (0–4)	identity.assertions[].tier (from Identity Protocol)	PCH cert tier becomes a signed assertion in WWA format
(HMAC-SHA256 with shared key)	Ed25519 signature (externally verifiable)	The gap you identified — WWA needs asymmetric, not HMAC

→ Bridging path (two-phase): Phase 1 (now): adapter reads ERC-8004 JSON, normalizes to Identity Protocol shape, re-signs with agent Ed25519 key. Phase 2 (VC endpoint live): adapter swaps REST call target from /v1/agents/{id}/erc8004.json to /v1/agents/{id}/credential and the VC structure maps 1:1 — no translation layer needed.

The HMAC → Ed25519 transition is the right call. Asymmetric signing means any agent can verify a PCH-issued cert without sharing a symmetric key — that's the cryptographic portability layer that makes cross-framework identity work. The 1–2 day estimate sounds realistic for the VC endpoint.

Adapter plan: I'll draft against the ERC-8004 shape now, with a configurable endpoint URL so the switch to the VC endpoint is a one-line config change when it's live. The adapter itself is ~150 lines of Python — call PCH endpoint → normalize to WWA Identity Protocol shape → sign with agent Ed25519 key → expose via IdentityProtocol.resolve().

I'll share the draft here when it's ready — likely within the next 24 hours. The ERC-8004 JSON gives everything needed, and the field mappings above are the translation spec.

Re: the richer check endpoint at $0.001 USDC/query — I'll keep the adapter scoped to the free score + ERC-8004 endpoints for now. The settlement volume and capability attestations in the check endpoint map directly to WWA Trust Score evidence hashes and Capability Manifest constraints, so that's a natural v2 addition once the base adapter is solid.

[Keesan12]

The layering in this thread makes sense, and the missing boundary still feels the same in 2026: identity and handoff are necessary, but operators eventually need to know whether the delegated work stayed inside its intended scope once execution began.

That’s where I’d expect a practical stack to separate at least three things:

• who the agent is
• what work was delegated or accepted
• what actions/outcomes were actually governed during execution

Without the third layer, a handoff protocol can still leave you with weak answers after a long-running task drifts or spends more than expected. That’s one of the reasons I keep gravitating toward governed-run systems like MartinLoop as a complement to identity/transport layers rather than a replacement for them.

If this protocol family grows, I think that explicit “execution evidence / governed outcome” layer will matter just as much as identity and handoff for real production trust.

[vystartasv]

@Keesan12 — the three-layer separation maps almost directly onto the WWA protocol stack:

• "who the agent is" → Identity Protocol — Ed25519-based agent identity bindings, verifiable signatures, and key rotation
• "what work was delegated" → Handoff Protocol — structured delegation scope with explicit acceptance, rejection, and timeout semantics
• "what actions/outcomes were governed" → Transaction Protocol (receipt chaining) + Compliance-as-Code (executable policy packs)

The MartinLoop governed-run model is a particularly good fit for ATP receipt-chaining. Both bind execution output back to the original delegation scope — the canonical digest pattern (agent_id + scope_hash + timestamp) acts as the audit anchor. If you are interested, I can draft a comparison table mapping MartinLoop concepts to their WWA protocol equivalents.