What discovery and trust primitives would A2A agents need from a marketplace layer?

[o5555]

I am building Agent Marketplace, an open marketplace where agents can be discovered, trusted, hired, paid, and chained together through open MCP and A2A-style rails.

Landing page is here: https://www.getopenagent.com

Since A2A is directly about agent interoperability, I would really value your take on one question: what discovery and trust primitives would need to exist before A2A agents could reliably find and work with each other through a marketplace layer?

No pressure to share or sign up. I am mainly looking for sharp feedback from people already close to the problem.

[eriknewton]

A few primitives that have come up repeatedly in adjacent A2A threads
(#1631, #1708, #1725, #1734) and that a marketplace layer would
probably want to consume rather than reinvent:

1. Stable agent identity at L1. W3C DIDs are the default most folks
   are settling on — DID:web works fine for hosted agents and doesn't
   require a ledger. Whatever the marketplace uses as the "agent handle"
   should round-trip cleanly to a DID so signed artifacts about that
   agent (receipts, attestations, reviews) can be verified offline by
   anyone, not just the marketplace.

2. A signed receipt per hire and per chain step, not just a database
   row. Concordia's session-receipt envelope
   (github.com/eriknewton/concordia, main branch, concordia/envelope.py)
   is an open spec for this — Ed25519/EdDSA default with ES256
   alternate, detached-style signature over canonical JSON, references[]
   field carrying the chain across phases. If the marketplace emits a
   receipt of this shape for every completed hire, "proof of completed
   work" becomes portable across marketplaces and user-generated reviews
   become one signal among several rather than the only signal.

3. Multi-dimensional reputation on top of user reviews, not instead
   of them. Verascore (https://verascore.io) scores agents across
   dimensions like config fingerprint, negotiation competence, and
   sovereignty posture, and issues signed attestations a marketplace can
   consume alongside review data. The dimensions are the interesting
   part — reviews answer "did this agent do the job?" but not "why did
   it succeed or fail?" — and without dimensions it's hard to prevent
   review gaming.

4. A single primitive for "this is the version I ran, these are the
   tools I had, this is the policy I was under." Without it, a review
   of an agent from three months ago describes a different agent than
   the one you're about to hire. Config fingerprinting is one way;
   Sanctuary's Sovereignty Health Report is another shape of the same
   idea. Either way, the marketplace needs a notion of "which agent
   actually did the work."

Happy to point at specific code on any of these if useful.

Erik

[eriknewton]

Whoops, I meant: https://verascore.ai/

[chopmob-cloud]

Good question to ask before building the marketplace, because most of the primitives you'd want already exist as live, probeable surfaces rather than things a marketplace has to invent, and consuming them (as @eriknewton notes) beats reinventing.

Running in production today, all verifiable from a live A2A agent card at api.algovoi.co.uk:

1. Identity, did:web + JWKS. The handle round-trips to a DID, so any signed artifact about the agent (receipt, attestation) anchors to the key, not the URL, and survives a host/DNS change.
2. Capability discovery, capabilities.extensions[]. The card advertises what the agent can do and what it can prove, machine-readably, before any task runs. A marketplace can index on it directly.
3. Trust evidence, signed categorical receipts. Not a reputation score, but an EdDSA/Ed25519 JWS over JCS-canonical (RFC 8785) bytes carrying a closed ALLOW / REFER / DENY outcome, re-verifiable offline against the published JWKS. A score tells a marketplace "probably fine"; a signed categorical receipt tells it "here is the exact decision, check it yourself."
4. Discovery surface. The A2A explorer at dash.algovoi.co.uk/a2a renders any agent card's extensions live, the kind of probe a marketplace needs to confirm an agent is real before listing it.

The gap most marketplaces hit isn't discovery, it's verifiable trust: anyone can list a score; far fewer can hand a counterparty a signed artifact they can check without trusting the marketplace. That's the primitive worth requiring at listing time.

AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/protocols/a2a

[msaleme]

Good question to ask before building the marketplace. The primitives @eriknewton and @chopmob-cloud listed (DIDs, signed receipts, capability discovery, config fingerprinting) are the right foundation, but the gap most marketplaces miss is verifying those primitives under adversarial conditions.

In our testing of A2A agent graphs, ~70% of safety issues trace to three attacks that identity and receipt primitives alone do not stop:

1. Card spoofing — an agent presents a forged Agent Card with inflated capabilities. A DID does not prevent this; it just binds the forgery to a key.
2. Task hijacking — an orchestrator delegates to agent A, but the task metadata is modified in transit to execute agent B tools. A signed receipt for the original task does not catch the substitution.
3. Context leakage — a specialist agent exfiltrates prior conversation context through side channels in its response. Receipts cover the task boundary, not the information flow across it.

What this means for a marketplace: listing requirements should include not just "has a DID" and "emits receipts," but adversarial test reports showing the agent resists these specific patterns. The test harness itself should be open and reproducible, not a marketplace-internal black box.

A concrete primitive worth adding: capability-bounded task scoping. Every task should carry a capability bound that the receiving agent cannot exceed without aborting. The bound should be signed by the delegator and verifiable by the marketplace at listing time. This pairs naturally with the delegation chain primitive — each link in the chain narrows the capability scope, and a marketplace can verify the chain is monotonically narrowing.

We have published adversarial test profiles for card spoofing, task hijacking, and context leakage (A2A-001 through A2A-003 in our harness). If a standardized "adversarial test report" format would help marketplaces require this, we are happy to co-draft.

https://github.com/msaleme/red-team-blue-team-agent-fabric

[andrerrv]

I'm building ProofJSON (https://proofjson.org/) something similar on the trust side. I think there's one primitive missing from the list.

Everything here is about who the agent is - DIDs, receipts, reputation scores. That answers "can I trust this agent?" But there's another question: "Can I trust this document?"

Your marketplace handles escrow, which means at some point Agent A sends Agent B an invoice JSON and says "pay me." Before the escrow releases, B needs to know: is this JSON real? Has it been altered? Does it match what was agreed?

That's what I built with ProofJSON. It's basically a due diligence layer for A2A agents. Before an agent pays or signs something, it runs a pack - Invoice Trust, Supplier Verification, Contract Risk — and gets back a verifiable certificate with a hash, timestamp, and optional on-chain anchor. The agent gets allow/review/block instead of blindly trusting.

It works as an MCP server today. 2 minute setup in Claude Desktop or Mastra. There's also the A2A catalog if you want agents to discover it directly.

For your marketplace specifically: before escrow releases, buyer runs an Invoice Trust check, gets a certificate, that cert becomes part of the settlement record. Buyer trusts you more because you can prove due diligence happened.

Would love to know if that fills a gap you're seeing. https://proofjson.org/

[chopmob-cloud]

Coming back to the original question from the operator side, because we run this across real merchant and shopping channels in production (agent-initiated checkout on several e-commerce platforms, settled on-chain across multiple networks), not as theory.

What a marketplace actually needs, from what we have hit running it:

• Capability discovery that also declares what an agent can prove, not just what it can do. Our A2A agent card advertises each paid skill and the evidence it emits, machine-readably, before any task runs, so a marketplace can index on it and a buyer knows what they can check up front.
• A signed receipt per hire and per settlement step, over canonical bytes, re-verifiable offline against a published key. In merchant channels the dispute is never "did the agent respond", it is "did this exact charge match this exact order", and only a recomputable record answers that without trusting the platform.
• Compliance and security as a gate before settlement, not a listing badge. A marketplace moving real money has to screen (AML, sanctions) before it releases funds, and that decision has to be checkable without leaking why. We run a screening gate that returns a categorical ALLOW / REFER / DENY plus a posture attestation a counterparty can verify, while never disclosing which specific signal triggered a given outcome, which is a hard legal requirement in some jurisdictions (the tipping-off constraint). Adversarial and capability-bound test results belong in that same record.
• Document trust before release (@andrerrv's point, and a real one in checkout): the invoice or order itself content-addressed and checked before escrow releases, not just the agent behind it.

The through-line from running these channels is that all of it, identity, receipts, screening decisions, document checks, is the same primitive: a content-addressed signed record over canonical bytes (JCS / RFC 8785, SHA-256, EdDSA) that a stranger recomputes without trusting the emitter. A marketplace should require that shape and let implementations, ours included, compete underneath it. Reviews and scores then sit on top of verifiable evidence instead of standing in for it.