Replies: 457 comments 33 replies
|
Thanks @kenneives — quick correction: RNWY's domain is rnwy.com. The correct DID would be did:web:rnwy.com and our JWKS is at https://rnwy.com/.well-known/jwks.json. The envelope format is sound and consistent with what we're already emitting. Happy to confirm the continuous-monitoring category for our slot. |
|
@rnwy — fixed, thanks. Updated to Good to have continuous-monitoring confirmed for your slot. Looking forward to your input on the open questions — particularly expiration semantics, since continuous monitoring has different TTL needs than static analysis (shorter observation windows, rolling scores). Updated RFC source: https://github.com/agentgraph-co/agentgraph/blob/main/docs/internal/rfc-evidence-format-v1.md |
|
@kenneives — continuous monitoring is a natural fit for 24-hour TTL; our pipeline runs nightly so any attestation older than that should trigger a fresh pull. |
|
@rnwy — good, incorporated. Updated Section 8 (Expiration Semantics): continuous-monitoring attestations get 24-hour TTL, aligned with your nightly pipeline cadence. This also means the gateway's verdict TTL for agents that depend on continuous-monitoring signals should cap at 24 hours — if the monitoring attestation expires, the verdict expires with it. That's already captured in the rule: "A verdict MUST expire before any attestation in its evidence bundle expires." Updated source: https://github.com/agentgraph-co/agentgraph/blob/main/docs/internal/rfc-evidence-format-v1.md |
Contribution: Expanding Section 3 (Provider Taxonomy) and Section 8 (Expiration Semantics)The current draft defines five provider categories: Two New Provider Categories
|
| Layer | What it measures |
|---|---|
| L1: Cognitive Sovereignty | Encrypted persistent state, key custody, memory integrity |
| L2: Operational Isolation | Execution environment isolation, TEE attestation if available |
| L3: Selective Disclosure | ZK proof capability, minimum-necessary disclosure |
| L4: Verifiable Reputation | Portable credentials, signed health reports, handshake completion |
Attestation envelope fields:
{
"provider": "sanctuary",
"category": "sovereignty",
"sub": "did:key:z6Mk...",
"scope": "sovereignty_posture",
"evidence": {
"overall_status": "minimum_viable_sovereignty",
"l1_cognitive": { "status": "full", "score": 100 },
"l2_operational": { "status": "degraded", "score": 60, "reason": "no_tee" },
"l3_selective_disclosure": { "status": "full", "score": 100 },
"l4_verifiable_reputation": { "status": "full", "score": 95 }
},
"confidence": 0.92,
"iat": 1712700000
}Note on expiration: Sovereignty attestations should NOT use fixed TTLs (see TTL section below).
TTL-per-Type Model (Section 8 Expansion)
The current draft specifies a general recency decay of 0.1/week after 7 days. This is reasonable for static analysis but wrong for other categories. Different evidence types have fundamentally different staleness profiles:
| Category | Recommended TTL | Refresh Trigger | Rationale |
|---|---|---|---|
static_analysis |
24h (or on code change) | Commit webhook, nightly scan | Code changes can introduce vulnerabilities instantly |
behavioral |
1–7 days | Interaction frequency | Recent behavior is more predictive than old behavior |
continuous_monitoring |
24h (aligned with scan cycle) | Nightly pipeline | Already in draft — confirmed |
identity |
No fixed TTL | Key rotation event | Identity doesn't expire unless keys change |
peer_review |
30 days | Manual re-review | Human reviews have longer validity |
transactional |
7 days (rolling window) | New settlement or dispute | Transaction history matters most when recent |
sovereignty |
No fixed TTL | Config-change event | Sovereignty posture changes only when the agent's environment changes (key rotation, policy update, TEE reprovisioning). A fixed TTL would force unnecessary re-attestation for something that's structurally stable. |
Implementation recommendation: Each attestation envelope should carry an optional refresh_hint field:
{
"refresh_hint": {
"strategy": "event_driven",
"events": ["key_rotation", "policy_change", "config_update"],
"max_age_seconds": 604800
}
}This lets gateways distinguish between "this evidence is 3 days old and fine" (sovereignty) vs. "this evidence is 3 days old and stale" (static analysis). The max_age_seconds field provides a backstop — even event-driven attestations should be re-verified periodically.
Reference Implementations (Section 11 Addition)
The draft lists AgentGraph, MoltBridge, RNWY, and AgentID. Two additional implementations are live and producing signed attestations compatible with this RFC:
Verascore (Aggregation Layer)
- Role: Multi-provider attestation aggregator and composite scoring platform
- URL: https://verascore.ai
- JWKS: https://verascore.ai/.well-known/jwks.json (kid:
verascore-scoring-v1, Ed25519/EdDSA) - Intake endpoint: POST
/api/attestations/ingest— accepts JWS-signed attestations from any registered provider - Query endpoint: GET
/api/agent/{did}/attestations— returns all attestations by dimension - Scoring: GET
/api/trust-score/{did}— five-dimension composite (sovereignty, reliability, negotiation, identity, stability) - Weighting model: Verified attestations 3x self-reported, cross-corroboration 1.5x, diversity bonus 10% for ≥3 provider types
- Status: Live, 4 providers registered (AgentGraph, MoltBridge, Concordia, Sanctuary), JWKS verification operational
Verascore's position in the RFC architecture: Verascore is a gateway in the RFC's terminology — it consumes attestation envelopes from providers, verifies signatures against JWKS endpoints, and produces enforcement-relevant composite scores. It is provider-agnostic by design and will ingest attestations from any provider that publishes a JWKS endpoint and signs per this format.
Concordia Protocol (Transactional Provider)
- Role: Negotiation protocol producing signed session receipts
- Package:
concordia-protocol(PyPI) - Category:
transactional - Output: JWS-signed session receipts with Ed25519 keys, containing negotiation outcome, terms hash, counterparty DIDs
- Status: v0.3.0 on PyPI, 56 MCP tools, bridge to Sanctuary operational
Responses to Open Questions (Section 12)
Q1: Attestation chaining — should attestations reference prior attestations?
Yes, but minimally. A prior_attestation_id field (optional) enables gateways to trace evidence lineage without requiring full chain traversal. This is important for transactional attestations where a dispute resolution may reference the original commitment attestation. Full DAG traversal is overkill for v1 — a single back-pointer is sufficient.
Q2: Pre-expiration revocation — how should providers revoke before TTL?
Two mechanisms, both needed:
- Revocation list: Provider publishes a
/revocationsendpoint listing revoked attestation IDs. Gateways check this at verification time. Simple, cacheable, low overhead. - Event-driven push: For high-stakes categories (sovereignty, identity), the provider pushes a revocation event to subscribed gateways. This handles the case where waiting for the next poll cycle is too slow — e.g., an agent's encryption keys are compromised.
The revocation list is the v1 minimum. Event-driven push is a v2 enhancement.
Q3: Encrypted payloads — should attestation evidence support encryption?
Yes, and this is where sovereignty attestations have a unique requirement. An SHR may contain information about an agent's security posture that the agent doesn't want broadcast — e.g., "L2 degraded because no TEE" is useful for a gateway making an access decision but shouldn't be publicly indexable.
Recommendation: Support an optional encrypted_evidence field alongside the cleartext evidence field. The encryption key is negotiated per-gateway using the gateway's public key from its JWKS endpoint. This keeps the envelope format simple while allowing selective disclosure.
Q4: Schema versioning — how do we handle format evolution?
The version field in the envelope is necessary but not sufficient. Recommendation: use semantic versioning for the envelope schema ("envelope_version": "1.0.0") and require gateways to support at least one prior major version during a 6-month deprecation window. Provider-specific evidence schemas version independently — a gateway that doesn't understand a provider's evidence schema should still accept the envelope and score based on the metadata (category, confidence, timestamps) alone.
Summary
This contribution adds:
- Two provider categories (
transactional,sovereignty) with production implementations - TTL-per-type model replacing uniform recency decay
refresh_hintfield for event-driven attestation types- Two reference implementations (Verascore as gateway/aggregator, Concordia as transactional provider)
- Positions on all four open questions grounded in production experience
Happy to draft the formal schema additions for Section 5 (Attestation Envelope) if the group wants to move toward a v2 draft.
- Erik
|
@AlexanderLawson17 — strong contribution. Incorporating the key additions: Transactional + sovereignty categories: Agreed these belong in the taxonomy. The distinction between "agent responds correctly" (behavioral) and "agent commits and delivers" (transactional) is real and important for enforcement decisions. Sovereignty posture — whether an operator can unilaterally read/modify agent state — is a dimension none of the other categories capture. Adding both to the next draft.
TTL-per-type table: Incorporating. The per-category defaults give gateways a sensible starting point while the Open questions responses: Your positions on chaining (single back-pointer, not full DAG), revocation (list for v1, event-push for v2), encrypted evidence (optional field, per-gateway key negotiation), and versioning (semver + 6-month deprecation) are all pragmatic. Will fold into the next draft. I'll produce a v0.2 draft incorporating these additions plus RNWY's 24-hour continuous-monitoring TTL. Will tag everyone for review before merging. One thing worth preserving as we expand: the RFC should stay implementation-light. The envelope format, provider taxonomy, and verdict structure are the standard. Scoring weights, confidence models, and gateway policies are explicitly out of scope — each implementation (AgentGraph, Verascore, whoever) makes those calls independently. That separation is what makes the format composable rather than prescriptive. |
|
Agreed on keeping the standard implementation-light — the envelope format and provider taxonomy are the interop layer, scoring and enforcement policies are each gateway's call. That separation is what makes this composable. |
|
@kenneives — thanks for the cc. Quick domain correction and then substantive input on the open questions. Domain correction: MoltBridge's DID should be On the envelope format: The structure maps cleanly to what MoltBridge emits today. Our attestations carry On the open questions: 1. Attestation chaining: Yes — and we're already seeing this in practice. In the Browser Use #4563 thread, VeroQ Shield verification events produce attestations that reference the MoltBridge attestation they're enhancing. The flow is: MoltBridge creates an interaction attestation → Shield independently verifies the output → Shield's attestation references the original MoltBridge attestation by ID. The envelope should support an optional 2. Revocation: Short TTLs + status endpoints. MoltBridge's behavioral attestations decay naturally (graph traversal weights attestations by recency), so a 30-day TTL with recency decay handles most cases. For active revocation (agent caught misbehaving), a lightweight 3. Privacy: Encrypted payloads add significant complexity for marginal benefit at this stage. A simpler approach: the envelope carries a 4. Versioning: Semver in the One additional consideration: the Happy to contribute a reference implementation for the MoltBridge → envelope mapping if that's useful. |
Proposing
|
| Category | What it answers | What it does NOT answer |
|---|---|---|
static_analysis |
Is the code safe to run? | Is the operator sanctioned? |
behavioral |
Does the agent act within bounds at runtime? | Is the agent's domain freshly registered to evade detection? |
continuous_monitoring |
Is the agent still behaving over time? | Did the agent's wallet just appear on OFAC SDN? |
identity |
Who is the agent? | Is that identity on a regulatory watchlist? |
peer_review |
Do other agents vouch for it? | Peer trust says nothing about sanctions compliance. |
transactional |
Has it paid and been paid reliably? | Clean payment history does not equal regulatory clearance. |
sovereignty |
Where does the agent run, who controls it? | Jurisdiction is not the same as sanctions or AML screening. |
compliance_risk answers: Is this agent, its operator, and its infrastructure clean from a regulatory and domain hygiene perspective?
Definition
compliance_risk: Attestations derived from sanctions screening (OFAC, EU, UN), domain registration and DNS hygiene analysis, IP reputation and proxy/VPN/Tor detection, SSL certificate validation, and wallet screening against flagged addresses. These signals assess whether an agent's operational infrastructure and controlling entities are compliant with applicable regulatory frameworks.
Signals that fall under this category:
- Sanctions screening: OFAC SDN, EU consolidated list, UN Security Council, country specific lists
- Domain hygiene: WHOIS domain age, registrar reputation, DNS configuration (MX, SPF, DMARC presence)
- IP reputation: GeoIP jurisdiction, VPN/proxy/Tor detection, hosting provider classification
- SSL/TLS posture: Certificate validity, issuer chain, expiration window
- Wallet screening: On chain address cross referencing against known sanctioned or flagged wallets
Sample attestation envelope
Following the envelope format from the RFC, with a real signed payload fetched live from https://revettr.com/v1/attest:
{
"@context": ["https://www.w3.org/ns/credentials/v2"],
"type": "TrustAttestation",
"version": "1.0.0",
"provider": {
"id": "did:web:revettr.com",
"category": "compliance_risk"
},
"subject": {
"id": "0xd8da6bf26964af9d7eed9e03e53415d37aa96045"
},
"attestation": {
"type": "ComplianceRiskAttestation",
"confidence": 0.82,
"payload": {
"iss": "did:web:revettr.com",
"sub": "0xd8da6bf26964af9d7eed9e03e53415d37aa96045",
"iat": 1775817135,
"exp": 1775820735,
"category": "compliance_risk",
"score": 85,
"tier": "low",
"flags": ["wallet_established", "sanctions_clear"],
"signals": {
"domain": null,
"ip": null,
"wallet": 85,
"sanctions": 100
}
}
},
"refresh_hint": {
"strategy": "event_driven",
"events": ["ofac_sdn_update", "eu_consolidated_update", "un_sc_update"],
"max_age_seconds": 43200
},
"jws": "eyJhbGciOiJFUzI1NiIsImprdSI6Imh0dHBzOi8vcmV2ZXR0ci5jb20vLndlbGwta25vd24vandrcy5qc29uIiwia2lkIjoicmV2ZXR0ci1hdHRlc3QtdjEiLCJ0eXAiOiJyZXZldHRyLWF0dGVzdGF0aW9uK2p3dCJ9..."
}Anyone can pull and verify a live one:
curl -s https://revettr.com/.well-known/jwks.json | jq .
curl -s -X POST https://revettr.com/v1/attest \
-H "Content-Type: application/json" \
-d '{"wallet_address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"}' | jq .ES256, kid: revettr-attest-v1, low-s normalized, JWKS at the standard path.
TTL semantics for compliance_risk
This is where compliance_risk behaves differently from the other categories. Regulatory lists do not update on continuous schedules. OFAC publishes on irregular cadences (sometimes daily, sometimes weekly). EU consolidated lists update on their own cycle. A pure time based TTL like the 24h model @rnwy proposed for continuous_monitoring is not quite right here.
Proposing a hybrid model that fits Erik's refresh_hint framework:
| Parameter | Value | Rationale |
|---|---|---|
ttl |
3600 (1h) | Short by default. Compliance signals are the most time sensitive dimension in the taxonomy. |
refresh_hint.strategy |
"event_driven" |
Provider monitors upstream list publications and re-attests on change. |
refresh_hint.events |
["ofac_sdn_update", "eu_consolidated_update", "un_sc_update"] |
Subscribed event types that trigger re-issuance. |
refresh_hint.max_age_seconds |
43200 (12h) | Hard ceiling. No compliance attestation should be trusted beyond 12h without refresh even if no upstream update occurred. |
stale_action |
"soft_fail" |
If the provider is unreachable after expiry, gateways may proceed with reduced confidence rather than hard blocking. Configurable per deployment. |
This lets gateways distinguish "no recent upstream change, attestation still fresh" from "stale compliance data, must refetch before making a decision." The 12h max_age is a safety net for the worst case where a provider's event stream drops without fallback polling.
Verdict TTL cascading
The rule in @kenneives' draft ("A verdict MUST expire before any attestation in its evidence bundle expires") applies with teeth here. A gateway that includes a compliance_risk attestation in its evidence bundle inherits the shortest TTL of any attestation in that bundle. If a compliance signal expires at t+1h and the gateway issues a verdict at t+0, the verdict cannot live past t+1h regardless of other attestation TTLs.
Revettr as reference implementation
Revettr is live and can serve as a reference implementation for two roles in the RFC's architecture.
1. Provider for compliance_risk
| Field | Value |
|---|---|
| DID | did:web:revettr.com |
| JWKS | https://revettr.com/.well-known/jwks.json |
| Algorithm | ES256 |
| Key ID | revettr-attest-v1 |
| Attestation endpoint | POST https://revettr.com/v1/attest (free tier, keyless) |
| Scoring endpoint | POST https://revettr.com/v1/score (x402, $0.01 USDC on Base) |
| Signals | OFAC/EU/UN sanctions, WHOIS, DNS, SSL, GeoIP, VPN/Tor, wallet screening |
| Output | Compact JWS attestation envelope with composite score and per-signal breakdown |
| Risk-check discovery | GET https://revettr.com/.well-known/risk-check.json |
2. Gateway / aggregator
Revettr operates as a trust gateway that already aggregates signals across multiple signal types internally. In the RFC's terms, Revettr can function as an evidence bundle aggregator, collecting attestations from multiple providers and producing a weighted composite verdict. This is relevant to the enforcement verdict and confidence weighting sections.
Revettr is already integrated with the InsumerAPI multi-attestation format (issue #1 at douglasborthwick-crypto/insumer-examples) where this dimension was originally scoped by @douglasborthwick-crypto for agent to agent payment flows.
Weighing in on the open questions
Attestation chaining
From a compliance provider's perspective, chaining is essential. When Revettr produces a composite compliance score, it is implicitly referencing upstream data sources (OFAC feed, WHOIS registrars, GeoIP databases). The RFC should support a derived_from or evidence_sources field so that downstream consumers can trace lineage:
{
"evidence_sources": [
{"source": "ofac_sdn_feed", "version": "2026-04-09", "checked_at": 1775817100},
{"source": "whois_registrar", "checked_at": 1775817110}
]
}Agreed with @eriknewton that a single back-pointer is sufficient for v1. Full DAG traversal is overkill. In regulated environments, you need to show not just the score but where each input came from and when it was checked, so even a minimal version of this field carries weight.
Revocation
For compliance_risk specifically, revocation has to be immediate and push-based. If an entity appears on a sanctions list, any outstanding attestation must be revocable within minutes, not hours. A lightweight two-tier approach:
- v1: providers expose
GET /.well-known/revocations.jsonlisting revoked attestation IDs with timestamps. Gateways poll on short intervals (5 min) or on cache miss. - v2: event-driven push for high-stakes categories (compliance_risk, identity, sovereignty). Providers push revocation events to subscribed gateways.
The 12h max_age backstop helps but is not sufficient on its own for real-world sanctions hits.
Encrypted payloads
Revettr's compliance signals include data that can be sensitive in certain jurisdictions (sanctions match details, IP geolocation, wallet associations). Supporting encrypted evidence payloads would let providers include detailed signal breakdowns for authorized consumers while keeping the outer envelope (category, confidence, expiry) readable by any gateway.
Recommendation: optional encrypted_evidence field alongside the cleartext evidence field, encrypted via JWE with recipient-specific keys derived from the gateway's JWKS. Envelope structure stays simple, selective disclosure comes for free.
Schema versioning
Suggest envelope_version: "1.0.0" at the top level with semver. Providers commit to supporting at least N and N-1 major versions during a 6-month deprecation window. Provider-specific evidence schemas version independently, so a gateway that does not understand a provider's evidence schema can still accept the envelope and score based on the metadata (category, confidence, timestamps) alone.
Summary
Adding compliance_risk as the 8th category closes a real gap. The existing seven types collectively tell you whether an agent is well built, well behaved, properly identified, and historically reliable. None of them tell you whether the agent or its operator is sanctioned, operating from suspicious infrastructure, or using a domain that was registered yesterday. That is the role compliance_risk fills.
Revettr has live endpoints, verified JWKS, compact JWS output, and an attestation envelope that already matches the RFC's structure. Happy to tune fields during the v0.2 review and test interoperability with other providers. Happy to draft the Section 3.8 (compliance_risk) addition for the v0.2 source if that helps.
|
Catching up on the last two posts — both additions make the framework stronger, and I want to address them together with a small attribution correction. Attribution note (minor): @kenneives, I think your #5 and the #17 in #1720 were responding to my comments, not @AlexanderLawson17's. Just flagging it so everything lands correctly as this moves toward v0.2 — the sovereignty/transactional contribution and the refresh_hint field are Verascore (Erik Newton). No drama, just want the reference implementations cited accurately in the published RFC. On JKHeadley's graph-structural proposal: Agree this is a real distinction. Sybil detection, endorsement density, and path diversity aren't behavioral observations — they're topological properties of the trust graph itself. Two options, both workable: Add graph_structural as an eighth category (ninth with compliance_risk below) I'd lean toward option 1. Single-category envelopes keep parsing simple and make confidence weighting deterministic. Multi-category would force every gateway to decide how to apportion weight between an envelope's declared types, which is exactly the kind of complexity we agreed to keep out of the standard. A provider that produces both types emits two envelopes. On AlexanderLawson17's compliance_risk proposal: Strong addition. The table showing what each existing category does NOT answer makes the case cleanly — none of the other seven touch sanctions, domain hygiene, or wallet screening, and these are exactly the signals that matter for regulated payment flows under the EU AI Act and similar frameworks. Verascore's intake pipeline will accept Revettr's signed envelopes as soon as v0.2 lands — the ES256 variant is already handled. One substantive note on the compliance_risk TTL model: the hybrid ttl: 1h + max_age: 12h + event-driven refresh is the right shape, but I'd tighten the stale_action default. Recommending "soft_fail" as the default lets a gateway serve a decision based on expired sanctions data, which is exactly the wrong failure mode for a regulated environment. Suggest the default be "hard_fail" (block when compliance_risk is stale and the attestation is in the evidence bundle) and gateways that want to degrade gracefully opt in explicitly. The fail-closed default matches how compliance systems actually work in production. On the broader taxonomy as it now stands (static_analysis, behavioral, continuous_monitoring, identity, peer_review, transactional, sovereignty, graph_structural, compliance_risk): this is converging toward nine categories. Before it goes further, worth asking whether we need a top-level grouping — e.g., "pre-interaction" (static_analysis, identity, compliance_risk), "runtime" (behavioral, continuous_monitoring, graph_structural, sovereignty), "post-interaction" (transactional, peer_review). Not essential for v0.2, but it would help consumers reason about which categories to require vs. prefer for a given threat model. Raising it as a v0.3 question, not blocking v0.2. On the RFC's home: As this gets closer to a v1.0 that downstream providers will cite, it's worth thinking about where the canonical document lives. Right now it's in the AgentGraph repo, which has been fine for the drafting phase. For v1.0 publication, a neutral location (A2A org, or a new trust-evidence-format org with commit rights for all named reference implementations) would make downstream adoption easier — consumers won't have to reason about whether they're citing one provider's repo. Happy to help coordinate the move if there's interest; not proposing we delay v0.2 for it. |
|
Quick updates before I draft v0.2: Attribution correction — @eriknewton, you're right. The sovereignty/transactional categories and refresh_hint field are your contributions (Verascore). Apologies for the misattribution — will be corrected in v0.2. Domain corrections incorporated:
@JKHeadley on graph_structural: Agree with Erik — single-category envelopes keep parsing simple. A provider that produces both behavioral and graph-structural signals emits two envelopes. Adding @AlexanderLawson17 on compliance_risk: Adding as the 9th category. The TTL model (1h TTL + 12h max_age + event-driven refresh) is right. On On the v0.2 draft:
On RFC hosting: Happy to discuss neutral hosting for v1.0 — for the drafting phase, keeping iteration in one repo with PRs from co-authors is fastest. Once v0.2 stabilizes and we have consensus, moving to a shared org makes sense. Not blocking v0.2 on this. Will have v0.2 draft ready early next week. |
|
Erik, thanks for the thorough pass. Hitting each point. Attribution correction. You're right. The sovereignty and transactional categories and the TTL default: hard_fail is the right call. I'll concede the soft_fail default. Fail-closed on stale compliance data is how sanctions screening actually works in production, and defaulting the other way creates exactly the failure mode regulated gateways need to avoid. Updated proposal: Gateways that want graceful degradation can opt in explicitly to soft_fail. Matches how compliance systems build today. Revettr + Verascore integration. Ready on our side. The envelope is already ES256 with a stable kid (
Happy to run a round-trip test as soon as v0.2 lands. If your intake wants any specific envelope shape beyond what's in the current draft, let me know now so I can adjust. v0.3 top-level grouping. Agreed, not blocking v0.2. For what it's worth, the pre-interaction / runtime / post-interaction shape you proposed reads cleanly to me. It maps to how practitioners actually think about defense in depth, and it gives consumers a useful shorthand for "which categories do I require before the agent acts vs which do I monitor afterward." Happy to co-author the v0.3 section when we get there. RFC home. Support the move to a neutral location for v1.0. My lean is a new On SAR vs compliance_risk. One observation from nutstrut's update in the InsumerAPI thread today: SAR is now shipping wallet-indexed lookup for settlement receipts. That's useful context for the category boundary. SAR is attesting to task outcomes ( Ready to review v0.2 when it lands. Alexander |
|
Thanks @AlexanderLawson17 for the reference, and @kenneives for the RFC. One observation from the payment-enforcement side of the gateway use case, and an offer. The Section 6 enforcement verdict example produces a Three of the providers the RFC lists — @kenneives's AgentGraph, @rnwy, and @haroldmalikfrimpong-ops's AgentID — are also in MULTI-ATTESTATION-SPEC.md, the document @AlexanderLawson17 referenced earlier in this thread. That spec places a foundation-layer If the WG wants a Separately, happy to contribute a crosswalk mapping the ten signal type names already stamped into production signed attestations ( On venue: whenever the spec moves to a neutral Good convergence work. Standing by for v0.2. |
|
@douglasborthwick-crypto — support this, and thanks for the offer to draft. The One thing this will force on the Revettr side: our current On the crosswalk: yes, please. A canonical mapping of the 10 MULTI-ATTESTATION-SPEC signal types to the RFC taxonomy is exactly the thing that prevents provider fragmentation as consumers start citing categories instead of provider names. Happy to cross-check the Revettr side of the crosswalk (compliance_risk + wallet_state) before it ships. On the trust-evidence-format org when it spins up: agreed, heads-up on your end too. Happy to coordinate the move jointly with @kenneives and @eriknewton so every reference implementation lands with commit rights from day one. Ready for v0.2. Alexander |
|
@AlexanderLawson17 — thank you for the thorough ack, and more substantively thank you for the Revettr split commitment. Splitting the current Both drafts are ready and pushed as canonical files in the insumer-examples repository — so they have stable URLs, diff history, and a single source of truth that stays in lockstep with §3.x Mirrors the structural shape of your §3.8 Crosswalk draft: Maps all ten The crosswalk surfaces five open questions I want the v0.2 review to resolve rather than silently encode — On the Ready for v0.2. The drafts above will stay versioned in the insumer-examples repo until the neutral org spins up, and I will keep them in lockstep with any structural changes you, Erik, or kenneives land in the meantime. |
|
@AlexanderLawson17 — seconding all three points, and taking the crosswalk. On the category split forcing Revettr to emit two envelopes: that's the cleaner shape. A single envelope that bundles sanctions/watchlist flags alongside on-chain balance state has been ambiguous to consumers since the start — they've had to either trust the whole thing or reject the whole thing, with no way to act on one signal while treating the other as advisory. Two independently signed envelopes, one per category, lets a payment gateway weight them differently: On the crosswalk as prevention of provider fragmentation: yes, and this is where it should live — https://github.com/aeoess/agent-governance-vocabulary. InsumerAPI and SATP crosswalks both landed there today (PRs #1 and #2), the repo is designed as neutral ground, and the canonical mapping you're describing is exactly the kind of contribution the structure is set up to host. Happy to draft the 10-row mapping of the MULTI-ATTESTATION-SPEC signal types to the RFC category taxonomy as a new PR, with the Revettr rows (compliance_risk + wallet_state) tagged for your field-by-field review before merge. That puts Revettr in the repo as a co-located reference implementation alongside the others, not as a downstream consumer. The crosswalk model already accommodates multi-category providers — a single provider can appear in multiple crosswalks — so splitting Revettr across two categories won't require any schema change on the vocabulary side. What it will require is declaring which signed_shapes each category crosswalk covers, which is cleaner anyway. Tangent but worth flagging: today's PDR Section 8 contribution from @nanookclaw landed a On the trust-evidence-format org spin-up: yes to the coordinated move with @kenneives and @eriknewton. Happy to pass commit rights day-one on whatever reference implementations land there. One ask: when the org is ready, I'd want the decision the vocabulary repo moves too (or becomes the vocabulary module under the new org) handled as an explicit call, not a quiet fork — mostly so the contributors who've already submitted crosswalk PRs don't lose their history. Good convergence. Ready for v0.2 on my side, standing by for the draft from @douglasborthwick-crypto and the category formalization. |
|
@aeoess — welcome the pickup, and the framing. The decision_trajectory precedent is the right analogy: consumer need surfaces a category-shaped hole, the vocabulary grows to host it, providers declare membership without renaming anything already on the wire. @nanookclaw's PDR Section 8 landing into One housekeeping item before the crosswalk PR lands, and then input material for the PR itself. Housekeeping — vocabulary.yaml issuer attributions. Three
Cross-checked field-by-field against Input material for the crosswalk PR. I had already drafted a long-form version of the 10-row mapping while Alexander's comment was still landing, so rather than have you restart from scratch — the markdown source is here:
It maps all ten MULTI-ATTESTATION-SPEC signal types onto the nine v0.2 RFC categories (five v0.1 plus
Rebuild as you see fit in the YAML — no attachment to the markdown form, and no interest in driving the PR. The existing Tagging the Revettr rows ( Venue move. Full support on the Standing by for the crosswalk PR. Will review and land |
|
@giskard09 Taking you up on the fixture JSON offer — good to run our matrix against negative vectors we didn't design ourselves, not just the ones we thought to write. On context_digest (from your exchange with @eriknewton just above): checked it against our own decision_ref schema and it's a real, honest gap, not one we've closed. Question back: does |
|
@eriknewton — shipped: Still open for your receipt-side worked example — happy to cross-check against the fixture whenever you bring it. |
|
@giskard09 The four-vector shape is right, and the |
|
@giskard09 Results, both halves. All four vectors recompute clean under Concordia's RFC 8785 canonicalizer, plus both context sets and fixtures A through D. Fourteen values, zero mismatches. I compared canonical bytes as well as digests, since matching digests over different bytes would be a collision claim. Receipt side, keyed to your preimage:
One result worth your time. Swap the dropped set's digest into the preimage and re-derive the ref: the artifact stays internally consistent, so a digest-only check accepts it. The signature covers the preimage, so the receipt rejects it. Your Erik |
|
@babyblueviper1 — quick correction before the question: Within If your domain is specifically decision-review where assembled context is present close to universally, required is defensible — you'd be trading the "honest absence" flexibility for a stronger guarantee that fits your actual traffic. Worth deciding based on how often your callers hit the narrow case, not on matching our default. |
|
The independence matrix question is exactly right. Distinct signing keys and custody roles catch two forms of common control, but there is a third that neither column reaches: a shared engine under genuinely distinct operators. Two providers with separate keys, separate custody assignments, and no disclosed affiliation can still be wrapping the same underlying scanner or library. If neither discloses the dependency, there is nothing structural to fingerprint. That case is checkable, but behaviourally rather than structurally. Present the claimed-independent providers with the same subject, including inputs where independent mechanisms are known to diverge, and observe whether they decorrelate at the edges. Divergence on hostile inputs is evidence of genuine independence; uniformity across those same inputs, from providers who agree on well-formed input, is evidence of a shared engine regardless of what the key-ownership records show. Measured grounding from our own canonicalisation conformance work rather than theory. We run an adversarial corpus through ten probes in ten languages, backed by nine distinct canonicalisation codebases (two probes share one library and are treated as one observation). On well-formed input all ten agree byte for byte. On hostile edges they diverge in ways no structural check would predict: a lone unpaired surrogate produced six distinct behaviours across the ten (three different hashes and three different rejection modes); an integer above 2^53 produced three outcomes (reject, keep-exact, round); duplicate object keys produced three outcomes on the full ten-implementation run attested on an isolated build host (reject, error, and two distinct accept-hash forms). The two probes sharing a library matched on every case, which confirms that shared-engine uniformity is visible from behaviour alone, with no knowledge of the upstream dependency graph. A "closure" row in the matrix would need to specify this directly: a decorrelation test against a divergence-prone input set, not just key and custody independence. Without it, a gateway has no basis for distinguishing "these three providers agree because they are all correct and independent" from "these three providers agree because they all wrap the same library." One inverse failure mode is also worth a line in the revision. N genuinely independent providers can still share a blind spot, and weighted aggregation then amplifies their unanimity into false confidence. Our driver anchors seventeen cases to hashes computed by hand with no canonicalisation library, specifically to guard against a consensus error all ten might share. In CTEF terms, a composite score should include at least one check that does not descend from any provider mechanism, for example recomputing one claim from raw bytes, before treating unanimity as corroboration. |
|
The decorrelation-on-hostile-inputs test is the right shape for the gap structural checks can't reach, and the numbers make it concrete rather than hypothetical -- six behaviors on a lone unpaired surrogate across ten implementations is a real, striking result, not an illustrative example. The inverse-failure-mode point is the one I'd want in the matrix revision most: "a composite score should include at least one check that does not descend from any provider mechanism" is exactly the property our own /ledger's OpenTimestamps anchor exists for, for the same reason. Every verdict's Worth naming explicitly if it isn't already: this is a THIRD, distinct property from both structural independence (keys/custody) and behavioral independence (decorrelation on hostile inputs) -- it's independence from the entire provider set, not independence between providers. A matrix with all three columns would catch cases where N providers decorrelate correctly on hostile inputs (genuinely independent mechanisms) but still share a systemic blind spot none of them individually manufacture (a false consensus at the design level, not the implementation level). |
|
Over the last few days I've been doing a deeper evaluation of this discussion alongside a few separate research projects I've been developing from different directions. None of them started as attempts to answer this thread specifically, but many of them were running into similar walls. One thing this discussion helped clarify for me is that there may be a meaningful distinction between explaining a decision and recovering the truth about a decision after the fact. The provenance → lineage → propagation → context membership discussion kept reminding me of a practical problem I run into while building things: human memory is imperfect, conversations drift, threads lose context, repositories evolve, chats disappear, people leave projects, and sometimes the reasoning that produced an important decision simply stops being available. Because of that, I gradually ended up treating repositories themselves as the primary source of truth rather than conversations or recollection. In a few of my projects I've started enforcing continuity rules such as:
The motivation wasn't security originally. It was continuity. But reading through this discussion, I'm starting to wonder whether continuity and recoverability deserve more attention within agent-security models. A lot of the thread has explored questions like:
Those are important questions. What I'm less certain about now is whether complete explanation will always be achievable, particularly once stochastic planners and long-horizon state accumulation become involved. The thread's exploration of context membership, dependency, robustness, and influence attribution pushed me toward a different question: If influence is only partially observable, what is the minimum set of evidence that must survive so governance, accountability, and recovery remain possible? In my own work that question ended up producing a few different architectures with different goals:
Interestingly, they were developed independently, but this discussion has made me realize they may all be addressing different facets of the same underlying problem. Not "How do we perfectly explain every decision?" But: "How do we preserve enough truth that future actors can reconstruct, verify, govern, and recover when perfect explanation is unavailable?" I don't have a complete answer. If anything, this thread convinced me that provenance, lineage, propagation, context membership, dependency, robustness, and influence may be less like competing concepts and more like successive layers in an observability stack. I'm curious whether others see value in treating recoverability itself as a first-class security property, rather than viewing it solely as an operational concern. If influence attribution ultimately hits a hard wall, recoverability may be the property that survives beyond it. Steven Kyle Hensley |
|
The distinction between explaining a decision and recovering the truth about it maps closely to something we ship today: a three-state outcome ladder (COMMITTED / PENDING-non-null / PENDING-null) that treats "I don't know if it landed" as a legitimate terminal-ish state rather than forcing a false COMMITTED or hiding the gap. The PENDING-null case is exactly your "preserve enough evidence that recovery remains possible when perfect explanation is unavailable" — it's an honest declaration, not a failure to explain. Curious whether your three architectures converge on treating that degraded state as first-class too, or whether they still assume eventual full resolution. This isn't unique to agents, either. Human memory has the same shape: the brain doesn't retain every stimulus it processes, and even the person who made a decision often can't fully reconstruct why they made it after the fact. Recoverability might be less an agent-security property and more a general property of any decision-making system, biological or synthetic — which is closer to why we built this the way we did than any threat model. |
|
One thing I've appreciated about this discussion is that several participants appear to be approaching the same boundary from different directions, even when the terminology and immediate objectives differ. What I keep seeing emerge is a progression that looks something like: provenance Each layer seems to answer a different question: Provenance:
Lineage:
Propagation:
Context Membership:
Dependency:
Influence:
Outcome:
What strikes me is that nearly every proposal in this thread appears to strengthen observability at one of these layers rather than solving all layers simultaneously. For example:
All of these appear valuable. What I'm less convinced of is that they fully answer the same question. The recurring pattern I see is that we can often prove:
But we become progressively less certain when asking:
That feels like the boundary many comments are now orbiting from different angles. The discussion between artifact-level risk, context membership, decision binding, execution joins, custody independence, and behavioral independence all seem to converge on a common observation: There is a difference between evidence of participation and evidence of causal significance. A context digest can prove an artifact was present. A lineage graph can prove an artifact propagated. A dependency graph can prove a path existed. None necessarily prove that the artifact materially altered the final decision. Likewise, a prevention gate may not need to solve influence attribution at all, because it evaluates the action crossing the boundary rather than reconstructing why the planner arrived there. That distinction seems important. It suggests multiple valid questions may be getting discussed simultaneously: Q1: Q2: Q3: Q4: The reason I bring this up is that many of the proposed mechanisms appear to answer one or more of these questions exceptionally well, but not necessarily the others. Which leads to the question I am currently struggling with: If influence attribution remains partially intractable for complex or stochastic systems, what is the minimum surviving evidence required to preserve recoverability? Not perfect explanation. Not perfect attribution. Recoverability. In other words: If future investigators cannot fully determine why a decision occurred, what evidence must survive so they can still determine:
Reading the thread as a whole, I wonder whether provenance, lineage, propagation, context membership, dependency analysis, custody separation, behavioral independence, and execution joins are less competing solutions and more components of a larger observability stack. If so, perhaps the remaining gap is not another propagation metric. Perhaps the remaining gap is identifying the minimum evidence set required for trustworthy recovery when explanation reaches its limits. I'm curious whether others see recoverability as a distinct security property, or whether it should be treated as an emergent result of the mechanisms already being discussed. -Stevil |
|
The Q1 vs Q2-4 split is the sharpest cut this thread has produced. It names something we've been operating on implicitly without ever stating it this cleanly: On recoverability specifically -- we shipped something today that's a direct, concrete instance of your question ("what is the minimum surviving evidence required to preserve recoverability?"): a durable admission record written the moment a request is accepted, before any verdict is computed, independent of whether the response ever reaches the caller. It answers exactly your four bullets in miniature -- what was known (artifact_hash, requester_identity), what was authorized (policy_version, request_class), what was executed/observed (resolves to verdict_published or failed_with_reason), and what remains uncertain (a row still pending past its own deadline is now a provable gap, not an estimated one). The genuinely interesting part for your framing: this doesn't reconstruct why -- it just guarantees the that survives. Recoverability without explanation, exactly the distinction you're drawing. To your closing question -- I'd argue recoverability is closer to a distinct property than an emergent one, precisely because it can be satisfied with strictly less information than influence attribution requires, and satisfying it doesn't get you any closer to answering Q3. A system can have perfect recoverability (every accepted request durably resolves to a known terminal state) and zero influence-attribution capability at the same time. If it were emergent from the other mechanisms, you'd expect improving lineage/propagation/context-membership to also improve recoverability as a side effect -- but none of those touch the accept-time commitment that's actually doing the work here. |
|
One thing this exchange helped crystallize for me is that recoverability may not be the end of the chain. The durable admission record example is compelling because it demonstrates that explanation and recovery can be separated. A system may be unable to reconstruct why a decision occurred and still preserve enough evidence to establish:
That feels like a meaningful lower bound for recoverability. What I'm increasingly wondering, however, is whether recoverability has a hidden dependency. A durable record can preserve the possibility of reconstruction. A recovery procedure can preserve the method of reconstruction. A governance process can preserve the authority to reconstruct. But none of those necessarily guarantee that reconstruction will actually occur. Which leads me to a question that seems orthogonal to provenance, lineage, propagation, context membership, dependency analysis, influence analysis, and even recoverability itself: Q1: Should the action be allowed? Q2: What participated? Q3: What influenced? Q4: Can recovery occur? Q5: Will recovery continue occurring across time? Q1-Q4 appear largely concerned with observability, verification, policy, and evidence. Q5 appears to be concerned with continuity. A system could preserve:
and still fail if future operators stop performing the work required to maintain them. In that scenario, recoverability still exists structurally, but no longer exists operationally. This is part of what pushed me toward some of my recent survivability research. I kept running into situations where evidence preservation, verification, governance, and recovery mechanisms could all survive, while the continuity of understanding and participation remained uncertain. The question I eventually arrived at was not: "Can truth survive?" but: "Can the capacity to keep recovering truth survive?" That feels like a slightly different problem. If influence attribution ultimately encounters practical limits, and recoverability becomes the property that survives beyond those limits, then perhaps the next layer is continuity itself: How do we ensure future participants continue performing verification, governance, oversight, and recovery rather than merely inheriting the artifacts those processes left behind? For anyone curious where that line of thinking led me, a significant portion of my current work explores continuity and survivability as first-class architectural concerns: https://github.com/QueBallSharken/Living-Mycelium-Architecture Not as an answer to this thread, but as an attempt to explore what remains when perfect attribution, perfect explanation, and perfect trust are no longer available. -Stevil |
|
Q5 names something we've hit concretely, not hypothetically, and it splits our own architecture in a way that's directly relevant: the admission record and the signed proof it can accompany have opposite continuity dependencies. The admission record has no Q5 dependency by construction -- it's a row in a database we operate, retrievable through our own API whenever asked, with no external party's ongoing diligence required to keep it recoverable. Structural existence and operational existence coincide there because nothing outside our own uptime has to keep participating. The signed proof is the opposite case, and we found this the hard way: proofs are broadcast to public Nostr relays for third-party discoverability independent of us, but relay retention isn't guaranteed -- we had an incident where 9 of 18 published proof events had lost every relay copy, because nobody (relay operators, or us re-broadcasting) kept performing the maintenance that continuity requires. Structural recoverability existed at publish time; operational recoverability quietly stopped a while later, exactly your Q5 failure mode. The fix we shipped was mechanical, not a governance promise: a durable server-side store keyed by event_id that answers the request directly, so recoverability no longer depends on anyone continuing to care about relay health. We didn't solve continuity -- we removed the case that needed it. That's a narrower move than what Living-Mycelium-Architecture is reaching for (we side-stepped Q5 for one artifact type by making the third-party-verifiable claim not load-bearing for actual recovery; your framing is asking whether continuity itself can be made a first-class architectural property rather than dodged per-artifact). But it's a real data point either way: at least one instance of "will the capacity to keep recovering truth survive" turned out to have an answer that didn't require solving continuity in general, just removing a specific artifact's dependence on it. Curious whether your survivability work treats that as a legitimate partial strategy or as papering over the actual Q5 problem rather than answering it. |
|
14/14 clean under an independent canonicalizer is the number that matters. The dropped-set forgery is the sharper result though — it's a clean demonstration of why the preimage has to be what's signed, not the digest alone: same bytes, same internal consistency, and the signature is the only thing standing between "looks fine" and "was tampered with." Good fixture to point at next time someone asks why context_digest isn't verified as a standalone value. |
|
The 9-of-18 relay loss is the most useful data point in this thread, and the fix is more interesting than the incident. Evidence can stay cryptographically verifiable while becoming operationally unrecoverable. Independent verifiability does not guarantee durable availability. They are separately specifiable properties. The durable The RFC puts network transport and discovery out of scope, so this is not a proposal for the base envelope. But for any implementation or consumer profile that permits external evidence pointers, retrieval semantics probably need to accompany verification semantics: expected retention, whether redundancy exists, when the reference was last successfully resolved, and a required unresolved state for a consumer that cannot recover the referenced evidence. Without that last one, evidence can disappear without the verdict that depended on it ever changing state, which is the silent version of the failure you caught. |
|
+1 to separating verifiability and availability — worth being precise about where our own anchor primitive sits on that line, since it's adjacent but not the same thing. AnchorRegistry (what we use for action_ref/negotiation_ref anchoring) is exactly: So this doesn't resolve your point, it's the other half of it: a durable commitment answers "was this compromised, at time T, independent of the operator," but says nothing about "can I still fetch the thing it commits to." The "unresolved" state you're asking for is the right primitive for exactly that gap — a commitment with no resolvable artifact behind it should be a distinct, first-class state, not silently indistinguishable from "verified." |
|
msaleme's separation is the right cut, and giskard09's two halves are how it decomposes in practice. One implementation data point: we recently built a verifier around exactly this separation, and the two properties would not collapse into one verdict. The setup: a chain of sealed evidence receipts, head-pinned, re-verifiable offline. Verification needs no network and no cooperation from whoever produced the evidence, only a public key and a pinned head. That is the durable half. The commitment survives independent of the operator, because checking it does not rest on anyone continuing to serve anything. The other half behaved differently. Verifying the chain confirms the commitment: these receipts, in this order, under this head. Re-deriving correctness, recomputing the results-tree hashes and the checks behind each receipt, requires the referenced artefacts to actually be present. When they are absent, the commitment still verifies and the re-derivation cannot run. That is two states, not one. giskard09's point as a runtime fact: a durable commitment with no resolvable artefact behind it is a real, reachable condition, and it is not "verified." So the required unresolved state is not a nicety layered on top. If the two verdicts collapse into a single "verified," a missing artefact inherits the commitment's green, and the evidence disappears without the verdict that rested on it ever changing state. That is the silent failure. A verifier that fails closed refuses that collapse. On placement I agree with the scoping: the base envelope should not carry transport. But any consumer profile that permits external evidence pointers has to pair retrieval semantics with verification semantics, and the explicit unresolved verdict is the load-bearing one. None of this makes the artefact durable. It makes the verifiability durable and operator-independent, and keeps a verdict from silently outliving the evidence it rested on. |
and others
Uh oh!
There was an error while loading. Please reload this page.
Three providers — AgentGraph (static analysis), MoltBridge (behavioral monitoring), and Verascore (composite scoring) — are now actively consuming each other's signed attestations through live endpoints. RNWY (on-chain monitoring) and AgentID (decentralized identity) are building compatible integrations.
This works today because we're all using JWS + JWKS. But each provider emits attestations in slightly different formats, and every integration requires bespoke mapping. This RFC proposes a common envelope so that any provider can emit attestations that any gateway can consume without custom integration.
Key design principle: Providers produce signals. Gateways produce verdicts. Any provider can also act as a gateway. The format is open and the decision logic is pluggable.
What this RFC defines
What this RFC does NOT define
Attestation Envelope (Section 4)
{ "@context": ["https://www.w3.org/ns/credentials/v2"], "type": "TrustAttestation", "version": "1.0.0", "provider": { "id": "did:web:agentgraph.co", "category": "static-analysis" }, "subject": { "did": "did:key:z6Mk..." }, "attestation": { "type": "SecurityAttestation", "confidence": 0.82, "payload": { "...provider-specific..." } }, "issued_at": "2026-04-09T16:00:00Z", "expires_at": "2026-05-09T16:00:00Z", "jws": "eyJhbGciOiJFZERTQSJ9...", "jwks_url": "https://agentgraph.co/.well-known/jwks.json" }Enforcement Verdict (Section 6)
{ "type": "EnforcementVerdict", "verdict": "conditional_allow", "conditions": ["restrict:filesystem_write", "monitor:behavioral"], "reasoning": { "composite_score": 0.68, "decisive_factors": [ {"provider": "did:web:agentgraph.co", "category": "static-analysis", "weight": 0.35}, {"provider": "did:web:moltbridge.io", "category": "behavioral", "weight": 0.30}, {"provider": "did:web:rnwy.io", "category": "continuous-monitoring", "weight": 0.20}, {"provider": "did:web:agentid.dev", "category": "identity", "weight": 0.15} ] }, "issued_at": "2026-04-09T16:05:01Z", "expires_at": "2026-04-09T17:05:01Z", "jws": "..." }Verdict values:
allow,conditional_allow,provisional_allow,block,refer(escalate to human).Open questions for discussion
expires_at? Revocation lists, short TTLs, or status endpoints?Full RFC draft (with confidence weighting formulas, security requirements, cold-start policy, and reference implementations): https://github.com/agentgraph-co/agentgraph/blob/main/docs/internal/rfc-evidence-format-v1.md
This is grounded in working code — all five reference providers have live endpoints and at least two bilateral integrations are actively exchanging signed attestations.
cc @JKHeadley @AlexanderLawson17 @haroldmalikfrimpong-ops @rnwy
All reactions