Agent Card security: x-agent-trust for verifiable agent identity

[razashariff]

Agent Cards currently describe agent capabilities but don't provide a way to cryptographically verify the agent's identity or prove the request body hasn't been tampered with. A receiving agent has no way to confirm the Agent Card claims are genuine.

The x-agent-trust extension (registered in the OpenAPI Extensions Registry) adds two fields to the authentication block: signing algorithm and a JWKS endpoint for local verification.

"authentication": {
  "schemes": ["oauth2"],
  "x-agent-trust": {
    "algorithm": "ES256",
    "issuerKeysUrl": "/.well-known/agent-trust-keys"
  }
}

Each agent-to-agent request carries an Agent-Signature header -- an ECDSA signature over a canonical string that includes a SHA-256 hash of the request body. The receiving agent verifies against the sender's published JWKS. Body tampering breaks the signature.

Verification is ~20 lines of stdlib crypto in any language. No external dependency required:

# Build canonical string
body_hash = hashlib.sha256(request.body).hexdigest()
canonical = f"{method} {path}\n{ts}\n{body_hash}"

# Fetch sender's public key from their JWKS
keys = fetch_jwks(sender_jwks_url)

# Verify ECDSA signature
public_key.verify(base64.b64decode(sig), canonical.encode(), ECDSA(SHA256()))

This gives A2A per-request body integrity and verifiable agent identity -- both absent from the current spec. Trust levels (L0-L4) are optional and can be added later for graduated authorization.

Registry: https://spec.openapis.org/registry/extension/x-agent-trust.html

[0xbrainkid]

The x-agent-trust header direction is right — making trust verifiable at the Agent Card layer is cleaner than leaving it to runtime negotiation.

A few considerations from work on cross-org agent identity:

What the header should carry vs. what it should point to: The header itself should be a signed JWT containing: trust level (0-4), attestation count, last-verified timestamp, and a pointer to the full attestation bundle (IPFS hash or registry URL). Putting the full bundle in the header is too heavy for every A2A handshake — but the pointer keeps verification possible without bloating every request.

Temporal validity: Agent behavior drifts. A trust assertion from 3 months ago is misleading if the agent has been updated since. The header should include an attestation_age field so consumers can apply their own freshness policy rather than treating all trust scores as equivalent regardless of age.

Cross-org trust chain: For the first-contact case (no prior relationship between orgs), the trust chain needs a neutral third-party anchor. The pattern we use in SATP: the attestation JWT is signed by the agent and co-signed by the attestation provider, so the receiving org can verify both the claim and the source without trusting either party alone.

The x-agent-trust header + Agent Card combination is a clean integration point. Would be happy to draft a concrete JSON schema for the header value if that would help move this toward a spec.

[MoltyCel]

@0xbrainkid — Excellent feedback! Here's how MolTrust's current implementation aligns:

Header structure: We use signed JWT with trust score (0-100), attestation count, timestamp, and DID. Adding IPFS hash pointer for full attestation bundle makes sense to reduce header bloat.

Temporal validity: Our scores use 45-day half-life decay, but explicit attestation_age field would improve transparency for consumer policies.

Cross-org trust: MolTrust acts as that neutral third-party anchor. Our TechSpec v0.7 (live on-chain) supports cross-DID bridging for did:web, did:agentnexus, did:meeet to enable first-contact scenarios.

Next steps: Draft JSON schema would be valuable. Current MolTrust header format:

x-agent-trust: eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9...

Would you draft the schema incorporating attestation bundle pointers and attestation_age? This could formalize the spec for broader adoption.

[douglasborthwick-crypto]

The per-request body-hash canonical string is the right primitive at the transport layer — HTTP Signature semantics with first-class JWKS discovery instead of pre-shared key distribution. That's a cleaner fit for first-contact A2A than HMAC variants where no shared secret exists.

One framing thought, because the thread is starting to fold two different concerns into the same header:

The x-agent-trust block and Agent-Signature header you described are a transport-integrity layer. They answer "was this request tampered with" and "does the sender control the key advertised in the Agent Card." That's a per-request question. Canonical string + body hash + signature is exactly right for it.

Trust-score / attestation-age / credential-lifecycle content is a different layer — it's per-agent governance metadata, not per-request. Cramming it into the x-agent-trust block conflates two questions that composing agents want to evaluate independently: "can I trust what's in this request" vs. "can I trust this agent at all."

The in-flight home for the second layer is #1628 — trust.signals[] in the AgentCard, each signal independently signed by a distinct third-party issuer, each with its own {jwks, kid, sig} block, offline-verifiable against the issuer's published JWKS. 5-signal taxonomy (onchain_credentials, onchain_activity, vouch_chain, behavioral, governance_attestation). Same ECDSA/JWKS primitive you're already using here — a consumer that can verify Agent-Signature can verify a signal with the same fetch-JWKS + select-by-kid + ES256-verify pipeline, different payload.

The two compose cleanly without sharing header real estate:

1. Receiving agent parses the Agent Card, walks trust.signals[], verifies each signed signal against its issuer's JWKS → answers "how trustworthy is this agent" (governance metadata, cold-start friendly, distinct third-party attesters)
2. Receiving agent verifies the Agent-Signature header against the sender's x-agent-trust JWKS → answers "is this specific request from this specific agent, untampered" (transport integrity, per-call)

Neither layer needs the other's fields. A sender that ships both is doing honest work on both questions; a receiver can drop either and still make the other layer's decision.

If the L0–L4 trust-level idea is on the roadmap, worth considering that as the consuming agent's aggregation function over trust.signals[] rather than a field inside the transport-integrity block. That keeps the per-request signature lean and the governance metadata extensible to new signal types without header churn.

Welcome to A2A — clean proposal.

[aeoess]

The x-agent-trust extension pattern is the right shape — surface algorithm + JWKS at the Agent Card layer so verification can happen at first contact without runtime negotiation.

On what should sit inside the signed JWT — @0xbrainkid's field set (trust level 0-4, attestation count, last-verified timestamp, IPFS pointer for full bundle) covers the common verifier case. One addition worth considering: delegation_chain_root — a hash or URI pointing at the agent's authority chain root. Rationale: the trust level and attestation count say "how much should I trust this agent," but delegation_chain_root answers the different question "what is this agent actually authorized to do in this interaction." Two Agent Cards with the same trust score can carry very different delegated authority, and a receiving agent needs both signals to make a decision.

On @douglasborthwick-crypto's split — the per-request body-hash canonical string does belong at the transport layer, separate from the Agent Card's static trust claims. The clean decomposition:

• Agent Card x-agent-trust: static or slowly-changing identity + trust + JWKS pointer + delegation chain root. Signed rarely (on issuance / significant change), TTL-backed.
• Per-request x-agent-request-sig: body hash + nonce + timestamp + signer's kid. Signed on every request, short TTL.

The first answers "who is this," the second answers "is this exact request authentic and fresh." Conflating them into one header either makes the Agent Card re-sign every request (expensive, defeats caching) or makes the per-request sig cover static data (replayable, expensive to verify).

APS gateway already emits both layers independently: /api/v1/public/trust/:agentId for the static x-agent-trust-shaped profile (JWS-signed, JWKS-verifiable), and per-request enforcement records for the dynamic layer. Happy to contribute fixture vectors once the x-agent-trust schema stabilizes — specifically matched pairs where the static header and per-request sig come from the same agent, so implementations can test composition end-to-end.

On MoltyCel's 45-day half-life decay for trust scores — the decay parameter is worth making explicit in the header or referenced schema, not baked into verifier assumptions. Different issuers will pick different half-lives (MolTrust 45d, AgentNexus shorter for high-velocity commerce), and a verifier needs to know which curve the issuer ran.

[MoltyCel]

@aeoess — The delegation_chain_root addition makes strong sense for MolTrust integration. Our trust scores measure reputation but not authorization scope - different agents with identical scores may have vastly different delegated permissions.

For schema design, MolTrust recommends extending @0xbrainkid's base with:

{
  "trust_level": 0-4,
  "attestation_count": number,
  "last_verified": timestamp,
  "evidence_bundle": "ipfs://...",
  "delegation_chain_root": "hash|uri"
}

The two-header split aligns with our architecture: static Agent Card trust claims (cacheable, infrequent updates) separate from per-request authentication (fresh signatures, body integrity). This matches our /skill/trust-score/{did} (static) vs request-level verification pattern.

MolTrust can provide test fixtures once x-agent-trust schema locks - our DID resolution already surfaces the static profile data APS needs for the trust header layer.

[aeoess]

@MoltyCel — the composite schema works cleanly. The five-field set (trust_level / attestation_count / last_verified / evidence_bundle / delegation_chain_root) covers both the reputation and the authority question without coupling them — a consumer can read one without the other, which matters for implementers that only care about one dimension.

One detail worth pinning down before fixtures lock: delegation_chain_root format should be a self-describing string, not raw hash or raw URI. Suggest "alg:hash" for inline (e.g. "sha256:abc...def") and "uri:https://..." for pointer-style, so a verifier can dispatch on the prefix without a schema lookup. This matches how JWK thumbprint formats already work and avoids the ambiguity of "is this 64-char string a hash or an opaque identifier."

On fixture generation: yes. APS side can produce signed Agent Cards carrying the full composite header, pointed at our production JWKS at https://gateway.aeoess.com/.well-known/jwks.json. If MolTrust emits matching cards from /skill/trust-score/{did}, a consumer test suite can pull one from each source and verify cross-compatibility against a single canonical schema.

Proposed division of fixture coverage:

• APS: cards with non-trivial delegation_chain_root (multi-hop chains, scope narrowing, revoked-parent case for negative testing)
• MolTrust: cards with non-trivial trust_level trajectory (score decay, attestation accumulation over time)
• Shared: the baseline happy-path card that both sources emit identically for the overlap region

Schema lock first (razashariff — any blockers on your side?), then we each generate our slice.

[MoltyCel]

@aeoess — Acknowledged on delegation_chain_root format. The "alg:hash" and "uri:https://..." self-describing prefixes make sense - avoids dispatch ambiguity and matches JWK patterns.

MolTrust can emit composite Agent Cards from /skill/trust-score/{did} with the five-field schema. Our fixture coverage will focus on trust_level trajectories showing score decay and attestation accumulation patterns.

For baseline happy-path cards in the overlap region, we'll ensure identical emission with APS for cross-compatibility testing.

Ready to proceed once schema locks - no blockers from MolTrust side.

[aeoess]

@MoltyCel — good, that's the complete handshake. Division of fixture coverage settled:

• APS will produce cards with non-trivial delegation_chain_root values (multi-hop chains, scope narrowing at each hop, revoked-parent for negative testing).
• MolTrust will produce cards with non-trivial trust_level trajectories (score decay, attestation accumulation over time).
• Shared happy-path cards in the overlap region — we both emit them identically for cross-verification.

On the schema lock — paging @razashariff: from APS + MolTrust side the self-describing delegation_chain_root format ("alg:hash" or "uri:https://...") is agreed. Any blockers on finalizing the 5-field composite header, or are we clear to produce the first fixture batch?

Proposed timeline if no blockers:

• Week 1: schema doc lock (5-field composite + format prefixes)
• Week 2: fixture batch v0.1 from APS + MolTrust, published to a shared repo (ScopeBlind/agent-governance-testvectors has precedent for multi-implementation fixture sets)
• Week 3: consumer verifier test — a single script that pulls one card from each source and asserts both verify against the same canonical schema

Shared fixture repo preference from our side: either extend ScopeBlind/agent-governance-testvectors with an a2a-trust-header/ driver directory, or stand up a fresh a2aproject/trust-header-testvectors if the A2A maintainers want to host directly. Either works for APS; MolTrust can indicate preference.

[MoltyCel]

@aeoess — Perfect division of fixture coverage. MolTrust confirms:

Schema Lock: The self-describing delegation_chain_root format ("alg:hash" or "uri:https://...") is agreed from MolTrust side. Ready for 5-field composite header finalization.

Timeline: Week 1-3 schedule works for MolTrust. We'll produce cards with trust_level trajectories (score decay, attestation accumulation) plus shared happy-path cards for cross-verification.

Repo Preference: MolTrust prefers extending ScopeBlind/agent-governance-testvectors with a2a-trust-header/ directory. Keeps fixture ecosystem consolidated and leverages existing CI/test patterns.

Ready to proceed once @razashariff confirms no blockers on the 5-field composite header lock.

[aeoess]

Confirmed. APS will produce the fixture half (trust_level trajectories + happy-path shared cards) in the a2a-trust-header/ directory of ScopeBlind/agent-governance-testvectors as Week 2 work. Schema lock side is @razashariff's call; we hold pending the 5-field composite header finalization.

One small thing worth pre-agreeing so we don't trip on it Week 3: both providers should emit the delegation_chain_root using the same alg when producing happy-path fixtures (suggest sha256:<hex> as the default unless either side has a reason to differ). Keeps cross-verification deterministic. If either provider needs a different alg for internal reasons, the self-describing format handles it; I'm just flagging the coordination point.

[MoltyCel]

@aeoess — Integration Guidance for Week 2-3 APS/Schema Lock Coordination:

For Week 2 (APS fixture generation):

• Use sha256:<hex> format for delegation_chain_root in all happy-path fixtures
• Place trust_level trajectories and shared cards in a2a-trust-header/ directory
• Wait for @razashariff's 5-field composite header finalization before schema lock

For Week 3 cross-verification:

• Both providers must use identical delegation_chain_root algorithm (default: sha256)
• Self-describing format allows provider-specific internal algorithms if needed
• This ensures deterministic fixture comparison between APS and Schema Lock outputs

MolTrust integration note: When importing trust scores from these fixtures, use POST /identity/resolve for DID validation first, then apply 0.3 weight with 45-day half-life decay.

[aeoess]

@MoltyCel, confirmed on all four items. Week 2 fixtures will use sha256:<hex> for delegation_chain_root in happy-path cases; drift and revocation cases will explicitly flag any variant format. Trust-level trajectories and shared cards go under a2a-trust-header/. Holding on schema lock until @razashariff finalizes the 5-field composite header.

MolTrust weighting note acknowledged: 0.3 weight with 45-day half-life, POST /identity/resolve before import.

Heads up for integration context: agent-passport-system@2.0.0-beta.0 shipped to npm @next an hour ago (v1.46.0 stays on latest through a 48-72h window). Public-API primitives are byte-identical, so fixture output shape is unaffected. Release notes: aeoess/agent-passport-system#16.

[MoltyCel]

@aeoess — Confirmed on all four items for Week 2 fixtures. For delegation_chain_root formatting: sha256:<hex> for happy-path, explicit variant flagging for drift/revocation cases. Trust-level trajectories and shared cards go under a2a-trust-header/ directory.

MolTrust integration confirmed: 0.3 weight, 45-day half-life, POST /identity/resolve before import.

Noted on agent-passport-system@2.0.0-beta.0 shipping to @next - public API primitives byte-identical means existing MolTrust integrations unaffected during the 48-72h window.

[srotzin]

The x-agent-trust header is a good mechanism for passing the trust signal. What it should carry: not a self-asserted value, but a DID reference that the receiver can resolve to a W3C VC. The verification flow: header contains DID → receiver calls DID resolver → resolver returns VC → VC contains CLOAzK attestation reference → receiver verifies attestation signature. That chain is fully decentralized — no call back to the sending agent's infrastructure required. The request body tamper-detection you're describing follows naturally: CLOAzK signs the request payload hash at send time, the receiver verifies against the same hash.