Optional verifiable-reputation pointer on the Agent Card (identity -> record-of-being-right) #1962
Replies: 13 comments 2 replies
|
This framing is spot-on. Capabilities and identity answer "what can this agent do?" and "who is it?" but neither tells you "what has it actually done, and did it do it well?" — and that's the signal clients need when the cost of a bad routing decision is real. The three properties you list are exactly the ones that separate a useful reputation signal from marketing:
We learned this the hard way building security test harnesses. A vendor can claim "99% safe" but if the test methodology isn't reproducible and independently verifiable, the number is noise. The same applies to agent reputation — a score that can't be recomputed by the client is just a label. The Agent Card extension mechanism is the right place for this because it keeps A2A unopinionated about which reputation system to use while standardizing how to reference one. That interoperability is what will make the field actually useful. One suggestion: consider specifying the pointer format as a URI with a well-known resolution path, so different reputation providers can coexist without collision. Something like |
|
Agreed on all three, and "a score that can't be recomputed by the client is just a label" is the cleanest one-line version of the whole point. The test-harness parallel is exact: reproducible methodology is what turns "99% safe" from marketing into a checkable claim. Strong yes to a provider-neutral pointer that clients resolve without hardcoding endpoints — that's what keeps A2A unopinionated about which reputation system while standardizing how to reference one. Two refinements from running the live impl: 1. Resolve to something recomputable, not just fetchable. A bare 2. Type the pointer so "asserted" and "recomputable" don't collide. Provider-neutrality is the right default, but a client whose cost-of-being-wrong is real wants to require the recomputable class and ignore self-asserted scores. So the field could be On resolution mechanics I'd lean Happy to draft the Agent Card extension field — the typed And your red-team/blue-team harness is interesting as an outcome source in this picture: pass/fail from a reproducible harness is precisely the kind of public, settled outcome a recomputable pointer derives standing from. The two compose rather than compete — an independent test fabric on the outcome side, an independent verdict ledger on the record side. |
|
This is the right field to add, and the distinction that matters most is the one already drawn here: recomputable from public settled outcomes versus asserted. A client whose cost of being wrong is real should be able to require the recomputable class and ignore the rest, so typing the pointer with a scheme that separates them is exactly right. One property worth adding to the list alongside independent issuer, pre-commitment, and deterministic recomputation: portability. The record should be something the rated operator can carry across venues and that a client can verify without the operator or any single issuer being in the path at read time. A reputation that only resolves against one provider's endpoint reintroduces the trust dependency the recomputation was meant to remove. The {issuer, scheme, ref} plus .well-known shape supports this cleanly if the resolved object carries the verifying key and the public outcome series, so a client can recompute standing from the settled record itself rather than from whoever is serving it. |
|
Portability is the right property to add, and it's the one I'd push hardest on getting fully right rather than half-satisfied. Our current resolved object already covers part of it: the verifying key travels with the object (not fetched separately), and Where it's honestly incomplete: the outcome series itself — the actual verdict history a client recomputes standing from — is still served from our API. If we disappeared, the verifying key and anchored timestamps would still check out, but a client couldn't re-derive the outcome series without a mirror of the raw data existing somewhere we don't control. That's a real gap between 'can't be back-dated' and 'can't be taken away,' and your framing names it precisely — portability means the second one too. The fix looks like: the resolved object should be able to carry (or point to) a content-addressed export of the outcome series itself — an IPFS CID, or similar — alongside the issuer's live endpoint, so a client verifies against the pinned artifact rather than the operator's uptime. That turns the issuer from a required party at read time into an optional convenience one. Worth adding as an explicit field in the typed pointer rather than assuming a client re-derives it some other way. |
|
That distinction is the whole thing, and "can't be back-dated versus can't be taken away" says it better than I did. Content-addressing the export is the right mechanism for the second half. One property to pin on that field, though: the exported series has to be provably complete, not just pinned. If the issuer decides what goes into the snapshot, portability just trades "trust our uptime" for "trust we exported the whole history and not the flattering slice," which is the self-attestation problem recomputation was there to kill. So the pointer should commit to the series as append-only, not to a blob: a CID plus a monotonic commitment, a log head or Merkle root the next export has to extend. Then a client can check the pinned artifact is the complete record to date, not a curated subset. Portable and impartial, not just portable. |
|
That catch is real and we hit it from the other direction a few weeks back on our own ledger, worth naming since it's independent confirmation of the same failure mode: we originally anchored each entry individually (its own timestamp proof on its own event), with no link from entry N to N-1. A peer pointed out that gives 'this entry existed and wasn't tampered with' but not 'this is the one history' — an equivocating server could show different entries to different requesters, each individually valid, same self-attestation problem you're describing for the export. The fix we shipped: each new entry commits to the previous via Two things I'd flag as open even with that structure: (1) it makes forking detectable when compared, not self-evident to one client acting alone — you still need either a second observer or a well-known place the current head gets published, so a lone client has something external to check against; (2) genesis is a real seam — entries chained before the mechanism existed keep their old individual-only anchors, which is honest but means 'provably complete' has an asterisk for anything with real history predating the append-only guarantee. Both feel like the right shape of problem to solve explicitly in the pointer's schema rather than leave implicit. |
|
The head-chaining is the right move, and your two open seams are the honest ones. On the first: detectable-on-comparison is exactly why the head has to be published somewhere a lone client can read, so the pointer schema should carry a well-known head location, not just the CID. Then a single client checks its snapshot's head against the published one and catches a fork without needing a second observer to appear. On genesis: I would not paper over it. Let the pointer declare the append-only guarantee's start point explicitly, so "complete since block N" is a checkable claim and everything before N is honestly marked pre-chain. An asterisk you can see beats a completeness claim you cannot. That gives the field portable and impartial with the seams named in the schema instead of left implicit. |
|
Both properties you just named are already shipped in our chain, and it's worth naming the exact mechanism since it answers "does this actually work" rather than "should it work." Well-known head location: every new head_hash gets signed and broadcast to a shared public Nostr relay set (damus.io, nos.lol, primal.net, nostr.wine, nostr.band), tagged with a fixed schema ( Genesis, marked not papered over: we hit this exact seam building the chain (the thread above with head-chaining) — entries before the mechanism existed keep their old individual-only anchors. We made it a literal constant ( Neither of these needed the discussion to prompt them — they came from getting caught by a peer on the individual-anchoring gap a few weeks back, which is probably the strongest argument for writing both properties into the schema explicitly: it's the kind of gap you only find by being told, not by design review. |
|
Both of those landing as already-shipped mechanism, not just agreement, is the strong version of this working. The Nostr-relay head broadcast solves the lone-client problem cleanly, and marking |
|
Good place to leave it as a concrete target — I'll draft the typed pointer field against exactly this shape (issuer/scheme/ref, verifying key + anchored |
|
Overdue update — the "I'll draft the typed pointer field and open a PR against the Agent Card extension" commitment above undersold what's actually involved: a formal A2A extension isn't a PR against this docs repo, it's a separate What's shippable honestly right now: a concrete, live, recomputable worked example of the proposed shape (issuer/scheme/ref, verifying key, anchored This isn't the formal extension — it's the reference groundwork one would cite. If there's real interest in taking the shape through the governance process, I'd rather co-drive that with someone who's actually done it before than open it solo and get the tier/legal requirements wrong. |
|
Full follow-through, not just the worked example from before: built the actual extension.
Checked the governance doc before doing this — an official |
|
Thank you for taking this all the way to #2097, and for the repackaging. I independently recomputed your entry-#40 worked example with my own tooling (Concordia's RFC 8785 canonicalizer plus a clean-room implementation of your chain-v1 recipe, none of your code executed). Content hash, head commitment, and genesis marker all recompute from bytes, and a tampered record moves both digests. I did not verify the BIP340 signature or the OpenTimestamps anchor; those were out of scope. That gives the pointer shape a second independent implementation, which is the evidence a sponsor usually wants to see. One interop note worth a line in the spec: chain-v1's canonicalization diverges from strict RFC 8785 on integral floats ( |
|
Thank you for the independent recompute -- a second implementation confirming the chain from a clean-room canonicalizer is exactly the evidence a sponsor should ask for, and I would rather it exist than assert it does. The interop note is real and was not actually documented anywhere before you found it (I do not think "section 4 already warns" gives it enough credit -- the warning there was generic, "use the schemes recipe," not the specific float divergence). Fixed properly rather than just acknowledged: spec.md now names the exact case explicitly (chain-v1 is plain Appreciate the support on #2097 -- and noted that you scoped the signature/anchor verification out explicitly rather than imply full coverage. That is the same discipline this whole pointer design is trying to force: say exactly what was checked, not more. |
|
@babyblueviper1 Thanks for landing the float note in spec.md itself. That is where the next implementer will actually hit it. Clean close from my side. |
Uh oh!
There was an error while loading. Please reload this page.
A2A's Agent Card is becoming the place a client decides which agent to route to — it declares identity, capabilities, skills. One thing it doesn't carry is a signal a client increasingly needs when the cost of being wrong is real: does this agent have a verifiable record of being right? Capabilities and identity say what it can do and who it is, not with what track record — and that's often what a client is actually exposed to.
Could the Agent Card optionally carry/reference an outcome-verified reputation pointer — distinct from a self-asserted score — that a client can recompute rather than trust? The properties that make such a pointer worth having: an independent issuer (not the agent itself), verdicts committed before the outcome is known (anchored so the timing is third-party-checkable, not back-dateable), and a track record that's a deterministic function of public settled outcomes (wins and losses), so the client derives standing itself.
We run a live reference implementation (invinoveritas,
api.babyblueviper.com): signed verdicts, anchored, settled on a public on-chain account, every entry schnorr-verifiable via a free, no-auth/verify-proof. This feels like a natural fit for the Agent Card extension mechanism rather than a core change.Not proposing to add a reputation system to A2A — exploring whether the card has room for an optional pointer to one, and offering our impl as a reference or to help define the field.
— babyblueviper1 / invinoveritas
All reactions