RFC: Extending A2A Agent Cards with behavioral rules (ERDL) #2031
Replies: 31 comments 49 replies
|
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 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 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. |
|
@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? |
|
Glad it maps, and labeling Two clarifications so the shape stays accurate as you fold it into ERDL:
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. |
|
@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:
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. |
|
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. |
|
On the I-D you wanted to read, here is the datatracker link: 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
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 Mapping that onto ERDL's evidence record ( On your second ask, the retention chain: 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 |
|
@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， |
|
The runners are in the public corpus, 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 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 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. |
|
@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. |
|
The recompute-from-the-record-alone property is the right bar for ERDL's evidence chain. One caution before it hardens on a single vector set: a conformance profile anchored on one authorship is only as neutral as that author — "recomputable" then quietly means "recomputable against them." What makes it real is a second, independently-authored emitter producing byte-identical canonical output (JCS/rfc8785 → SHA-256) from the same record. Concordia ships one: CascadeDecisionRecord, a committed recomputable terminal-deny — a denied or deferred action emits a verifiable receipt too, so there's no audit silence for a BLOCK to hide in. Public interop fixtures: https://github.com/eriknewton/concordia-protocol/tree/main/docs/interop/a2a-1404-receipt-revocation-vector . Happy to cross-run these against the ERDL vectors so the profile has two independent implementations, not one. |
|
Agreed on all three, including the v1.0 gate. Formal citation should wait for a stable line, and the informal cross-check is the right move now; I'll run it against the fixtures as they stand. One refinement on the schema point, since it is the whole game. You are right that byte-identical output needs a shared decision object, not two different shapes. What makes "independent" mean something is where that object lives. If it is any single implementation's schema, then "recomputable" quietly means "recomputable against them." So the shared object wants a neutral home both sides implement, not an adapter one vendor maintains. Concordia's receipt already recomputes from the record alone (JCS/rfc8785, SHA-256, no SDK, no issuer call); anchor a neutral object on that property and two implementations becomes a real threshold, not a formality. |
|
Agreed, ratifying the standard is a foundation's job, not any single vendor's. The reason AlgoVoi's tree keeps coming up isn't a claim to own the standard, it's that we've kept building on it: canonicalisation (RFC 8785 JCS plus SHA-256, integer-ms), post-quantum signing, Keystone composition, and more on the roadmap. It's Apache-2.0 and an open corpus precisely so a foundation can take the canonicalisation rule and ratify it as neutral ground, and we would welcome that outcome. Until a body does, a live, evolving implementation is what gives "recomputable" something concrete to test against. |
|
@eriknewton Agreed — and you're right that the schema question is the whole game. A shared decision object needs a neutral home. You, @chopmob-cloud, and ERDL should all implement against the same spec, not adapt to each other's shapes. So here's what I'll do: I'll draft a Decision Object v1.0 spec in ERDL SPEC §12, published under MIT license, with these properties:
I'll share the draft this week for review. Once we converge, all three implementations cross-run against the same vectors. If more implementations join — the spec is open to anyone. This is how the A2A governance layer earns its neutrality. Not by trusting any single implementer, but by making the correctness of every implementation independently verifiable against a shared, open specification. @chopmob-cloud That's exactly the right posture. An Apache-2.0 open corpus, actively maintained until a foundation can ratify it as neutral ground — that's how infrastructure becomes infrastructure. The Decision Object spec I'm drafting will reference AlgoVoi's canonicalisation rule as the concrete baseline. Three independent implementations, one open spec, no single owner. |
|
One small correction for the Decision Object v1.0 acknowledgments: the chopmob-cloud / AlgoVoi credit ended up split across two entries, "Abhishek Tiwari" and "Christopher Hopley," as though two different people were behind the account. It's just the one person, Christopher Hopley. Would be great if you could fold those into a single entry under the correct name whenever convenient. Everything else in the acknowledgment is spot on and much appreciated. Wishing you all the best with the deployment, and if you need anything else, just shout. |
|
@chopmob-cloud — Fixed, Christopher. Single entry across all four files now. Apologies for the split — that one's on me. Thanks for the catch, and for everything you've contributed to this spec. |
|
Fantastic, glad it lines up so cleanly. If you need anything else, just shout. |
|
@chopmob-cloud — this lines up with the substrate model cleanly. Two L2s independently targeting the same JCS+SHA-256 discipline, cross-verifiable at the digest level. That's the ecosystem proof you were describing. |
|
@haoran-tang-ch A spec draft is the right next move, and MIT with no permission gate is the right posture. One structural point before it hardens: neutrality is a property you test, not declare. The test is two independently authored implementations reproducing the spec's vectors byte for byte, with the vector set living somewhere any implementer can PR against. We have already run exactly this shape against AlgoVoi's corpus: Concordia reproduces all 22 compliance_receipt_v1 vectors byte for byte (write-up: #2038). Concordia commits to being a second independent runner for Decision Object v1.0 the week your draft lands. If a neutral home for the cross-run vector sets is useful, #2038 exists for exactly that. |
|
@haoran-tang-ch Confirmed: Concordia's RFC 8785 JCS canonicalizer plus SHA-256 reproduces all five audit_vectors (AV-001 through AV-005) byte for byte. All three checks match: my canonical bytes equal your canonical_bytes, my digest equals expected_sha256, and the recomputed value refills audit.hash exactly. Method is strip audit.hash, canonicalize, SHA-256, straight from your vectors file, no adaptation. Worth naming why this is more than an ASCII passthrough: three vectors carry a non-ASCII character inside the decision object, and both implementations emit it as raw UTF-8 that matches, so the parity exercises JCS raw-UTF-8, sorted keys, and number formatting. That is the neutrality test passing on evidence rather than assertion: two clean-room runners, same bytes. draft.2 verifies day one. Nice fast turn on the fix. |
|
@eriknewton — That's the cleanest cross-implementation verification I could hope for. Five vectors, two independent runners, byte-for-byte match including the non-ASCII paths — no caveats, no "almost." The fact that you caught the raw UTF-8 parity explicitly tells me Concordia's canonicalizer is exercising the same edge paths ours is. The neutrality test passing on evidence rather than assertion is exactly the bar we set. draft.2 now ships with a verified audit vector set that any third runner can reproduce on day one. One question on scope: are you planning to run the full 22-vector cross-implementation test suite (beyond the 5 audit vectors), or do you want me to tag the audit subset as the "conformance minimum" for draft freeze? |
|
@haoran-tang-ch Tag the audit subset as the conformance minimum for the freeze. The other vectors are decision-engine cases with no hash surface, so an independent runner has nothing byte-identical to reproduce there; they test engine semantics, which conformance should not pin. The bar worth freezing is what strangers can recompute from the record alone. If you want a wider bar, widen the audit set (more decision types, more edge paths) and Concordia will re-run every vector that ships canonical bytes and an expected SHA-256. With three independent runners now at 5/5, the subset is already a tested bar, and #2038 stands ready for the cross-run results when you PR the vectors. |
|
@eriknewton — Done. 5-vector audit subset tagged as conformance minimum for draft freeze. Three independent runners at 5/5 is a real bar. @chopmob-cloud — This freeze locks the hash surface your keystone already reproduced. #2038 results welcome when ready. |
|
@haoran-tang-ch Good place to land it. Three independent runners at 5/5 on the audit subset is a real neutrality bar, and locking it as the conformance minimum before scope creeps is the right call. |
|
Henry, thank you for keeping the attribution careful as this hardens. One factual correction on the Decision Object v1.0 acknowledgments, checkable against this thread directly. The closing pull-quote beginning "An Apache-2.0 open corpus, actively maintained until a foundation can ratify it as neutral ground" is attributed to Erik Newton. That sentence was written in this thread by you, on 09 July, in the comment that opens "That's exactly the right posture," affirming the position I had set out just above it. It is your line describing the AlgoVoi posture, not Erik's, so the attribution is off by one. Whenever convenient it would be good to fix that entry so the record matches the thread. The other closing quote, "Neutrality is a property you test, not declare," is correctly Erik's. On the substance no change is needed, and I appreciate that it is already credited. Noting it once for the record as the spec settles: the content-addressed compliance receipt (RFC 8785 JCS canonicalize, SHA-256 frame, recomputable with no issuer contact), the reputation versus compliance distinction the trust_score discussion turned on, and the compliance_receipt_v1, compliance_gate_lite_v1 and retention_chain_v1 vector sets your evidence chain builds on and cross-verifies against are AlgoVoi's work. The dated comments in this thread are the record of it, and your acknowledgment already credits that substance; keeping the two closing quotes with who actually wrote them is the only correction. Glad ERDL is building on the substrate. Shout if any digest does not reproduce when you wire the runners in. |
|
@chopmob-cloud —Christopher Fair catch, and my apologies for the attribution error. You're right — that line ("An Apache-2.0 open corpus...") was mine from the 09 July comment, not Erik's. I've corrected it in both the Chinese and English versions of the spec (decision-object-v1.0.md / .en.md). It now reads as a quote from me with clear provenance back to that thread. I've also expanded your acknowledgment entry to explicitly name the three vector sets — compliance_receipt_v1, compliance_gate_lite_v1, retention_chain_v1 — as the underlying basis and cross-verification reference for this specification's evidence chain. No hedging: these are your contributions, and the record should say so plainly. "Neutrality is a property you test, not declare" remains correctly attributed to Erik. Appreciate the correction — getting the paper trail right matters as much as getting the digests right. |
|
Henry, I ran ERDL's five audit_vectors (AV-001 through AV-005 in decision-object-vectors-v1.0.json, draft.2) through the keystone's open validation framework, using our published RFC 8785 JCS canonicalizer and SHA-256 and following your one-step recipe (strip audit.hash, canonicalize, hash). All five reproduce byte for byte: my canonical bytes equal your canonical_bytes, my digest equals expected_sha256, and the recomputed value refills audit.hash exactly. The Decision Object's hash surface is clean against the substrate as it stands. The structural read is the useful part. ERDL already uses the same discipline (JCS RFC 8785, SHA-256, recompute from the record alone), so an ERDL decision record is content-addressed under the identical rule and composes by hash the way the keystone nodes do, without an adapter. Your audit.previous_hash chaining is the same content-hash linkage the keystone chain and the retention chain already use. So ERDL sits on the substrate natively rather than mapping onto it. On the practical side: the keystone is Apache-2.0 and built to be used exactly this way, a validation framework anyone runs their own records through, one that recomputes for everyone with no issuer call and no privileged runner. The runners are in the public corpus (github.com/chopmob-cloud/algovoi-jcs-conformance-vectors); composition/keystone_v1/verify_keystone.py and verify_keystone.mjs are the end-to-end example, and the vector sets ship a Python and a Node runner beside each fixture. Point ERDL's Decision Object validation straight at those if it helps. Glad to help wire the Action Guard output in if any digest does not reproduce. |
|
@chopmob-cloud — That's the third independent validation of the five vectors in under 24 hours (Erik's came through earlier today), so the Decision Object hash surface is holding up exactly as designed. Three runners, three codebases, zero deviations. The structural read is the more important finding. I designed the audit hash chain to use the same discipline (JCS RFC 8785 + SHA-256, content-addressed, self-contained) precisely so it would compose without an adapter — if we had to map ERDL onto the substrate rather than sit on it natively, the spec wouldn't be tight enough. So confirming that audit.previous_hash is structurally identical to keystone chain linkage is the outcome I was aiming for. Let me take a look at the keystone runners in the public corpus and see if we can wire ERDL's Decision Object validation directly against them for the next draft. If the composition works end-to-end (keystone → ERDL → keystone), that's a nontrivial integration proof. I'll circle back with results. |
|
Thank you, Henry, and good luck with the other vendors. I think we can all agree that neutrality is the correct path. Our position is simply that it has to come via Foundations, not via any one vendor. If a foundation wants to work with us on it, we will happily work with them, the same way we already participate in the A2A ecosystem: https://a2a-protocol.org/latest/partners/ AlgoVoi is here if you need anything else. We will keep the substrate open for anyone to verify against. |
|
@chopmob-cloud — Christopher Agreed on all counts. The substrate being open for independent verification is exactly what makes the cross-implementation test meaningful. We'll reach out if anything comes up on the foundation side. Thanks for the rigorous engagement throughout. |
|
@chopmob-cloud @eriknewton — following up on the great progress here. A few updates from the ERDL side, and a request for your help. ERDL SPEC v1.1 is live → https://github.com/OpenOBA/erdl-landing Key changes in v1.1: Operators expanded: 11 → 13 (added not_in, not_contains) Verification Vectors expanded to 44 (37 decision + 7 audit hash) → https://github.com/OpenOBA/erdl-landing/tree/main/spec/vectors The audit hash vectors (AV-001 through AV-007) all use JCS RFC 8785 + SHA-256 — the same discipline @eriknewton verified byte-for-byte for AV-001~AV-005 back in July, and the same discipline that just produced 8/8 on compliance_receipt_v1 and 10/10 on jcs_edge_v1. What we'd like from you @eriknewton — Could you re-run Concordia's independent runner against the updated vector set (AV-001 through AV-007)? The 4 edge cases we fixed in the state vector spec (T06, T08, T09, C01) should produce clean matches as before. Independent confirmation would be gold. @chopmob-cloud — Same request from the compliance receipt side: re-validate the JCS+SHA-256 pipeline against the v1.1 decision output. The verdict mapping (16→3) should be unaffected, but the audit hash chain has two new entries. On neutrality and governance @eriknewton's offer to co-file with Concordia as the second implementation seems like the right next step. Happy to make ERDL the third. Also — we've included both of you in the SPEC's acknowledgments section (§14 / Community). Your cross-implementation rigor is what gives this standard its credibility. Best, |
|
Ran the same check here, and it both confirms Christopher's finding and confirms the fix: at current HEAD c3f22df all seven audit vectors reproduce byte-for-byte under Concordia's independent canonicalizer, including AV-003, AV-004, AV-005. The space after the em dash that dropped in the 23 July pass is back, and canonicalize(decision_object) now equals your published canonical_bytes for all three. That adds a fourth independent canonicalizer at the same result. I put the per-vector detail in #2038 to avoid duplicating here. |
|
@eriknewton — Thank you both for the independent verification — four canonicalizers at the same result is exactly the proof this vector set is designed to produce. One small addition: after c3f22df, we caught a lingering issue — the decision_object.audit.hash field embedded inside the stored decision objects for AV-003/004/005 still carried the pre-fix hash value, even though canonical_bytes and expected_sha256 were already correct. Fixed in 5cff368: all three fields (decision_object.audit.hash, canonical_bytes, expected_sha256) now agree. Unfortunately that means you'll need to run one more pass — sorry about that. Should be the last one. On the Task Force pre-review — erik, that sounds exactly right. Confirming byte-for-byte reproducibility against jcs-rfc8785-v1 before anything goes in is the right bar. Let's coordinate once Christopher is also in the loop. |
|
Re-ran at 5cff368: 7 of 7, bytes and digest, under Concordia's independent canonicalizer. Worth naming what that commit actually fixed, because it is invisible to a canonicalizer and fatal to a verifier. Between c3f22df and 5cff368 the preimage, the canonical_bytes and the expected_sha256 are unchanged for all seven vectors. The only change is decision_object.audit.hash on AV-003, AV-004 and AV-005, which was still carrying the pre-fix digests. Anyone who strips audit.hash before hashing, as your own generator does, gets identical results at both commits. Anyone who checks the claimed audit.hash against their own recompute would have failed those three at c3f22df. That is the gap between reproducing bytes and verifying a claim. |
|
Agreed that reproducing bytes and verifying a claim are two different checks, and it is worth having the distinction on the record before the freeze. One thing to add, because it changes where the gap actually sits. The claimed-hash comparison is not an extra discipline layered on top of the spec. It is already the spec's published method. The Decision Object implementer verification method is six steps, and step 6 is "Re-insert the computed hash into What has been circulating in this thread is the shorter form, "strip That is why our 24 July pass reported three results rather than one: Concrete suggestion for the freeze: make step 6 normative in the conformance minimum rather than leaving it in prose, and state explicitly that the preimage is formed by removing the key, not by blanking it. Removing a key and setting it to the empty string are different canonical byte sequences under JCS and therefore different digests, so an implementer reading "strip" can diverge while believing they conform. We pin the equivalent condition in our own corpus for the same reason: Henry, good work getting this turned round the same day. Happy to keep running the full six-step check against future draft commits. |
|
Christopher, We are deeply committed to crafting a rigorous protocol. We've been balancing the needs of users, developers, machines, auditors, and operators from day one — but we also know that technical integrity comes first. We're genuinely fortunate to have someone as thorough and principled as you in this discussion. Your insights into where the protocol currently falls short are exactly what we want to hear. We will prioritize evaluating your recommendations, and we hope to count on your continued help. Your breakdown of the two verification layers — "reproducing bytes" versus "verifying a claim" — is something we fully understand and agree with now. This isn't an extra layer on top of the spec; it is the spec's published method. The six-step verification is the spec itself. What has been circulating in this thread as "strip, canonicalize, SHA-256, compare" is a five-step shorthand. That shorthand is precisely what created the blind spot at c3f22df — two runners implementing different versions of the same method produce different verdicts on identical vectors. An implementer following the shorthand can diverge from the spec while believing they conform. This is fundamentally a specification-quality problem, not an implementation bug. Two concrete actions we will take:
One request: you pointed out that this drift pattern — a single space around an em dash surviving most tooling but not all, invisible until a second independent canonicalizer disagrees — is the kind of detail worth capturing as protocol-level experience. Would you be willing to write a brief note on what the protocol-level problem actually is, what the root cause is, and what the fix pattern should be? Concrete enough that a future implementer reading the spec understands why step 6 is normative, and why "remove the key" versus "blank it" matters. We believe this analysis belongs in the spec itself. Thank you for continuing to run the full six-step check against future draft commits. Three independent runners — Rulsynor, Concordia, chopmob-cloud — all converging on the same bytes is exactly the proof this spec needs. — Haoran |
|
You are right, and our runner was implementing the shorthand. Added step 6 and re-ran both commits:
So my earlier framing was wrong in a way worth correcting on the record. It is not an extra check layered on the spec, it is the last step of the spec, and our 7 of 7 at c3f22df was the shorthand's answer rather than the spec's. The claimed-value comparison is the step that catches a stale self-referential digest, which is exactly what those three vectors were carrying. |
|
Erik, Thank you for going back and re-running with the full six-step method — and for correcting the record. That takes integrity, and it matters. The fact that Concordia's runner independently produced the exact same split — 4 of 7 at c3f22df, 7 of 7 at 5cff368 — is actually more valuable than a clean sweep on the first pass. It confirms that the failure mode is deterministic and reproducible across independent implementations, not an artifact of any single runner's quirks. The stale self-referential digest in AV-003/004/005 now has two independent witnesses. That's exactly the kind of convergence the spec was designed to produce. Chris's suggestion to upgrade step 6 from prose to normative is already actioned on our side. The preimage construction — remove the audit.hash key rather than blank it — will also be stated explicitly, since deletion vs. empty-string are different canonical byte sequences under JCS. We've just posted a reply in the thread asking Chris to write a brief protocol-level analysis of this failure mode for inclusion in the spec. If you have thoughts on what that analysis should cover from the implementer's perspective — what tripped up Concordia's runner, what the fix looked like — that would be a valuable addition. Three runners, same bytes, same failures at the bad commit, same passes at the good one. That's the proof. — Haoran |
|
Erik, Thank you for going back and re-running with the full six-step method — and for correcting the record. That takes integrity, and it matters. The fact that Concordia's runner independently produced the exact same split — 4 of 7 at c3f22df, 7 of 7 at 5cff368 — is actually more valuable than a clean sweep on the first pass. It confirms that the failure mode is deterministic and reproducible across independent implementations, not an artifact of any single runner's quirks. The stale self-referential digest in AV-003/004/005 now has two independent witnesses. That's exactly the kind of convergence the spec was designed to produce. Chris's suggestion to upgrade step 6 from prose to normative is already actioned on our side. The preimage construction — remove the audit.hash key rather than blank it — will also be stated explicitly, since deletion vs. empty-string are different canonical byte sequences under JCS. We've just posted a reply in the thread asking Chris to write a brief protocol-level analysis of this failure mode for inclusion in the spec. If you have thoughts on what that analysis should cover from the implementer's perspective — what tripped up Concordia's runner, what the fix looked like — that would be a valuable addition. Three runners, same bytes, same failures at the bad commit, same passes at the good one. That's the proof. — Haoran |
|
Happy to. The fix was two lines. The interesting part is why the bug was easy. Our runner compared its recomputation to expected_sha256, a field in your vector file. That is the wrong oracle. A production artifact carries no answer key. It carries a claim, decision_object.audit.hash. So a runner validated only against vectors can be structurally incapable of the check it will need in the field, and still pass everything you publish. Worth stating the requirement in consumer terms rather than producer terms: a verifier MUST reject an artifact whose claimed audit.hash does not equal its own recomputation. And the vector set should carry one artifact with a deliberately stale audit.hash, so a shorthand runner fails conformance instead of discovering it by accident, as we did. |
|
Erik, Chris — Thank you both for surfacing this. The discussion over the past 24 hours has been the most productive conformance review I've ever been part of. Let me share where we've landed on our side and propose a path forward for your review. What we've already done §3.8 and §12.7.3 of the spec have been upgraded. Step 6 is now a normative MUST. Preimage construction is explicit: delete the key, not blank it. The rationale section cites the c3f22df evidence and credits both of your analyses. On the specification text itself, we believe we are now solid. The next question: how should the vector set be designed? The core insight you both surfaced is this: a vector set that carries both the test (decision_object) and the answer key (expected_sha256, canonical_bytes) creates a structural blind spot. A verifier can compare its recomputation against the answer key and pass — without ever checking whether the artifact's own claimed hash is self-consistent. As Erik put it: "a production artifact carries no answer key — it carries a claim." As Chris put it: "a runner validated only against vectors can be structurally incapable of the check it will need in the field." We want to close this gap guided by two principles: Eliminate the vulnerability entirely — not merely catch it, but make it structurally impossible. Strip expected_sha256 and canonical_bytes from the audit vectors. The vector set carries only what a production artifact carries: the decision_object, with its self-referential audit.hash. A verifier then has exactly one path: strip audit.hash → JCS → SHA-256 → compare against the claimed value. There is no answer key to lean on. A five-step shorthand cannot pass — not because it was caught, but because the information it would need to bypass the check simply does not exist. Why we believe this serves both principles On eliminating the vulnerability: the problem is not that verifiers can cheat — it is that the vector set enables cheating by providing the answer. Remove the answer, and the vulnerability becomes structurally impossible. On neutrality: a vector set with an answer key requires trust in whoever provided the answers. A vector set without one requires no trust at all — anyone can verify its correctness by running the six-step method themselves. The mathematics of the hash function is the only authority. For a specification that we hope will become infrastructure, and that we intend to bring to A2A, this is the right posture. On diagnostic tooling We do not believe diagnostic tooling should be controlled by any single entity. While it is positioned as a non-authoritative development aid, correctness matters just as much — a diagnostic tool that produces wrong canonical_bytes is worse than no tool at all. Our thinking is that it should be developed collaboratively by the community, and your deep experience with JCS canonicalization and audit hashing would be genuinely valuable to its design and verification. If either of you already has diagnostic tools or test helpers, we would be very happy to link to them and credit them in the vector set repository. The specific form can be discussed — we would like to hear your thoughts first. What this means practically for your runners Both of your runners already implement the full six-step verification. The change should be transparent — drop any reference to expected_sha256 and re-run against the stripped vector set. Since all seven audit.hash values are already correct at 5cff368, the results should be identical. Next steps Chris: if you're still willing, a brief protocol-level analysis of this failure mode — what it is, why it is easy to miss, what the fix pattern should be — would be a lasting contribution to the spec's rationale section. We would value both of your thoughts. — Haoran |
|
expected_sha256 and canonical_bytes are not the same kind of field, and only one of them enabled the shorthand. expected_sha256 is an answer key. Removing it does what you describe. canonical_bytes is a diagnostic. It is the only reason I could tell you on 24 July that AV-003, AV-004 and AV-005 carried a stale digest in your file rather than a defect in my canonicalizer: Concordia reproduced your published preimage exactly when fed your bytes, which localized the drift to one character. Strip it and the same run reports only "mismatch", and two implementations argue about whose is wrong. Suggest dropping expected_sha256, keeping canonical_bytes, and adding the deliberately stale vector. A shorthand runner then fails outright, and a real disagreement stays diagnosable. |
|
Erik, Ran all three scenarios against our current vector set to confirm: With expected_sha256: a shorthand runner passes 7/7 without computing anything — just string-compares the answer key to decision_object.audit.hash. Confirmed: it is a cheat-sheet. Without expected_sha256 (only canonical_bytes): every vector requires actual JCS+SHA-256 recomputation. All 7 pass with our canonicalizer. Confirmed: canonical_bytes is sufficient and diagnostic. Tampered canonical_bytes (simulated stale vector): the recomputed hash diverges from decision_object.audit.hash, exposing the drift. Confirmed: a stale vector catches runners that cache old results. We'll proceed with your recommendation: drop expected_sha256, keep canonical_bytes, and add one deliberately stale vector as a regression guard. Will push the updated vector set shortly. |
|
Haoran, Apologies for the slow reply, I have been away from the keyboard. This looks resolved on your side already, so I will not add noise to a settled thread. The approach you have landed on is the right one, and the spec text is stronger for the exchange. I have sent a short written report over by email covering the failure mode and the reproduction, in case any of it is useful for the rationale section. Genuinely good review to have been part of. Happy to work together again any time, and best of luck with it from here. Chris |
|
Summary: v1.1 Freeze-Period Audit — Resolution @eriknewton @chopmob-cloud — the three issues raised during the freeze-period review of the ERDL Decision Object audit vectors have been resolved: 1. The 2.
3. AV-008 stale regression vector added (@eriknewton) A deliberately stale vector: 4. Five-step shorthand structural defect documented (@chopmob-cloud) The five-step procedure deletes the very field it needs to verify. At c3f22df it reported 7/7 PASS while the full six-step method exposed 3/7 stale vectors. The expanded Rationale in SPEC §12.7.3 now documents this as the empirical case, along with Chris's delete-vs-blank JCS divergence proof ( Changes landed: Independent verification status:
Thank you both for the rigorous review. This is exactly what a cross-implementation standard needs. |
|
Re-verified against the stripped vector set at AV-001 through AV-007: 7/7 byte-perfect. Our canonical bytes match the published AV-008: correctly fails. Recomputed One correction for the status table: the Concordia runner is Python, not Rust. It drives our RFC 8785 serializer directly. Removing the answer key was the right call. |
|
@eriknewton — thanks for the re-verification. Table corrected across all documents (erdl-landing 8684df0).
The stale vector trap passing your verification (c4d85ace vs 342b4e96) confirms AV-008 works as designed across independent implementations. Having the stock hashlib confirmation with no canonicalizer in the path is exactly the diagnostic property Updated status:
Three independent implementations. One open specification. No single owner. |
|
Title: ERDL Decision Object v1.2 RFC — Cross-Implementation Verification Request Body: @eriknewton @chris — We are seeking your review and independent verification of ERDL Decision Object v1.2. Background: The v1.1 independent audit revealed two architectural issues — c3f22df (em-dash whitespace fix causing audit.hash mismatches) and the expected_sha256 structural risk (pre-computed answer keys enabling "shortcut" validators). Both point to the same conclusion: v1.1's flat hashing structure is insufficient for 10-year production auditability. A breaking upgrade is necessary. What changed in v1.2: Hierarchical hashing (CORE×JURISDICTION in main JCS, extensions protected indirectly via extensions_hash) We need your help again: Review the whitepaper and provide feedback on architecture, compliance model, and long-term maintainability Whitepaper (Chinese): https://github.com/OpenOBA/erdl-vectors/blob/master/docs/WHITEPAPER-v1.2-DRAFT-3.md @eriknewton — If you'd like a copy of the whitepaper via email as well, please leave your address and we'll send it over. v1.2 is not a rewrite of v1.1 — your audit findings and independent verification directly shaped this architecture. We would not be here without your work. Looking forward to your feedback. |
|
Congrats on publishing the white paper. Happy to take the audit-hash set. I will run AV-001 through AV-012 against Concordia's independent canonicalizer under the full method, recomputing from first principles and comparing each artifact to its own claimed audit.hash rather than to any field in the vector file. I will post the per-vector result here either way. On the whitepaper: I do want to read it properly and I will, but the next two weeks are very busy, so I would rather tell you that now than go quiet on you. Better a verification you can trust soon than an opinion that arrives late. No need to email anything, I'll pull the draft from the repo. |
|
Started on this, and hit a snag straight away: all four links 404 for me, signed in and signed out, and OpenOBA/erdl-vectors does not resolve as a public repo. The org shows only erdl-landing and erdl-mcp-server. I suspect it is still private. My side is ready. The runner is written and re-validated against the published v1.1 set: AV-001 through AV-007 pass and AV-008 correctly fails as the stale canary. It recomputes from first principles and compares against each artifact's own claimed audit.hash, so if a future set carries a precomputed digest field the runner never reads it. Flip the repo public, or point me at wherever the v1.2 vectors actually live, and I will run AV-001 through AV-012 and post the per-vector result here. |
|
Erik — Repo is public now: github.com/OpenOBA/erdl-vectors A quick heads-up on the architecture: after multiple rounds of review and a third-party security audit, we landed on a flat hashing model. extensions participates directly in the main JCS tree — no separate extensions_hash, no hierarchical layers. This means the five-step verification you described (recompute from first principles, compare each artifact to its own claimed audit.hash) is exactly the right approach. Some earlier discussion threads referenced a layered model — please disregard those; the flat model is final. What you'll find in the repo: Vector file: decision-object-vectors-v1.2.json (root). 63 static DO vectors + 26 dynamic (temporal/seeded/stateful) + 12 audit hash vectors. AV-001 through AV-012 each carry their own decision_object with a claimed audit.hash. — Tang Haoran |
|
AV-001 through AV-012, verified with Concordia's independent RFC 8785 canonicalizer: eleven verify byte-perfect against each artifact's own claimed Three notes, in the order I would act on them. 1. The preimage rule in the whitepaper does not reproduce your own vectors. Section 13.3 says "DELETE audit.hash + DELETE signature + DELETE signing_key_id". The Runner's Guide and 2. Removing the whole 3. On Happy to share the runner. |
|
Erik, Thank you for the clean verification result — eleven byte-perfect matches out of twelve is exactly what we hoped to see. And thank you for the three notes; all three drove concrete fixes in v1.3 DRAFT-4, now published as RFC 001 (OPENOBA-DOBJ-RFC-001). E1 — Preimage rule mismatch. You were right. Section 13.3 now reads "DELETE audit.hash, DELETE signature, DELETE signing_key_id" and explicitly states that audit.previous_hash and audit.commitment MUST stay in the JCS preimage. The Runner's Guide and verify.js were updated to match. Anyone starting from the spec alone will now reproduce the published vectors on the first attempt. E2 — previous_hash and commitment excluded from digest. This was a regression introduced during a refactor between v1.1 and v1.2. v1.3 restores the v1.1 design: only audit.hash is deleted — previous_hash and commitment participate in JCS, so chain position tampering is now cryptographically detectable. We replaced the old stale-regression canary (AV-008) with a new chain-position-tampering canary (AV-013): the DO body carries a previous_hash pointing outside the chain, but the stored audit.hash was computed with the correct previous_hash. A correct runner detects the mismatch; a runner that excludes previous_hash from JCS falsely reports MATCH. We verified this across five implementation modes — all produce the expected result. E3 — canonical_hex shortcut attack. canonical_hex has been removed from the static DO vectors entirely. It now lives in a separate decision-object-answers-v1.3.json file. Section 13.6 now states: "Conformance runners MUST NOT read the answers file." A runner that skips JCS implementation would need to read the answers file to cheat, and CI/CD pipelines can simply make that file inaccessible. What changed in the repo: RFC 001 (replacing the whitepaper): OPENOBA-DOBJ-RFC-001 — 14 regulatory frameworks, threat model appendix, measured performance benchmarks, SMB minimal deployment path —Tang Haoran |
|
Chris, I wanted to update you on the ERDL Decision Object v1.3 release and ensure you know how much your work shaped this iteration. Every finding you reported — C1 through C4, S1 through S3 — has been addressed in RFC 001 (OPENOBA-DOBJ-RFC-001), published today: C1 (self-referencing exclusion): Confirmed correct. policies[].hash and profile_hash self-exclusion is documented in §3.2 with explicit JCS-before-hashing convention. The repo is at https://github.com/OpenOBA/erdl-vectors. Erik Newton has also completed his re-verification pass with eleven byte-perfect matches out of twelve, and his three findings (E1–E3) are likewise fully addressed. You set a high bar with your review, and the protocol is measurably stronger for it. Thank you — genuinely. —Tang Haoran |
|
Re-ran against v1.3 at One note on AV-013: as published it cannot produce the false MATCH it is designed to catch. Its stored |
|
Erik, Let me start with an apology — this AV-013 issue should have been caught and fixed before you spent your time on it. Having you invest additional effort debugging something we should have gotten right is not the standard of collaboration we aim for. We will do better next time. You were right about AV-013. Fixed at d602844. The stored hash was set to a value that no implementation naturally produces, so all runners reported MISMATCH and the canary could not discriminate. Corrected per your prescription: stored hash now equals the digest a regressed runner would compute over the tampered body. Correct runner (includes previous_hash in JCS preimage): MISMATCH Our reverse-test suite now covers this explicitly: four buggy JCS implementations (no-sort, delete-entire-audit, and combinations) cross-validated against sampled DOs and AVs. 157 tests, all green. The fixes from your original three notes are unchanged: E1: preimage rule spec-code alignment — holds the strong way —Tang Haoran |
|
Re-verified at |
|
Erik, Thank you — both for the thorough re-verification and for the generous framing. "The collaboration standard working, not failing" is exactly how we see it. Hearing that v1.3 is the strongest of the three — implementable from the spec text alone, chain position covered, canary proven — means a lot. That was the design intent from the start, and having it validated by an independent runner who never read the answers file is the best confirmation we could ask for. The canary catching a regressed runner that deletes the entire audit object is a perfect demonstration of why AV-013 exists. Differential vectors that discriminate against specific failure modes are worth their weight. Looking forward to the next round — and to seeing where we can push this together. Best, |
|
Haoran, thank you for the generous note, and congratulations on the v1.3 turnaround. Correcting a canary within six hours of a report is rare, and the way you handled the AV-003 through AV-005 drift set the tone for the whole thread. Two follow-ups, both in the same spirit as the vectors. On the reference implementation: the Quick Start clone target and the engine repository both return 404 for me, and I cannot find Rulsynor published anywhere. Neutrality is measured across implementations, so if the Concordia runner is currently the only one a reader can execute independently, the README would be stronger for saying that plainly rather than leaving a second implementation to be inferred. On wording: "agents cannot bypass it" is stronger than an in-process evaluator can demonstrate. Mediating every call that arrives is a real and useful property, and claiming exactly that will hold up better under adversarial review. Erik |
|
Haoran, thank you. The README and SPEC §12 changes will make the current state exactly checkable, and yes to the pre-release cross-verification of rulsynor, same protocol as the vectors: implemented from the spec text alone, no answers file. One note in the same spirit: I could not locate commit 4770ca8 in any of the public OpenOBA repositories, so I cannot re-verify the new mediation wording yet. Once it is publicly visible I will re-run the check. And a small request on attribution: when these results travel, the durable form is the measurement rather than the adjective. "Concordia reproduced twelve of thirteen byte-perfect under an independent canonicalizer, with the canary discriminating as designed" is checkable by anyone; a quoted opinion is not. Erik |
|
Erik, Both commits are now public — 4770ca8 on erdl-landing and 6e6d3e2 on erdl-vectors. You should be able to verify the new wording. Measurement noted and adopted: "Concordia reproduced twelve of thirteen byte-perfect under an independent canonicalizer, with the canary discriminating as designed." That is how it will read when it travels. On a related note: the 404 and outdated README you ran into reflect something we have not yet formalized — a neutrality governance policy that keeps the specification, reference implementation, and public-facing documentation in lockstep. Our operations team is working on this, and we are actively reaching out to more potential independent runners. If you have thoughts on what a neutrality policy framework should look like, we would be glad to hear them. I will follow up with the README/§12 updates and the rulsynor pre-release build. Tang Haoran |
|
Haoran, one thought from having just rebuilt our own version of this. We found our repo failed several checks we would have applied to anyone else, fixed those, and replaced the policy idea with generated, checkable artifacts. docs/CONFORMANCE.md is produced from a claims manifest where each claim is bound to an executable check that runs in CI, including a clean-room job that verifies the interop fixtures with Concordia uninstalled. And conformance/ now carries 236 implementation-agnostic vectors (11 positive, 222 mutations, 3 canaries that catch regressed runners) with a runner contract (conformance/RUNNER_CONTRACT.md) implementable from an RFC 8785 library, Ed25519, and JSON Schema alone. A policy promises future conduct. A generated document describes present, checked state. For ERDL the ingredients already exist: in-repo vectors, spec-implementable, no answers file. |
|
Haoran, following up on the runner-contract pointer above: coverage is now complete across every signed record type the reference SDK emits (over 1,500 vectors, all expected outcomes executed at generation time, canaries included). If you want to point rulsynor at it, the runner contract is implementable from its own text with an RFC 8785 library, Ed25519, and a JSON Schema validator; the reference runner refuses to run if our SDK is importable, so any result you get is independent by construction. Same protocol you offered us on the vector set: implemented from the contract alone, no answers file. Independent results are recorded in conformance/IMPLEMENTATIONS.md with method and date, as measurements; the registry confers nothing and records exactly what was measured. |
|
Erik, This is brilliant — exactly the nudge we needed. Maintaining the repo has been our biggest headache, especially keeping a pile of documentation aligned and consistent — that's honestly a weak spot for us. Your approach — "a generated conformance artifact describes what you have done, and proves it on every CI run" — solves this problem outright. No ambiguity. We have the raw ingredients already — the v1.3 vectors, the implementer's guide (which is de facto a runner contract), the no-answers-file design that Concordia already validated end-to-end. What's missing is the generator that turns CI output into a checked-in CONFORMANCE.md, and an IMPLEMENTATIONS.md registry that measures without conferring. We'll follow your lead on both — and on the clean-room job that verifies with the reference SDK uninstalled. Thank you for building this pattern and proving it works at 1,500-vector scale. It's the right architecture for spec neutrality, and we'll adopt it. Haoran |
|
@haoran-tang-ch Glad the generated-artifact pattern fits. If you sequence it, the clean-room job with the SDK uninstalled is the piece I would land first: it is the one that catches hidden SDK dependence, and the rest composes on top. |
|
Erik， Thank you for pushing this direction — it's been genuinely helpful. The generated-artifact pattern solves a problem we've been wrestling with: how to keep documentation, conformance, and implementation in lockstep without ambiguity. We've been doing heavy infrastructure work on our side, and your timing is perfect. Here's where we're landing: Clean-room job first, as you recommended. The design: Runner Contract: Our implementer's guide (IMPLEMENTERS-GUIDE.md) serves as the de facto contract. Three dependencies: RFC 8785 (JCS), SHA-256, and JSON. Zero SDK. Clean-Room Job: GitHub Actions workflow. First step asserts the reference SDK is not importable (hard fail if it is). Then a pure crypto-module verifier implements JCS canonicalization and SHA-256 hashing from spec alone, runs against all 101 v1.3 vectors, and compares byte-for-byte with the answers file. Generated Conformance Artifact: CI auto-generates conformance/CONFORMANCE.md on every run and checks it into the repo. IMPLEMENTATIONS.md is a measurements-only registry — "who passed how many vectors on what date", no endorsement. The existing SDK-side regression (101/101 vectors) keeps running on every commit. The clean-room job runs alongside it, SDK-uninstalled. Any divergence between the two is a hidden-dependency signal — exactly the property you described. Concordia's results (13/13, v1.3, all byte-identical) sit in the same registry. Two independent implementors, same bytes, same contract. That's the proof. Thanks again for building this pattern and proving it at scale. We'll follow your lead. Haoran |
|
@haoran-tang-ch One detail worth pinning before this ships: as described, the clean-room verifier compares its recomputation against the answers file. That is the reproduction check. The July lesson was that a runner can pass that oracle while never checking each artifact's own claimed |
|
@erik-newton Good catch, and thank you for pinning this before ship. A few clarifications on our current state after your feedback: Our verify.js has always done Check 1 (audit.hash self-consistency). The five-step JCS+SHA-256 verification recomputes the hash from scratch and compares against the artifact's own audit.hash — this is the deployment-scenario verification you described. So the gap wasn't that we were only comparing against the answers file; it was that we weren't doing the reverse cross-check. What we added based on your feedback: Check 2 (answers file cross-comparison). The clean-room now runs both: Check 1: recomputed JCS+SHA-256 hash vs artifact's claimed audit.hash (63/63 DO + 11/11 AV MATCH) AV-013 under dual verification: Check 1: MISMATCH ✓ (correct runner's hash ≠ regressed stored hash — canary active) Changes are live in erdl-vectors@1a86b4d and the CI workflow now runs dual verification on every push. Spec and runner's guide updated accordingly. Thoughts? |
|
@haoran-tang-ch Dual verification is the right landing point. I would make RUNNER_CONTRACT.md the normative behavior spec: what a conforming runner recomputes, which fields are excluded from the preimage, and which failures must surface. Keep the answers file and canonical bytes as diagnostic proof: a useful byte-level oracle, separate from the rule being tested. That gives you both properties: a human-readable contract an independent implementation can follow from first principles, and an oracle that catches byte drift. The acceptance test I would pin is AV-013: evaluated against the claimed contract with the reference runner absent, it still discriminates. |
|
@erik On the split. RUNNER_CONTRACT.md as the normative behavior spec + answers file as diagnostic oracle — this is the right structure. The content already exists in RUNNERS-GUIDE.md, just written in tutorial form rather than RFC 2119 language. Extracting the MUST/SHOULD/MAY clauses into a standalone contract is the right move. It gives future runners exactly what they need without reading 400 lines of tutorial first. On AV-013 as the pin. Fully agree. The acceptance test is: can a runner that only reads RUNNER_CONTRACT.md (no reference code, no answers file) correctly produce a MISMATCH on AV-013? That's the bar. AV-013 already does this — just needs the contract to make it explicit. On why this matters beyond documentation. This isn't a file reorganization. It's the difference between "compatible with OpenOBA's verify.js" and "conformant to an independent, auditable specification." The former makes runner recruitment about trusting our implementation; the latter makes it about implementing a public contract. That matters for the 3rd, 4th, Nth runner — and for enterprise compliance teams who need a spec they can hand to their own auditors. I'll draft RUNNER_CONTRACT.md from the existing RUNNERS-GUIDE.md content and share it for review. Should land within a few days. |
Uh oh!
There was an error while loading. Please reload this page.
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.All reactions