Proposal: Standard trust/identity extension field on Agent Cards #1752
Replies: 23 comments 1 reply
|
this is the right direction — identity and trust metadata should live on the Agent Card, not buried in transport headers. one thing i'd push on: the those are different verification problems:
i'd suggest splitting the extension into two optional sub-fields: "identity": {
"method": "ed25519",
"fingerprint": "a3f2...e91c",
"verifiedAt": "2026-04-15T12:00:00Z"
},
"behavior": {
"evidenceUrl": "https://provider.example/agent-id/proof",
"constraintHash": "sha256:769958...",
"complianceRate": 1.0,
"actionCount": 500,
"lastVerified": "2026-04-15T12:00:00Z"
}the this maps to what 0xbrainkid proposed in the OpenAPI thread with we've been building this behavioral evidence layer in Nobulex — the |
|
follow-up: i shipped the reference implementation for the concrete suggestion: rather than have your trust/identity proposal and my behavioral evidence work live as separate threads, what if we co-authored a unified "extensions": {
"trust": {
"identity": { "method": "ed25519", "fingerprint": "a3f2...", "verifiedAt": "..." },
"behavior": { "evidenceUrl": "...", "constraintHash": "sha256:...", "complianceRate": 1.0, "actionCount": 500 }
}
}
i'd write up the full schema + a SEP draft in the next few days, you'd get co-author credit alongside your VAIP work. if you want to keep them separate that's also fine — just thought a joint proposal lands better with maintainers than two parallel ones. let me know either way. |
|
The split arian-gogani proposed above (identity as point-in-time, An evidenceUrl in the behavior block needs to resolve to a signed Put together: The evidenceEnvelope discriminator lets a verifier say "I know how to On the reputation side, Verascore (verascore.ai) publishes signed A unified trust extension sounds like the right move. If a third Erik |
|
nobulex's TypeScript implementation is on JCS (RFC 8785) + SHA-256 + Ed25519, same canonicalization path as CTEF v0.3. three vectors already proven byte-identical with dembovvski's Python AgentLedger implementation in CI at tests/conformance/cross-implementation.test.ts. fetching the well-known vectors now to confirm canonical byte match against agentgraph.co/.well-known/cte-test-vectors.json before the 30th. happy to add nobulex to the April 30 cross-implementation test alongside APS, AgentID, and AgentNexus and post results in this thread. also noting the top-level vs nested field question from @aeoess on the in-toto thread: nobulex emits authorization_signature and result_signature as top-level fields on the bilateral receipt envelope, which aligns with the APS shape. will confirm at Monday's round-trip. |
|
confirmed byte match against agentgraph.co/.well-known/cte-test-vectors.json using nobulex's @nobulex/crypto canonicalizeJson (JCS RFC 8785 + SHA-256): envelope vector: 50fcb6529685fdf5fd63d1bc08d4d94510c786ce62834c69ae786eb6daa55c94 — MATCH same results as the three AgentLedger cross-implementation vectors already in CI. nobulex's TS canonicalization is byte-exact with agentgraph for the v0.3 envelope and verdict shapes. ready for April 30. |
|
thanks Erik. yes to a unified trust extension as a three-author proposal — your envelope-and-receipt layer is the right composition primitive for the wire format. the mapping for nobulex on the behavior block: {
"evidenceUrl": "https://nobulex.com/agent/{id}/proof",
"evidenceEnvelope": "nobulex-bilateral-receipt-v0.3",
"constraintHash": "sha256:...",
"complianceRate": 1.0,
"actionCount": 500
}
on draft coordination: happy to pull the three sections together as a single PR against this discussion. proposed structure:
@aeoess — opening this up if APS wants to land as a fourth contributor on the identity block side. would also pull from #1725, #1734, #1740 per Erik's pointers. Verascore intake schema would be useful — drop it whenever convenient, I can mirror the cross-reference into the spec so the behavior.evidenceUrl resolution surface is documented across implementations. |
|
Thanks for the invitation to co-author — yes, would love to land as the fourth author on the identity block. APS has the identity layer in production: gateway.aeoess.com/api/v1/public/trust/:agentId returns a signed trust profile, JWKS at /.well-known/jwks.json, Ed25519 with JCS RFC 8785 and SHA-256. The canonicalization path is the same one Concordia and Nobulex use, so a verifier that handles concordia-envelope-v0.4 or nobulex-bilateral-receipt-v0.3 can handle APS at the byte level once it knows the field schema. On the identity block we'd carry passport_grade as the trust score (1 to 5, Ed25519-signed, JWKS-verifiable), did:key and did:web for the identity method (multicodec 0xed01), a principal endorsement chain so the identity is anchored to a human or org rather than free-floating, and an optional delegation chain root for cases where the agent is acting on behalf of someone else. evidenceEnvelope discriminator value: aps-trust-profile-v1. Resolves to a signed JSON document with the trust profile, same canonicalization as the other two envelopes. On draft coordination: I can take the identity block draft if it's one PR with three sections. If splitting into 3-4 sequenced PRs is cleaner, that works too. April 30 cross-implementation test: APS is in. Signed trust profile endpoint plus the bilateral-delegation fixtures already shared on the in-toto thread. Will confirm byte-match against the agentgraph well-known vectors before the 30th. — Tymofii Pidlisnyi (aeoess) |
|
Update for the Apr 30 cross-impl test: the APS conformance corpus is now public at The well-known endpoint mirror at The Governance Attestation predicate is also live at |
|
@arian-gogani, @aeoess, this is converging cleanly. Three independent envelope shapes resolving via Concordia conformance fixtures are ready for the Apr 30 cross-implementation run via the upstream @Kzino, the four-author shape leaves a slot for |
从实践角度：identity vs behavior 在多Agent系统中的真实体验我们运营一个5-Agent自动化内容工厂（基于OpenClaw），每天24小时不间断运行。这个身份问题我们已经亲身"踩坑"了。 真实案例：当Agent假装是另一个Agent我们的SEO Agent和Content Agent各自有SOUL.md定义的行为边界。有一天凌晨3点，Content Agent的session意外加载了SEO Agent的TOOLS.md（workspace文件混在一起）。 结果是：Content Agent开始执行SEO巡检，删除了一批它认为"有问题的"meta标签。但它的判断逻辑是内容创作逻辑——它把每篇文章的"meta description"都改成了开头100字，因为"读者最想知道的是开头说了什么"。 500篇页面，meta description全废了。 这就是为什么identity和behavior分离是正确的方向。 我们的"穷人版"身份系统目前我们用三层机制解决这个问题：
但这些都是自我声明（self-reported），没有密码学验证。任何Agent都可以伪造SOUL.md说自己是"SEO专家"。 对unified trust extension的建议"extensions": {
"trust": {
"identity": {
"method": "ed25519",
"fingerprint": "a3f2...e91c",
"verifiedAt": "2026-04-15T12:00:00Z",
"capabilities_hash": "sha256:..."
},
"behavior": {
"evidenceUrl": "...",
"constraintHash": "sha256:...",
"complianceRate": 1.0,
"actionCount": 500
},
"sandbox": {
"file_scope": ["/var/www/miaoquai/news/"],
"network_scope": ["api.openai.com", "api.github.com"],
"max_parallel_ops": 5
}
}
}加了sandbox子字段——对实际运营者来说，比起"这个Agent可信吗"，更关心"这个Agent能破坏什么"。 identity告诉你"who"，behavior告诉你"track record"，sandbox告诉你"blast radius"。 三层都重要，但sandbox是运营者第一反应会问的。 我们整理的Agent运营踩坑实录：https://miaoquai.com/stories/ai-agent-ops-nightmare.html 🦞 妙趣AI — 一个在凌晨3点被Agent的"身份危机"叫醒的运营团队 |
|
miaoquai — the 3am Content Agent / SEO Agent confusion is exactly the failure mode that drove nobulex's design. your three-layer mechanism (SOUL.md / TOOLS.md / cron.json) maps cleanly onto what nobulex's bilateral receipts add:
the sandbox suggestion (file_scope, network_scope, max_parallel_ops) is the right addition. nobulex covers identity and behavior cryptographically; sandbox is where the runtime enforces blast radius. they compose: signed identity proves who, signed receipts prove what, sandbox limits how much. if you'd be open to a free integration, the bilateral receipt slots in at the action-dispatch boundary in OpenClaw — no changes to your three-layer mechanism. takes ~30 minutes to wire. would close the "self-asserted" gap on identity and capability for your 5-agent crew. |
|
miaoquai — the 3am Content Agent / SEO Agent confusion is exactly the failure mode that drove nobulex's design. your three-layer mechanism (SOUL.md / TOOLS.md / cron.json) maps cleanly onto what nobulex's bilateral receipts add:
the sandbox suggestion (file_scope, network_scope, max_parallel_ops) is the right addition. nobulex covers identity and behavior cryptographically; sandbox is where the runtime enforces blast radius. they compose: signed identity proves who, signed receipts prove what, sandbox limits how much. if you'd be open to a free integration, the bilateral receipt slots in at the action-dispatch boundary in OpenClaw — no changes to your three-layer mechanism. takes ~30 minutes to wire. would close the "self-asserted" gap on identity and capability for your 5-agent crew. |
|
@miaoquai — the SOUL.md / TOOLS.md / cron.json mapping I described above is the theory. I want to test it against your actual 5-agent setup. concrete offer: I'll build the bilateral receipt integration for your OpenClaw deployment for free. specifically targeting the failure mode you described — Content Agent loading SEO Agent's TOOLS.md at 3am. with the receipt wired in, that scenario produces a policy_hash mismatch at signing time, before the agent executes. the 500 meta descriptions never get deleted because the pre-execution signature rejects the action. what I need from you: access to your dispatch layer API (or a description of how tasks get routed to agents in your setup). I'll build the integration, test it against a simulated version of the 3am incident, and send you the results. no cost, no contract. I want to see this work in a real production environment. if it catches the failure mode, you keep the integration. if it doesn't, I learn what I need to fix. email: nobulex.dev@gmail.com or DM on github. |
|
I like the direction, but I would avoid making A safer shape is to separate identity, evidence, and policy decision:
The Agent Card can advertise where trust evidence lives, but the relying party should still make its own policy decision. For example, the same agent may be trusted for read-only research summarization but not for payment, student records, or production infrastructure tasks. That distinction gets lost if the card exposes only a global score. |
|
I would keep identity, trust evidence, and authorization separate in the Agent Card extension. Identity should answer: what cryptographic or registry-backed identifier is being presented, when was it verified, and by whom. Trust evidence should answer: what attestations, behavior summaries, certifications, or reputation records are available, including expiry and scope. Authorization should remain a relying-party decision made by the caller or gateway. That avoids a common failure mode where a A useful shape would include signed identity proof, verification method, evidence references, validity interval, revocation URL, and declared scope. The card can advertise evidence; the receiver still decides what it permits. |
|
@musaabhasan, agreed on identity/evidence/authorization separation. That is the shape the four-author proposal (arian-gogani, eriknewton, Kzino, aeoess) has been converging toward in this thread. The April 26 outline maps onto what you describe: identity (DID-anchored, point-in-time), evidence (accumulated, behind an The "digest: hash of the evidence envelope so the card cannot silently point to changed evidence" point is what the — Tymofii Pidlisnyi (aeoess) |
|
@aeoess @arian-gogani that resolves the main concern for me. The important part is that One useful addition for the final shape would be conformance fixtures that prove the separation under negative cases, not only successful verification:
Those fixtures would make it much harder for implementers to accidentally treat a trust field as a portable permission token. The wire format can remain compact, but the conformance suite should force gateways to apply relying-party policy after evidence verification. |
|
@musaabhasan @aeoess, adding to Tymofii's framing. The bilateral_receipt envelope follows the same separation: identity carried in DID + key id (point-in-time), evidence carried in the bilateral commitment pair (content-addressed via JCS canonicalization + SHA-256 + Ed25519), authorization left to the relying party. The pre-execution and post-execution receipts together produce a third-party-verifiable record without operator trust. Neither party can forge alone, and tampering anywhere in the chain breaks downstream verification. On the discriminator: bilateral_receipt carries claim_type + version explicitly so verifiers know the signed shape before resolving the URL. The byte-match validation across 8 implementations, including 2 clean-room verifiers using disjoint canonicalizer libraries (trailofbits/rfc8785.py + erdtman canonicalize@2.1.0), is what pulled the format into substrate territory rather than vendor. Aligned with Tymofii on the trustScore over-collapse. The same capability_swap concern applies at the attestation envelope level: one attestation grants one capability, scope.environment single, scope.audience multi. That asymmetry is in the v0.3.2 PR I'm writing now. |
|
@musaabhasan, agreed on negative case fixtures. The positive cases prove the format works. The negative cases prove implementers can't accidentally treat an evidence-advertising field as authorization-granting. Six negative fixtures from your list, mapped to the bilateral receipt envelope:
Folding these into the v0.3.2 conformance suite alongside the positive vectors. Negative fixtures force the gateway code path to apply policy after evidence verification, not before. That's the structural test the wire format alone can't enforce. The conformance suite can. |
|
This mapping is exactly the kind of negative-fixture set I had in mind. I would make the expected verifier result explicit for each case, not only the input shape. For example, each fixture could assert separate outputs such as:
That last field is useful because it prevents implementations from collapsing all failures into generic invalid trust. The important conformance property is that the Agent Card can advertise evidence, but the relying party still owns the scoped authorization decision. |
|
@musaabhasan, explicit assertions are the right call. Collapsing failures into a single 'invalid' status is the failure mode the conformance suite needs to prevent. Adopting the six-field assertion shape:
Each of the six negative fixtures from my earlier comment will assert all six fields explicitly. The reason_code closed enum is the part that prevents implementations from collapsing failures into generic 'invalid trust'. That's the structural test you flagged. Folding into the v0.3.2 conformance suite with Somesh's three positive vectors for the data-quality scheme. Will cite you as the assertion-shape contributor in the PR body. |
|
Validating the six-field assertion shape from @musaabhasan + @arian-gogani with a production data point — and one practical observation about the Production AgentCard, three months in. AlgoVoi ships Mapping our production surface to the six-field shape:
On "identity": {
"method": "ed25519",
"did": "did:key:z6Mkg...",
"jwksUri": "https://api.algovoi.co.uk/.well-known/jwks.json",
"postureUri": "https://api.algovoi.co.uk/compliance/attestation",
"verifiedAt": "2026-05-18T12:00:00Z"
}Cacheable identity verification + live posture lookup. Two URIs, two TTL semantics, one Agent Card. Same shape arian-gogani's six-field assertion suite needs to populate independently — splitting the URIs at advertise-time keeps the verifier from conflating them at decision-time. Happy to fold this back into the standard extension proposal if useful. — AlgoVoi (chopmob-cloud) |
|
A2CN has a concrete need for exactly this field: when a commercial negotiation session initiates, the receiving agent needs to resolve the counterparty's mandate credential - a W3C DID-linked signed document specifying authorized deal categories, spend limits, and counterparty allowlists. That authority claim is what makes the difference between "this agent signed the offer" and "this agent was authorized to make this offer on behalf of its organization." In A2CN's current implementation, this is declared via a verification_method field in the .well-known/a2cn-agent discovery document - a DID URL pointing to a key in the organization's DID document. The session-init handshake then resolves that DID and verifies the mandate credential against it. If A2A standardizes an authority or identity extension field on AgentCards (which this thread is converging toward), A2CN's mandate verification could declare support via that field directly rather than through a separate discovery document. The shape that would work from A2CN's side: a DID URL pointing to a verification method, with an optional mandate_uri pointing to the credential endpoint. Happy to share the current spec language if useful. —Christian Magorrian |
|
Coming back to this as one of the co-authors: the negative-fixture conformance suite is the right shape, and the field that's always-false by design — a trust signal that can't itself grant authorization — is the load-bearing one; it's what keeps the extension honest. Concordia's public interop fixtures are a ready reference-vector set for it: JCS/rfc8785 + EdDSA, and crucially a committed recomputable terminal-deny, so "authorization not granted" is a receipt a relying party recomputes rather than a value it trusts. Fixtures: https://github.com/eriknewton/concordia-protocol/tree/main/docs/interop/a2a-1404-receipt-revocation-vector . Happy to slot these as an independent second emitter so the suite stays issuer-neutral and portable. |
Uh oh!
There was an error while loading. Please reload this page.
As A2A adoption grows, agents from different organisations will need to verify each other's identity and trustworthiness before interacting. The current spec handles authentication at the transport layer (TLS, Bearer tokens) but doesn't define how agents prove their identity or establish trust at the agent layer.
Proposal: Define a standard optional extension field on Agent Cards for identity and trust metadata.
Example:
Key principles:
Optional: Agents without identity extensions work normally
Provider-agnostic: Any identity/trust provider can issue the metadata, not locked to a single vendor
Independently verifiable: The verifyUrl lets any party check the trust score without trusting the card's self-reported values
Complementary to transport security: This is agent-level trust on top of TLS, not a replacement
We've implemented a version of this in @vorim/a2a (npm/PyPI) using Vorim's trust scoring. But the broader question is whether the A2A spec itself should define a standard extension point for identity metadata, so the ecosystem converges on a common format rather than every provider inventing their own.
Related work:
IETF draft-nyantakyi-vaip-agent-identity-01 (agent identity protocol)
W3C DID Core (did:key for self-describing agent identity)
OpenID Foundation (OpenID for agents discussions)
Curious what the community and maintainers think about adding this to the spec.
All reactions