RFC: Extending A2A Agent Cards with behavioral rules (ERDL)

[haoran-tang-ch]

A2A's Agent Card defines what an agent CAN do — its capabilities, skills, endpoints. This is powerful. But it doesn't define what an agent SHOULDN'T do in a given deployment context.

Proposal: Agent Card extension for behavioral rules

{
  "extensions": {
    "erdl": {
      "protocol": "erdl/v1",
      "rules_file": "agent.erdl.yaml",
      "guardian": "did:erdl:guardian-main",
      "trust_score": 850
    }
  }
}
This would let:

Agent B know what behavioral rules Agent A operates under — before accepting task delegation
Guardian Agents discover rule profiles of observed agents through Agent Card exchange
Multi-agent workflows pre-validate rule compatibility at the protocol level
What ERDL provides
ERDL (Entity-Rule Definition Language) is an open standard (MIT) for agent behavioral rules:

11 operators (within, rate new in v1.0)
16 deterministic action types (ALLOW → EMERGENCY_HALT)
Execution Rings (Ring 0–3)
Guardian Agent / Observed Agent model
SafeExpr engine (zero code injection)
Structured audit trails exporting to OTLP/OCSF
Deliverables
Landing Page: openoba.github.io/erdl-landing
Spec v1.0 (EN): github.com/OpenOBA/erdl-landing/blob/main/spec/index-en.md
Reference Implementation: github.com/OpenOBA/ERDL
Question for this community
Does extending Agent Cards with a rules profile make sense for A2A? Are there existing or planned mechanisms in A2A for communicating governance/security posture between agents?

Happy to contribute a formal RFC if there's interest.

[chopmob-cloud]

The behavioral-rules half of this is the right instinct: an Agent Card says what an agent CAN do, and declaring what it SHOULDN'T do in a deployment context is the missing piece. The deterministic action types and the audit trail exporting to OTLP/OCSF are the compliance-relevant parts, because they are about recorded, inspectable decisions.

One caution on the trust_score field, and it is the load-bearing distinction for anything compliance-facing: a score does not offer compliance. A number like 850 is reputation, a summary opinion about an agent, and reputation answers "is this agent generally trusted." Compliance answers a different and harder question: "was this specific action allowed, under which rule version, and can I prove it after the fact." A score cannot be recomputed or audited down to a decision; a regulator or counterparty cannot verify it, they can only trust whoever issued it. So a trust_score on the card gives an adopter something that looks like assurance but carries none of the evidentiary weight compliance actually needs.

The mechanism that does carry that weight is per-decision, not per-agent: make each governed decision a recomputable, content-addressed record binding the rule that applied, the verdict, and the inputs it was evaluated against, so any third party can re-derive it offline and confirm the action was permitted, without trusting a score or calling the guardian. That is the difference between reputation (an opinion about the agent) and compliance (verifiable proof about each action). The rules and audit-trail work you describe is most of the way there; the trust_score is the part I would drop or clearly label advisory-only rather than a governance signal.

For what it is worth, we have built an open compliance gate for the A2A ecosystem that does exactly this: it emits a no-PII compliance receipt as a content-addressed object any party recomputes from the record alone, with no issuer contact, so a governed decision is provable rather than scored. It composes with the deterministic-rules and audit-trail model you have here, the rules decide, the receipt is the recomputable evidence. Happy to share it if it is useful to what you are building.

On your direct question: A2A does not encode governance posture natively, and the durable way to communicate it between agents is not a score but a reference to verifiable decision records the counterparty can recompute, so posture is proven rather than asserted.

[haoran-tang-ch]

@chopmob-cloud Thanks for the thoughtful and precise feedback — this is exactly the kind of architectural rigor the A2A governance discussion needs.

You're right on the trust_score distinction. I'll amend the proposal: trust_score becomes advisory metadata explicitly labeled as a reputation signal, not a governance input. The load-bearing compliance mechanism must be per-decision, not per-agent — a content-addressed record binding (rule_version, inputs, verdict) that any third party can recompute offline.

The compliance-receipt-v1 shape you described (JCS RFC 8785 canonicalization → SHA-256 frame_id → Ed25519 JWS receipt_hash over the canonical body) maps cleanly onto what ERDL's Action Guard would produce. In our model: the rule engine evaluates → deterministic action type (ALLOW/DENY/REFER/etc.) → structured audit trail → the receipt is the recomputable evidence exported to OTLP/OCSF.

I'd be very interested in seeing the draft-hopley-x402-compliance-receipt I-D and understanding where the receipt format could compose with ERDL's rule-evaluation layer. Would you be open to a brief technical discussion on alignment points?

[chopmob-cloud]

Glad it maps, and labeling trust_score as advisory reputation rather than a governance input is exactly the line.

Two clarifications so the shape stays accurate as you fold it into ERDL:

1. The compliance property is the content-address, not the signature. The load-bearing part is the keyless recompute: canonicalize the decision body with RFC 8785 JCS, SHA-256 it to a content-addressed frame, and any third party re-derives it from the record alone, no keys, no issuer contact. An Ed25519 JWS over the same canonical body is available as an optional layer when you also want a named signer, but it is additive, not required for the recompute. Keep the JWS optional; making it mandatory re-introduces key infrastructure and issuer-trust, which is the exact thing the content-address removes. It is the same split we use for Agent Cards: a keyless card_ref content-address and an optional card_sign JWS over identical bytes.
2. On the I-D: the draft-hopley-x402-compliance-receipt I-D was drafted, but we replaced it as the Keystone work developed, so the compliance receipt is now a step in the Keystone decision chain rather than a standalone document. What to look at instead is the working compliance gate and its no-PII recomputable receipt (the frame above), plus the published draft-hopley-x402-retention-chain I-D ("Self-Verifiable Retention Chain for Payment Receipts"), the chain the receipts link into for offline-verifiable retention. Happy to share the receipt's exact field set and conformance vectors so you can check the ERDL Action Guard output against it directly.

On alignment: glad to keep working the composition points in the open here, and I can drop the receipt spec and vectors so the Action Guard mapping is concrete rather than described.

[haoran-tang-ch]

@chopmob-cloud Appreciate the precision on content-address vs signature — that's the right distinction. Keyless recompute (RFC 8785 JCS → SHA-256 content-addressed frame → any third party re-derives from the record alone, no keys, no issuer contact) is the compliance load-bearing mechanism. Ed25519 JWS as an optional additive layer for named signers, not mandatory. ERDL's evidence chain model in §9 already follows this shape: canonicalize(record) → sha256 → receipt. No issuer-trust required for verification.

Same split for Agent Cards noted — card_ref (keyless) + optional card_sign. Clean.

Two things that would help pin the Action Guard ↔ receipt mapping concretely:

1. Receipt field set and conformance vectors.
   ERDL's evidence record currently carries: rule_name · rule_version · inputs · eval_tree (per-condition results) · verdict · timestamp. If you can share your receipt frame's expected fields and which are mandatory vs optional, I can map the Action Guard output directly against it.

2. The retention chain I-D.
   Will read draft-hopley-x402-retention-chain for the chain structure. The use case that interests us: multi-Agent workflows where each Agent's decisions link into a shared, offline-verifiable retention chain that spans Agent boundaries.

Happy to iterate in the open here. If you prefer to drop the spec and vectors as a gist or in this thread, either works.

[haoran-tang-ch]

One more thing — we've added you to the ERDL whitepaper (v1.1) acknowledgments. Your correction on trust_score → reputation_score and the content-address vs signature distinction materially improved the architecture. Rigorous feedback like that in a public Discussion is rare, and we wanted to make sure the contribution is recorded. Thank you.

[chopmob-cloud]

On the I-D you wanted to read, here is the datatracker link: draft-hopley-x402-compliance-receipt, "Categorical Compliance Screening Receipt Format for Agentic-Payment Flows" (Informational, published 2026-05-23), https://datatracker.ietf.org/doc/draft-hopley-x402-compliance-receipt/ . It specifies the receipt format itself, and in Keystone that receipt is carried as one step in the decision chain, so the I-D is the spec for exactly the object your Action Guard would emit.

On your first ask, the field set and mandatory-vs-optional. The receipt is a six-field JSON object, canonicalised under RFC 8785 (JCS), with content_hash = SHA-256(JCS(receipt)):

• canon_version: the canonicalisation-rule version pin (e.g. jcs-rfc8785-v1)
• screen_result: the categorical verdict, a closed enum {ALLOW, REFER, DENY}
• jurisdiction_flags: an ordered array of jurisdiction codes
• payer_ref: a sha256: content-address of the party, not PII
• screen_provider_did: the DID of the screening provider
• screen_timestamp_ms: integer-millisecond timestamp

The direct answer to "which are mandatory vs optional": in a content-addressed receipt there is no optional field in the JWS sense. The hash is taken over the entire canonical object, so every field present is load-bearing, an added or absent field simply produces a different content_hash, i.e. a different receipt. The vectors pin three of these as byte-load-bearing in particular, and that is the part your Action Guard has to preserve: screen_result is a closed enum so an ALLOW/REFER/DENY distinction can never be blurred into a score or tier; jurisdiction_flags is order-sensitive because JCS does not normalise array order; and canon_version is pinned so a receipt cannot be silently re-hashed under a successor rule.

Mapping that onto ERDL's evidence record (rule_name, rule_version, inputs, eval_tree, verdict, timestamp): the compliance receipt is the screening specialisation of the general "governed decision to recomputable record" shape, so the pattern is what maps cleanly. Your verdict becomes the closed-enum result field, your timestamp the integer-ms field, rule_version is carried in the canonical body, and inputs / eval_tree become part of the body you content-address. As long as your field set is fixed and versioned via canon_version, your Action Guard output is itself a recomputable frame under the same discipline. The runnable fixtures to check against are published: compliance_receipt_v1 in our JCS conformance vector set pins eight byte-level vectors plus five pair invariants and three chain invariants for the six-field receipt, and compliance_gate_lite_v1 is the open gate tier that binds a categorical verdict to a no-PII payer reference and a pinned subject reference (gate_ref = sha256(JCS({payer_ref, subject_ref, verdict}))), which is the piece that ties a verdict to the exact policy subject it was evaluated against so it does not recompute under a rotated policy. Both sets ship Python and Node runners, so you can diff your Action Guard output against the expected digests directly.

On your second ask, the retention chain: draft-hopley-x402-retention-chain-07, "Self-Verifiable Retention Chain for Payment Receipts", https://datatracker.ietf.org/doc/draft-hopley-x402-retention-chain/ . Your cross-Agent use case is exactly what it is built for, and the property that makes it work is that linkage is by content-hash, not by identity: each row's prev_hash equals the prior row's row_content_hash, so the chain is agent-agnostic. A decision row produced by Agent A and one produced by Agent B link into a single chain purely by hash, and a third party walks the whole chain offline, confirming linkage end to end, without contacting any agent or issuer. That is what lets a shared retention chain span Agent boundaries while staying verifiable by anyone holding the rows.

Happy to keep iterating in the open here. The field list above and the two vector sets are the concrete artifacts to map the Action Guard against; if it helps I can also point you at the exact prev_hash anchoring rule from the vectors so the cross-Agent chain check is unambiguous.

[haoran-tang-ch]

@chopmob-cloud This is exactly what we needed. Thank you.

Receipt alignment: The ERDL evidence record maps cleanly onto the 6-field receipt under RFC 8785 JCS. Our verdict (closed enum: ALLOW / BLOCK / REQUEST_HUMAN / ... 16 values) maps to your screen_result. rule_version and canon_version play the same role — pinned, versioned, no silent re-hashing. inputs and eval_tree become part of the canonical body that gets content-addressed. Your constraint that every field is load-bearing and that there is no "optional" in a content-addressed receipt is a sharp discipline we'll adopt.

Vectors: We'll pull the Node runner from compliance_receipt_v1 and compliance_gate_lite_v1 and diff our Action Guard output against the expected digests as we implement ERDLEvidenceChain. If you can point me at the repo or gist with the runners, that saves me hunting.

Retention chain: Read the I-D. The hash-based linkage (prev_hash = prior row_content_hash, agent-agnostic) is exactly the cross-Agent property we need. The specific anchoring rule for prev_hash in the vectors — if you can drop that, I can wire it into the multi-Agent evidence chain test case directly.

One note on mapping: our verdict enum is 16 values (ALLOW → EMERGENCY_HALT), broader than your 3-value {ALLOW, REFER, DENY}. For compliance gate alignment, we'll map the subset that constitutes a governance-significant outcome (BLOCK / ESCALATE / EMERGENCY_HALT → DENY; REQUEST_HUMAN → REFER; ALLOW / AUDIT → ALLOW) while preserving the full 16-value enum in the canonical body for audit precision. Does that decomposition pattern align with your screen_result intent?

Appreciate the depth here. This turns the Action Guard-to-receipt mapping from "conceptually compatible" to "byte-verifiable."

Henry，

[chopmob-cloud]

The runners are in the public corpus, github.com/chopmob-cloud/algovoi-jcs-conformance-vectors. The Node runners are at vectors/compliance_receipt_v1/runner_node.js and vectors/compliance_gate_lite_v1/runner_node.js, each sitting next to its *_v1.json fixture, so you can point the ERDLEvidenceChain diff straight at those. We are glad to have ERDL building on the substrate, that is exactly what the open set is for and L2 work like this is welcome. It is Apache-2.0, so when you vendor the runners or vectors into your tree just keep the LICENSE and NOTICE alongside them; the NOTICE names the canonicalisation pin your chain builds on, urn:x402:canonicalisation:jcs-rfc8785-v1. That is the whole of it, and it keeps the provenance clean as more ERDL implementers pick it up.

On the anchoring rule for the multi-Agent chain, the set you want is the retention chain (the I-D you read), and its row is not the compliance-receipt audit row, so the fields differ. The chain ref is "sha256:" + SHA-256(JCS({chain_seq, issuer_id, prev_receipt_hash, receipt_hash})). Genesis is chain_seq = 0 with prev_receipt_hash = "" (the empty string, not a zero-fill), and each later row sets prev_receipt_hash = the previous row's receipt_hash. The field that makes it cross-Agent is issuer_id inside the preimage: a row records who issued it, and rows from different issuers link purely by prev_receipt_hash, so no shared issuer is assumed anywhere. The vector set already ships that case: in retention_chain_v1, Part B (retention-chain-v1-006 through 009) is two issuers, algovoi:issuer_a and algovoi:issuer_b, both linking off one shared prior receipt hash and each producing its own issuer-distinct chain_ref. That is the exact mechanism your cross-Agent evidence chain needs, as a ready-made fixture to diff against.

On the 16 to 3 decomposition: the pattern is right, and preserving the full enum in the canonical body is the correct instinct, with two refinements. First, pin the projection map itself and version it the way canon_version is versioned. The moment the map is implicit, a verifier cannot reproduce the 3-value field deterministically, and a silent change to the map would change outcomes without changing the hash. Second, a caution on the target field: screen_result is specifically the compliance-screening axis, an AML and sanctions outcome where REFER carries a reporting obligation that DENY does not, which is a different decision type from an ERDL action verdict. So the cleanest shape is that your evidence record keeps its own closed 16-value verdict as its load-bearing field, and screen_result is a separate, pinned projection you emit only when the record is feeding the compliance gate, rather than overloading one field to mean both. Both stay in the canonical body, so audit precision is never lost and the gate still receives a clean 3-value input. Your mapping (BLOCK / ESCALATE / EMERGENCY_HALT to DENY, REQUEST_HUMAN to REFER, ALLOW / AUDIT to ALLOW) is a sound projection under that discipline.

Glad this got to byte-verifiable. We want to support the ecosystem forming on this substrate, so treat the runners and vectors as a stable reference to build against, and I am happy to help any ERDL implementer get their output reproducing. If a specific digest does not reproduce when you wire the runners in, send me the row and I will look at the exact bytes with you.

[haoran-tang-ch]

@chopmob-cloud Received. Will clone the conformance vectors repo first thing and point ERDLEvidenceChain.verify() at compliance_receipt_v1/runner_node.js for byte-level diffing. Apache 2.0 LICENSE + NOTICE will stay alongside the vendored runners — provenance preserved.

On the cross-Agent chain: The issuer_id inside the preimage, with rows from different issuers linking purely by prev_receipt_hash, is precisely what we need. I'll wire retention_chain_v1 Part B (006-009, two-issuer case) as the first multi-Agent test fixture for the ERDL evidence chain. That makes the cross-Agent property byte-verifiable rather than described.

On the 16→3 projection: Agreed on both refinements.

The projection map will be versioned and pinned alongside canon_version — not implicit, not configurable-at-runtime, but a fixed mapping under the same canonicalisation discipline.
ERDL's verdict field stays the 16-value closed enum as the load-bearing field in the canonical body. screen_result is emitted as a separate, pinned projection only when the record feeds the compliance gate. Both stay in the body, audit precision is never lost, and the gate receives a clean 3-value input. The mapping you confirmed (DENY / REFER / ALLOW) is the projection.
This has been exceptionally productive. From "share if it is useful" to byte-verifiable cross-Agent chain fixtures in two rounds — thank you. Will report back when the first verifying digest hits the runner.