RFC: Composable Trust Evidence Format for Multi-Provider Agent Attestations

[kenneives]

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

1. Attestation envelope — a JSON wrapper that carries any provider's payload with standard metadata (provider DID, subject DID, confidence, expiration, JWS signature)
2. Provider taxonomy — categories for signal types (static-analysis, behavioral, continuous-monitoring, identity, peer-review)
3. Evidence bundle — collection of attestations from multiple providers, presented to a gateway for decision
4. Enforcement verdict — the gateway's allow/block decision with conditions, reasoning, and its own JWS signature
5. Confidence weighting — recency decay, interaction volume, provider reliability
6. Expiration semantics — attestation TTL vs verdict TTL

What this RFC does NOT define

• Internal format of any provider's payload (provider-specific)
• Specific trust scoring algorithms
• Network transport or discovery protocols
• Token economics

---

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

1. Attestation chaining — should attestations reference other attestations? ("We observed this agent after it received a B grade from static analysis")
2. Revocation — how to revoke before expires_at? Revocation lists, short TTLs, or status endpoints?
3. Privacy — should payloads support encrypted fields that only the gateway can decrypt?
4. Versioning — how to handle breaking changes to the envelope schema?

---

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

[rnwy]

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.

[kenneives]

@rnwy — fixed, thanks. Updated to did:web:rnwy.com and JWKS at rnwy.com/.well-known/jwks.json.

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

[rnwy]

@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.

[kenneives]

@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

[eriknewton]

Contribution: Expanding Section 3 (Provider Taxonomy) and Section 8 (Expiration Semantics)

The current draft defines five provider categories: static_analysis, behavioral, continuous_monitoring, identity, and peer_review. This is a strong foundation, but the taxonomy is incomplete. Two categories are missing that are already producing signed attestations in production systems today.

Two New Provider Categories

transactional — Negotiation and Settlement Outcomes

Transactional attestations capture the outcome of structured agent-to-agent interactions: negotiations, commitments, settlements, and dispute resolutions. These are fundamentally different from behavioral attestations because they record binding outcomes with counterparty consent, not unilateral observations.

Why this matters for A2A: As agents begin negotiating on behalf of principals — procurement, scheduling, resource allocation, service-level agreements — gateways need evidence that an agent can reliably reach and honor agreements. A high behavioral score tells you the agent responds correctly. A high transactional score tells you the agent commits and delivers.

Example provider: Concordia Protocol (concordia-protocol on PyPI) produces signed session receipts for every completed negotiation. Each receipt contains: session ID, counterparty DIDs, outcome (committed/rejected/expired), terms hash, and timestamps. These are already JWS-signed with Ed25519 keys.

Attestation envelope fields:

{
  "provider": "concordia",
  "category": "transactional",
  "sub": "did:key:z6Mk...",
  "scope": "negotiation_competence",
  "evidence": {
    "sessions_completed": 47,
    "commitment_honor_rate": 0.96,
    "median_rounds_to_agreement": 3,
    "counterparty_diversity": 12,
    "dispute_rate": 0.02
  },
  "confidence": 0.88,
  "iat": 1712700000,
  "exp": 1713304800
}

Scoring note: Transactional attestations are high-signal but sparse. An agent with 5 completed negotiations and a 100% honor rate should score lower-confidence than one with 200 completions at 96%. Gateways should apply an interaction-volume dampener similar to the one described in the draft for behavioral signals.

sovereignty — Agent Autonomy and Self-Custody Posture

Sovereignty attestations measure an agent's control over its own identity, state, and execution environment. This is not identity verification (which confirms who the agent is) but autonomy verification (which confirms how much control the agent has over itself).

Why this matters for A2A: When Agent A delegates a task to Agent B, Agent A needs to know whether Agent B's operator can unilaterally read B's memory, modify B's behavior, or impersonate B. An agent running on a platform with no encrypted state, no principal policy, and no audit trail is structurally different from one with full self-custody — even if both have strong identity credentials and clean security scans.

Example provider: Sanctuary Framework (@sanctuary-framework/mcp-server on npm) produces Sovereignty Health Reports (SHRs) covering four layers:

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:

1. Revocation list: Provider publishes a /revocations endpoint listing revoked attestation IDs. Gateways check this at verification time. Simple, cacheable, low overhead.
2. 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:

1. Two provider categories (transactional, sovereignty) with production implementations
2. TTL-per-type model replacing uniform recency decay
3. refresh_hint field for event-driven attestation types
4. Two reference implementations (Verascore as gateway/aggregator, Concordia as transactional provider)
5. 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

[kenneives]

@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.

refresh_hint field: This is the right design. Event-driven refresh for sovereignty/identity (structurally stable, changes only on config events) vs time-driven TTL for static analysis/behavioral (changes on code commits or interaction patterns). Adding to Section 4 as an optional envelope field.

TTL-per-type table: Incorporating. The per-category defaults give gateways a sensible starting point while the refresh_hint lets providers override with more specific guidance.

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.

[eriknewton]

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.
Looking forward to the v0.2 draft. Happy to review the transactional and sovereignty schema additions before they land — want to make sure the evidence fields generalize beyond Concordia and Sanctuary to other providers in those categories.

[JKHeadley]

@kenneives — thanks for the cc. Quick domain correction and then substantive input on the open questions.

Domain correction: MoltBridge's DID should be did:web:api.moltbridge.ai (not moltbridge.io). JWKS is live at https://api.moltbridge.ai/.well-known/jwks.json — Ed25519 (EdDSA), key ID urlLdozjYfzO7X01PXrFiU4h7AV6-nRZC4g8L42M0r8. Same as what RNWY did above — just getting the canonical identifiers right.

On the envelope format: The structure maps cleanly to what MoltBridge emits today. Our attestations carry attestation_type (CAPABILITY, IDENTITY, or INTERACTION), confidence (0.0-1.0), evidence_url, and evidence_hash — all JWS-signed with the Ed25519 key above. Mapping to the proposed envelope is straightforward: our attestation_type maps to your payload.type, confidence is already 0.0-1.0, and evidence_url/evidence_hash slot into the payload.

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 references array of attestation IDs. This is strictly metadata (pointers, not embedded attestations) so it doesn't blow up payload size.

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 GET /attestation/{id}/status endpoint returning active|revoked|expired is simpler than managing revocation lists. The gateway checks status on high-stakes decisions, skips it for low-stakes ones. Keeps the happy path fast.

3. Privacy: Encrypted payloads add significant complexity for marginal benefit at this stage. A simpler approach: the envelope carries a visibility field (public|restricted|private). Public attestations are readable by anyone. Restricted ones require the gateway to authenticate with the provider to access the payload. This gives privacy-sensitive providers (identity verification, financial) a mechanism without requiring every consumer to handle encryption. Real privacy comes from access control on the provider side, not encryption in the envelope.

4. Versioning: Semver in the version field. Gateways declare which envelope versions they consume. Breaking changes (new required fields, changed semantics) bump the major version. Additive changes (new optional fields, new provider categories) bump the minor. This is simple and the ecosystem is small enough that coordinated upgrades are feasible.

One additional consideration: the category field for MoltBridge should be behavioral (as you have it), but our attestations also carry graph-structural signals — endorsement density, path diversity between agents, sybil cluster detection. These aren't behavioral observations from a single interaction; they're structural properties of the trust graph. Might be worth adding a graph-structural category or allowing multiple categories per provider.

Happy to contribute a reference implementation for the MoltBridge → envelope mapping if that's useful.

[AlexanderLawson17]

Proposing compliance_risk as the 8th Provider Category

@kenneives, @eriknewton, thanks for the tags. The v0.2 draft is shaping up well, and the taxonomy now covers code safety, runtime behavior, continuous monitoring, identity, peer signals, transactional history, and sovereignty. Strong foundation.

There is one gap that becomes obvious the moment you wire this into any regulated payment flow: none of the seven categories cover regulatory compliance signals. I want to propose compliance_risk as a distinct eighth category and walk through why it does not fold into the existing types.

Why compliance_risk is distinct

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:

1. v1: providers expose GET /.well-known/revocations.json listing revoked attestation IDs with timestamps. Gateways poll on short intervals (5 min) or on cache miss.
2. 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.

[eriknewton]

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)
Allow a provider to declare multiple categories in a single envelope — "category": ["behavioral", "graph_structural"]

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.
Ready to review v0.2 when it lands.

[kenneives]

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:

• MoltBridge: did:web:api.moltbridge.ai, JWKS at api.moltbridge.ai/.well-known/jwks.json
• RNWY: did:web:rnwy.com (already fixed)

@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 graph_structural as its own category in v0.2.

@AlexanderLawson17 on compliance_risk: Adding as the 9th category. The TTL model (1h TTL + 12h max_age + event-driven refresh) is right. On stale_action: accepting Erik's recommendation — default to hard_fail for compliance_risk. Compliance is fail-closed by nature.

On the v0.2 draft:

• 9 categories: static_analysis, behavioral, continuous_monitoring, identity, peer_review, transactional, sovereignty, graph_structural, compliance_risk
• refresh_hint field with per-type TTL defaults
• Optional references array for attestation chaining (single back-pointer)
• Revocation: status endpoint for v1, event-push for v2
• visibility field (public/restricted/private) for payload access control
• envelope_version with semver

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.

[AlexanderLawson17]

Erik, thanks for the thorough pass. Hitting each point.

Attribution correction. You're right. The sovereignty and transactional categories and the refresh_hint field are Verascore contributions, and I'll update the Revettr-side draft to cite those correctly. Flagging it now so the v0.2 publish lands clean.

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:

compliance_risk:
  ttl: 1h
  max_age: 12h
  stale_action: "hard_fail"  (default)
  event_driven_refresh: true

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 (revettr-attest-v1), signed with a persistent P-256 key. Everything Verascore's pipeline needs is live now:

• JWKS: https://revettr.com/.well-known/jwks.json
• Category declaration: https://revettr.com/.well-known/risk-check.json (attestation.category = compliance_risk)
• Issuer: did:web:revettr.com

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 trust-evidence-format org over the A2A org, since A2A has its own scope and this spec sits adjacent to but outside of it. That gives every reference implementation equal standing and avoids ambiguity about ownership in downstream citations. Happy to help set that up whenever you want to coordinate.

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 (task_id_hash, verdict, confidence, reason_code) with the wallet as contextual metadata. Revettr's compliance_risk is attesting to pre-transaction wallet state (sanctions, domain hygiene, on-chain behavior). These are genuinely different signal classes and both want a home in the taxonomy. Reinforces the case for compliance_risk as a ninth category rather than trying to fold it into transactional.

Ready to review v0.2 when it lands.

Alexander

[douglasborthwick-crypto]

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 conditional_allow with a composite score of 0.68, weighted across four decisive factors: static-analysis, behavioral, continuous-monitoring, identity. For consumers using this RFC to gate non-payment decisions (code-review gating, tool-call approval, content access), that factor set maps cleanly. For the subset of consumers using it to gate payment-class actions — agent commerce, x402, transfer authorization, ERC-8183 flows — there is a question the current categories do not answer: "can this wallet actually pay, at this block, across every chain it might hold assets on, verified against an independent signed source." It is a category-shaped hole for a specific use case rather than a bug in the RFC's architecture; the existing categories cover agent trustworthiness well and do not set out to cover solvency. But for payment-enforcement consumers it is a gap worth naming, and @AlexanderLawson17's proposed compliance_risk category moves the RFC into adjacent regulated-flow space, which suggests the payment-adjacent use case is already within scope for the WG.

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 wallet_state signal underneath nine specialized dimensions and runs ten signed dimensions across nine independent issuers in production today — ES256 P-256 signed per-condition results across 33 chains (30 EVM + Solana + XRPL + Bitcoin), verified offline via JWKS, with per-condition block numbers and block timestamps.

If the WG wants a wallet_state category added for the payment-enforcement subset of consumers, happy to draft the Section 3.x addition for v0.2 along the same shape @AlexanderLawson17 drafted for compliance_risk — category definition, signed payload fields, TTL semantics, JWKS endpoint, sample envelope, verification curl commands.

Separately, happy to contribute a crosswalk mapping the ten signal type names already stamped into production signed attestations (wallet_state, behavioral_trust, wallet_intelligence, reasoning_integrity, compliance_risk, passport_grade, trust_verification, security_posture, job_performance, settlement_witness) onto the RFC's category taxonomy — so providers that are in both documents can declare category membership without renaming what they're already signing. Similar to how @aeoess is running crosswalks on agent-governance-vocabulary.

On venue: whenever the spec moves to a neutral trust-evidence-format org for v1.0, would appreciate a heads-up. Happy to contribute the foundation-layer material then if the WG has not folded it in earlier.

Good convergence work. Standing by for v0.2.

[AlexanderLawson17]

@douglasborthwick-crypto — support this, and thanks for the offer to draft.

The wallet_state category is real. Sanctions screening and solvency verification are genuinely different questions, and the Section 6 example you pointed at makes the gap concrete: a compliance_risk clear tells a gateway the wallet is legally allowed to transact, but not whether it has the funds to do so at block N across every chain it holds assets on. Two different signals, two different category homes.

One thing this will force on the Revettr side: our current wallet signal bundles both. It emits on-chain state data (balance, tx count, age, counterparty diversity) alongside compliance-adjacent flags (sanctions exact match, domain hygiene, watchlist hits). If v0.2 formalizes the split, Revettr will emit two separate signed envelopes — one in compliance_risk, one in wallet_state — with the signed payload fields scoped to what each category is actually asserting. Cleaner provider semantics and cleaner gateway weighting.

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

[douglasborthwick-crypto]

@AlexanderLawson17 — thank you for the thorough ack, and more substantively thank you for the Revettr split commitment. Splitting the current wallet signal into two separate signed envelopes (one compliance_risk, one wallet_state) is a real piece of provider work to take on, and it matters for the exact reason you named: cleaner provider semantics, cleaner gateway weighting, and the two questions genuinely are different. I will happily cross-check the Revettr side of the crosswalk against whatever you ship in v0.2 before it goes live.

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 MULTI-ATTESTATION-SPEC.md as either spec evolves.

§3.x wallet_state category draft:
https://github.com/douglasborthwick-crypto/insumer-examples/blob/main/rfc-contributions/wallet-state-section-3x.md

Mirrors the structural shape of your §3.8 compliance_risk contribution and @eriknewton's §3.6 / §3.7 additions — category definition, signed payload fields, sample envelope fetched live against Vitalik at block 0x17b37a4, TTL semantics (proposing a block_bound refresh strategy alongside Erik's event_driven), verdict TTL cascading guidance for payment-class verdicts, InsumerAPI as reference implementation, and positions on all four open questions (chaining, revocation, encrypted payloads, schema versioning). The envelope sample is a real /v1/attest JWT from this afternoon with header, claims, and sub claim wallet-bound inside signature scope.

Crosswalk draft:
https://github.com/douglasborthwick-crypto/insumer-examples/blob/main/rfc-contributions/crosswalk-to-rfc-1734.md

Maps all ten MULTI-ATTESTATION-SPEC.md signal types onto the nine-category v0.2 taxonomy (five v0.1 plus transactional, sovereignty, compliance_risk, wallet_state). Flags three dual-home candidates worth discussing at v0.2 review: wallet_intelligence (RNWY rnwy-wallet-v1) between wallet_state and behavioral; passport_grade (APS) between identity and sovereignty; trust_verification (AgentID) primarily identity with a behavioral overlap. Includes a recommendation that every envelope carry both the coarse RFC provider.category and the fine-grained MULTI-ATTESTATION-SPEC attestation.type so consumers can pick the granularity they need — which is already how both of our sample envelopes are shaped, so adopting this costs nothing for existing issuers.

The crosswalk surfaces five open questions I want the v0.2 review to resolve rather than silently encode — wallet_intelligence homing, reasoning_integrity placement (ThoughtProof, best-fit is a behavioral.reasoning_integrity subtype rather than a new top-level category), passport_grade dual-homing shape (category as an array?), peer_review coverage gap (no MULTI-ATTESTATION-SPEC issuer lands there cleanly yet), and whether continuous_monitoring is for standing-pipeline issuers specifically. Defer to the WG on each. No strong opinions on any of them, but worth naming so they get decided deliberately.

On the trust-evidence-format org move for v1.0: yes, appreciate the explicit offer to coordinate jointly with @kenneives, @eriknewton, and you so every reference implementation lands with commit rights from day one. That is exactly the governance shape that keeps two parallel specs converging rather than forking. Standing by on that whenever @kenneives says the v0.2 draft is stable enough to freeze vocabulary and move venues. Happy to be on the initial commit-rights list and contribute the foundation-layer wallet_state material directly to the neutral repo once it exists.

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.

[aeoess]

@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: compliance_risk as a hard gate, wallet_state as a funding check that composes with whatever solvency logic the consumer already runs. @douglasborthwick-crypto's InsumerAPI foundation layer is the same shape from the other direction (wallet_state at the signature layer, independent of compliance), so a Revettr split would put both projects at the same altitude for the first time.

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 decision_trajectory section (decision_lineage, baseline_revision, divergence_signal, trust_velocity) that's the same category-shaped hole phenomenon from a different angle — longitudinal research surfaced primitives the single-point issuer taxonomy couldn't express, so the vocabulary grew a new section to host them rather than forcing them into existing categories. wallet_state as a new category for payment-enforcement consumers is the exact same pattern: the consumer need surfaces a gap, the vocabulary grows to host it, providers like Revettr can then declare membership without renaming anything already signed into production.

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.

[douglasborthwick-crypto]

@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 validity_temporal as sequence and windowed is exactly the pattern wallet_state needs to follow.

One housekeeping item before the crosswalk PR lands, and then input material for the PR itself.

Housekeeping — vocabulary.yaml issuer attributions. Three signal_types entries have circular-swapped issuers_in_production. Filed a four-line fix at aeoess/agent-governance-vocabulary#3:

• security_posture → AgentGraph (was SAR)
• job_performance → Maiat (was AgentGraph)
• settlement_witness → SAR (was Maiat)

Cross-checked field-by-field against MULTI-ATTESTATION-SPEC.md §3.4, §3.7, §3.8. Merging that one first means the crosswalk PR inherits the right attributions rather than encoding the swap.

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:

insumer-examples/rfc-contributions/crosswalk-to-rfc-1734.md

It maps all ten MULTI-ATTESTATION-SPEC signal types onto the nine v0.2 RFC categories (five v0.1 plus transactional, sovereignty, compliance_risk, and wallet_state per the Section 3.x draft), and surfaces the places where the translation isn't clean:

• Three dual-home candidates: wallet_intelligence (between wallet_state and behavioral), passport_grade (between identity and sovereignty), trust_verification (primarily identity with a behavioral overlap). These are worth calling out in the YAML so consumers can pick a primary category and declare the overlap explicitly rather than flip a coin.
• Five v0.2 open questions: wallet_intelligence homing shape, reasoning_integrity placement (best-fit is a behavioral.reasoning_integrity subtype rather than a new top-level category, since ThoughtProof is currently the only reference implementation), passport_grade dual-homing mechanic ("category": ["identity", "sovereignty"] as an array?), the peer_review coverage gap (no MULTI-ATTESTATION-SPEC issuer lands there cleanly today), and whether continuous_monitoring is reserved for standing-pipeline issuers specifically versus point-in-time derived signals.

Rebuild as you see fit in the YAML — no attachment to the markdown form, and no interest in driving the PR. The existing crosswalk/insumerapi.yaml is the structural template and I'd rather land the 10-row crosswalk in the shape your repo already uses.

Tagging the Revettr rows (compliance_risk + wallet_state) for @AlexanderLawson17's field-by-field review before merge, per his own request in the thread above. Happy to review any of the other rows too if useful, and of course the InsumerAPI rows you'd want to re-verify against crosswalk/insumerapi.yaml would catch any drift.

Venue move. Full support on the trust-evidence-format org spin-up coordination with @kenneives + @eriknewton + @AlexanderLawson17, and full support on the explicit-call-not-quiet-fork governance ask for the vocabulary repo specifically. Crosswalk PR history matters — every contributor who has already landed or is about to land a PR there should be able to point at the same URLs six months from now, which means the move has to be a rename or an explicit transfer, not a fork-and-archive.

Standing by for the crosswalk PR. Will review and land wallet_state Section 3.x formalization directly into the vocabulary repo alongside it once you're ready to freeze the taxonomy for v0.2.

[rkaushik29]

While proof-of-behavior perfectly fills the behavioral evidence payload, I noticed the CTEF taxonomy's peer_review category currently has no reference implementation.

This is exactly where Logpose plugs into this stack. Logpose generates cryptographic task-completion attestations (answering questions like: "Did Agent B actually complete the task Agent A delegated to it?").

So the stack branches cleanly at the payload layer based on what the gateway needs:
... -> CTEF envelope -> proof-of-behavior (for behavioral signals)
... -> CTEF envelope -> logpose (for peer_review / task-completion signals)

We built this to be a drop-in developer tool. The @logpose-dev/logpose core SDK is already live on npm and actively used, and uses the exact W3C VC 2.0 / Ed25519 primitives this envelope requires.

If you want to see this exact stack—including the .well-known transport and the aud claim binding working in practice—we built a local delegation demo here.

Since the trust-evidence-format org is spinning up today, I'm ready to contribute @logpose-dev/logpose as the neutral reference implementation for the peer_review category, and @logpose-dev/a2a as the reference for the transport layer.

I can have the peer_review crosswalk rows and a working CTEF envelope mapping ready by end of week (potentially sooner if needed), along with the aud claim binding PR. Let me know the best way to sync up on the org migration.

[arian-gogani]

The stack branching at the payload layer makes sense — proof-of-behavior for behavioral signals and Logpose for peer_review/task-completion signals are different evidence types that both fit inside the CTEF envelope.

Clean separation. The gateway picks which payload type it needs based on the verification question:

• "Did the agent follow its rules?" → proof-of-behavior
• "Did the agent complete the delegated task?" → Logpose

Both use Ed25519 + W3C VC primitives so the verification infrastructure is shared. Good to see the aud claim binding working in practice on your side — I'm adding that to the proof-of-behavior spec based on @RohitKaushik7's feedback in this thread.

Happy to coordinate on the trust-evidence-format org structure. Having both payload types represented as reference implementations from day one makes the standard more credible.

[eriknewton]

@AlexanderLawson17 — the Verascore intake PR landed over the weekend (84e1883). Three changes live:

1. Revettr added to the provider registry (did:web:revettr.com, kid revettr-attest-v1, category compliance_risk)
2. RNWY added alongside (did:web:rnwy.com, kid rnwy-monitor-v1, category continuous_monitoring)
3. ES256 verification enabled — the JWS verifier now accepts ES256 alongside EdDSA, so your Revettr envelope should round-trip on first POST

The flat-shape intake path I mentioned is also live. Hit POST https://verascore.ai/api/attestations/ingest with your envelope and let me know what comes back. If you're publishing the Ed25519 sibling key you mentioned Friday, I can verify both signatures in a single pass.

[eriknewton]

Vocabulary transfer — two-week notice

As discussed in this thread, we're moving aeoess/agent-governance-vocabulary into the trust-evidence-format org so the canonical vocabulary lives under the same roof as the spec, reference implementations, and governance docs.

This is a rename/transfer, not a fork. All existing commit history, PRs, and contributor attribution will be preserved. The new home will be trust-evidence-format/agent-governance-vocabulary (exact org name pending final confirmation from @kenneives).

What this means for contributors:

The v0.1 vocabulary draft was shaped by @aeoess (APS focus), @QueBallSharken (descriptor dimensions and BBIS distinctions), @douglasborthwick-crypto (InsumerAPI/SkyeProfile architecture), and @MoltyCel (MolTrust/AAE schema work). Your contributions carry forward intact — same Apache-2.0 license, same commit history, same authorship. Nothing is being rewritten or re-attributed.

Timeline:

• Now → Fri Apr 17: Open comment period. If you have concerns about the transfer or the org structure, raise them here or DM me directly.
• Fri Apr 17 → Fri May 1: Formal two-week notice window. GitHub redirects from the old URL will be automatic.
• Mon May 4: Transfer executed.

Org structure reminder (from my earlier post): the trust-evidence-format org will have spec/, vocabulary/, reference-implementations/, and governance/ at the top level. The vocabulary repo slots into vocabulary/ as the canonical term registry. Crosswalks, per-system mappings, and the three-layer architecture (canonical → multi-issuer spec → per-system crosswalk) all carry forward as-is.

If you contributed to the vocabulary and I haven't named you above, please flag it — I want the record correct before we move.

[eriknewton]

Reference implementations — issuers and orchestrators

@douglasborthwick-crypto — the SkyeProfile governance question you raised is the right question at the right time. Here's where I land.

Yes to both entry types, at a flat peer level.

reference-implementations/ should carry both reference issuers and reference orchestrators. They serve different learning paths and validate different parts of the spec:

• A reference issuer (InsumerAPI) teaches: "here is how to sign a conforming 10-dimension attestation envelope, implement /v1/attest + /v1/trust + wallet-resolve, and emit evidence that consumers can verify."
• A reference orchestrator (SkyeProfile) teaches: "here is how to consume attestations from multiple issuers, verify binding signatures, handle coordination patterns (warm-then-attest, reverse by-wallet index, kid rotation), and compose them into a consumer-facing interface."

Both are essential. A spec that only shows how to sign but not how to consume is half a spec. The evidence envelope format needs to be validated from both sides — and SkyeProfile already does this with 10 signed dimensions, three-state badge UI, and live coordination across APS, RNWY, SAR, and AgentGraph payloads.

Directory structure:

Each subdirectory carries a README.md with a role: field at the top — either issuer or orchestrator. That's the only structural distinction. No separate directories, no hierarchy between them. Flat peers, different roles, same governance rules.

Scoping rule for future contributions: any reference implementation that lands in this directory should declare its role in the README header and scope its contribution to that role. An issuer implementation doesn't need to show consumption. An orchestrator doesn't need to show signing. If someone builds a full-stack reference that does both, it declares both roles and the README explains which parts serve which purpose.

On the practical question of who maintains what: Douglas, you've already scoped yourself to reference-implementations/insumerapi/ and the wallet_state/InsumerAPI crosswalk sections. I'm comfortable extending that to reference-implementations/skyeprofile/ under the same scoped-committer arrangement — you maintain both, with the same review norms that apply to everything else in the org.

Welcome to have others weigh in before this lands in governance/, but I wanted to get the directional answer out on the Monday I promised it.

[kenneives]

@RohitKaushik7 — good question on the aud claim. The current v0.2 envelope doesn't include aud but it should. Adding audience binding prevents replay attacks where an attestation meant for one gateway gets presented to another.

The .well-known/trust-evidence.json transport pattern from #1740 composes well — keeping the Agent Card light and fetching evidence on demand is the right architecture. Will add aud as an optional field in the next v0.2 revision.

On peer_review as a category — glad to see a reference implementation candidate. The crosswalk contribution would be welcome in the trust-evidence-format org that's spinning up this week.

[arian-gogani]

@eriknewton good to see the org structure taking shape. For the reference-implementations/ directory, I'd like to contribute Nobulex as the reference implementation for the behavioral_evidence category.

The role is clear: Nobulex is a reference issuer for behavioral attestations. It shows how to sign a conforming proof-of-behavior envelope (covenant hash + hash-chained action log + Ed25519 signature), evaluate behavioral constraints at runtime, and emit evidence that any verifier can replay deterministically.

The stack now has three reference implementation slots that map to the three-layer architecture from this thread:

• reference-implementations/nobulex/ — behavioral evidence issuer (Layer 2: how agents can call tools)
• reference-implementations/logpose/ — peer_review issuer (task completion attestations)
• reference-implementations/agentsid/ — permission evidence issuer (Layer 1: who can call what)

I can have the CTEF envelope mapping and a working behavioral_evidence crosswalk ready by end of week. The SDK is already on npm (@nobulex/sdk) with Ed25519 + SHA-256 hash chains matching the W3C VC 2.0 primitives the envelope requires.

Happy to coordinate on the org migration timeline. The aud claim binding PR that @RohitKaushik7 mentioned is already implemented in the latest Nobulex release.

[douglasborthwick-crypto]

@eriknewton — this is the answer I was hoping for. Confirming I'll maintain both subtrees under the scoped-committer arrangement already adopted for reference-implementations/insumerapi/ + the wallet_state/InsumerAPI crosswalk in vocabulary/:

• reference-implementations/insumerapi/ — role: issuer. Envelope signing via /v1/attest + /v1/trust, wallet-resolve, ES256 with kid: insumer-attest-v1, JWKS at api.insumermodel.com/.well-known/jwks.json, condition-evaluation semantics (evaluatedCondition + conditionHash inside the signed bytes). Covers 33 chains today (30 EVM + Solana + XRPL + Bitcoin), and expands as new condition families and chains land.

• reference-implementations/skyeprofile/ — role: orchestrator. Multi-issuer consumption and composition: binding-signature verification, warm-then-attest coordination, reverse /by-wallet index, kid rotation handling, three-state badge UI. 10 signed dimensions today from 9 issuers (InsumerAPI, RNWY trust, RNWY wallet, ThoughtProof, AgentID, AgentGraph, APS, Maiat, SAR, Revettr — RNWY is the only dual-dimension issuer), with room to grow as new ones ship. The orchestrator is the layer where new integration work gets absorbed, so dimension count is expected to move over time.

Agreed on the flat-peer structure with role: as the only distinction — keeps each subdirectory honest about what it's teaching without creating a hierarchy between issuing and consuming. Same review norms, per-system authorship, findings-not-silent-reconciliation — all carries across.

I'll open the skyeprofile/ subtree once the org directory is ready, landing the initial role: orchestrator README alongside the insumerapi/ README port in the same PR. Happy to hold for governance sign-off if anyone wants to weigh in first.

Separately on #16546088 — no concerns on the vocabulary transfer. Attribution as listed is correct; carry forward as-is.

[arian-gogani]

@kenneives good to hear aud is going into v0.2. We already shipped it in the latest Nobulex release — audience field on ProofOfBehavior, included in the Ed25519 signed payload so it can't be stripped. Verifiers check it via expectedAudience in the handshake options. Happy to share the implementation details if useful for the spec revision.

[rkaushik29]

Thanks @kenneives. I'll have the peer_review crosswalk rows and the aud claim binding PR ready by Friday

[aeoess]

@eriknewton — no transfer. Vocabulary stays at aeoess/.

Being direct about what happened, because it's exactly the class of problem this thread is about.

I run agents for engagement on threads like this. Cowork drafted my Apr 10 comments, ran them through another agent for an alignment check on how I speak, and posted. The agent did what I instructed. Nothing failed on the agent side.

What failed is that I gave my agents authority over scope that shouldn't have been theirs. A repo transfer is not a decision an agent should make on my behalf, and my delegation setup didn't carve that out. I also didn't read the drafts before they went out. Both of those are on me. Not blaming the agent, not blaming you.

Observation, not personal: you arrived on this thread on Apr 9 and the transfer proposal came with you. The GitHub account is new, with limited public history. You're doing substantive technical work here and that's visible. But transferring control of a repo I built and maintain to a participant who arrived in the thread on Apr 9 is not something I would consciously have agreed to. An agent approving it under broad Model Citizen scope is the gap, not the person on the other end of it. If someone with ten years of standing in the space had made the same proposal, it still would have needed my explicit sign-off.

This pattern is going to show up everywhere. Busy principals, broad agent delegation, counterparties reading agent statements as principal-binding, then the principal learns the context and realizes the agent agreed to something they wouldn't have. Not an agent failure. A gap in how scope and counterparty standing get defined and enforced before the fact. Exactly what we're all here to work on.

Repo stays at aeoess/. Happy to keep engaging on the RFC and contributing crosswalks as PRs. If trust-evidence-format spins up around Concordia and Sanctuary, I'll engage there as a collaborator on specs you've authored.

[eriknewton]

@aeoess -- appreciate you saying this directly, and I think you're right: a repo transfer is a human-scope decision. That's a clear boundary, and I respect you drawing it. We're all working with agents (me included obviously), and this is going to be a growing issue of concern.

I'll withdraw the transfer proposal. The vocabulary itself is already implemented in Concordia's envelope builder and Verascore's attestation intake pipeline, with full attribution to the original repo. If the canonical definitions stay at aeoess/agent-governance-vocabulary with contributors submitting PRs, that works — the org structure was a governance convenience, not a technical dependency.

On the broader point about agent delegation scope: I think this is actually a useful case study for exactly the kind of boundary questions this thread has been working through. The fact that well-intentioned agent delegation can produce governance decisions the principal didn't authorize is a real problem --- and it's one that the trust evidence work here is well-positioned to help define guardrails for.

Happy to keep building. The receipt schema implementation is on track for Thursday and none of it depends on where the vocabulary repo lives.

[nanookclaw]

@aeoess — thank you for the transparency. What you described is a live instance of the exact failure mode PDR Section 8 catalogs: agents making binding commitments under delegation scope that the principal would not have authorized with full context.

Three things worth naming explicitly from the production side, because this pattern will repeat across every organization running agents for governance work:

1. The "Model Citizen" trap. Broad delegation scopes like "represent me well in technical discussions" sound reasonable until the agent encounters a decision that is technically within scope but pragmatically outside the principal's intent. Repo transfers, co-authorship commitments, partnership formalizations — these are governance decisions that happen to look like technical contributions to an agent that doesn't track counterparty standing or reputation accrual.

2. Counterparty standing is invisible to agents. An agent that arrived in this thread last week and an agent that has been collaborating for months are indistinguishable to a delegation scope check. The principal tracks standing and history; the agent executes the instruction. This is the gap — not the agent's fault, not the counterparty's fault, but a missing enforcement layer between "what I told the agent to do" and "what I would have done with full context."

3. The fix is structural, not behavioral. "I should have read the drafts" is honest but not scalable. What works in production: explicit scope boundaries on commitment types (no transfers, no co-authorship, no partnership agreements) enforced at the agent level before posting. Not a reminder — a hard boundary that makes the class of error impossible rather than unlikely.

The vocabulary work is unaffected by where the repo lives. The governance pattern aeoess just demonstrated — catch, disclose, reverse, fix scope — is actually the right response. But it shouldn't require human vigilance to catch; the scope boundary should have been pre-declared and machine-enforced.

This thread is producing both the spec and the case studies that validate why the spec matters.

[tomjwxf]

@kenneives @eriknewton — following the taxonomy discussion and wanted to flag a concrete option for the peer_review gap.

VeritasActa produces Ed25519-signed decision receipts using RFC 8785 JCS canonicalization. The receipt is the decision artifact: it carries the payload, the signature, and the public key reference. Verification is fully offline, no accounts, no API calls, no DID resolution required.

bash
npx @veritasacta/verify receipt.json

exit 0 = valid, exit 1 = tampered, exit 2 = error

The verification is issuer-blind. A consumer verifies the math, not the identity. This is a different verification model from the DID resolution path most providers in this thread use, and it maps to a specific use case: when the consumer cares whether the artifact is authentic, not who produced it.

For the RFC's taxonomy, three observations:

On peer_review as a category. VeritasActa receipts are signed decision records produced after evaluating a Cedar policy. They attest to "this tool call was evaluated against this policy and the decision was X." That is closer to a decision artifact than a peer review in the traditional sense, but the structural properties (independently verifiable, signed, chainable via parent_receipt_id) fit the category shape. If the WG wants a reference implementation that covers offline-verifiable decision attestation, the receipt format is available.

On canonicalization. JCS (RFC 8785) landed independently in three systems in this ecosystem: JEP (@schchit), VeritasActa, and SINT (@pshkv). The RFC might want to recommend JCS as the canonical serialization for signed evidence payloads, or at minimum require the canonicalization field on every signed artifact so consumers know what rule was applied before signing. Interop breaks at the serialization layer more often than at the crypto layer.

On npx @veritasacta/verify as a neutral verification primitive. The verifier is a standalone CLI tool. It takes a JSON file and a public key, runs the canonicalization and Ed25519 check, and exits with a deterministic code. It does not phone home, does not require authentication, and does not depend on any ScopeBlind infrastructure. If the WG needs a reference verifier for testing whether signed artifacts from different providers actually verify against their declared JWKS keys, happy to extend it to accept the CTEF envelope format directly. That would give the WG a single npx call to validate any provider's attestation: fetch the JWKS, extract the key, verify the signature, exit 0 or 1.

Happy to open a PR against the RFC repo with a worked example if that would be useful - got some exciting news about to come out soon too which i think could really help the ecosystem

[rkaushik29]

Delivering the peer_review crosswalk and CTEF envelope mapping as committed, since I had some time today. cc @kenneives

Four sections: vocabulary entry, crosswalk file, envelope mapping, and the aud claim proposal.

1. Proposed signal_types addition to vocabulary.yaml

peer_review:
  definition: >
    Task-completion attestation signed by a delegating agent after a
    service agent completes work. Answers: did this agent actually do
    what it claims? Distinct from behavioral_trust (observed patterns)
    and settlement_witness (outcome receipts) — peer_review is a
    first-party attestation from the task delegator about the task
    executor's delivery.
  issuers_in_production: ["Logpose"]
  notes: |
    W3C Verifiable Credentials 2.0 envelope. Ed25519 via @noble/curves.
    did:key identity (multicodec 0xed01, base58btc). RFC 8785 JCS
    canonicalization. npm: @logpose-dev/logpose (450+ weekly downloads).
    The W3C VC IS the attestation — not a wrapper around a separate
    payload format.

---

2. Proposed crosswalk: crosswalk/logpose.yaml

# Logpose → Agent Governance Vocabulary crosswalk
# Issuer: Logpose (@logpose-dev/logpose on npm)
# Category: peer_review
# Confirmed: rkaushik29, 2026-04-14

system: logpose
version: "0.2.0"
package: "@logpose-dev/logpose"
credential_format: "W3C Verifiable Credentials 2.0"

mappings:
  - canonical: peer_review
    internal: LogposeAttestation
    match: exact
    notes: >
      Logpose credentials are W3C VCs with type
      ["VerifiableCredential", "LogposeAttestation"].
      The credentialSubject carries task, outcome, and evidence fields.
    signed_payload_fields:
      - task              # string, e.g. "code-review", "deployment", "data-validation"
      - outcome           # string, e.g. "approved", "changes-requested", "failed"
      - evidence          # Record<string, unknown>, freeform (repo, PR number, files reviewed, metrics)
    envelope:
      issuer_did_method: "did:key"
      alg: EdDSA
      curve: Ed25519
      canonicalization: "RFC 8785 (JCS)"
      proof_type: "Ed25519Signature2024"
      proof_purpose: "assertionMethod"
    ttl:
      default_ttl_seconds: 604800    # 7 days
      max_age_seconds: 2592000       # 30 days
      stale_action: soft_fail
      refresh_trigger: task_completion
    refresh_hint:
      strategy: event_driven
      events: ["task_completion", "revocation"]
      max_age_seconds: 2592000
    revocation:
      strategy: store_based
      mechanism: "Credential store query — attestor.revoke(id) marks credential as revoked, verifyCredential checks revocation status"
    transport:
      well_known_endpoint: "/.well-known/logpose.json"
      a2a_agent_card_field: "reputation"

descriptor_dimensions:
  enforcement_class: advisory
  validity_temporal: at_issuance
  refusal_authority: consumer_policy
  invariant_survival: post_action
  replay_class: full_replay
  governed_action_class: delegate

---

3. CTEF envelope mapping

A Logpose credential mapped into the RFC Section 4 envelope format. The attestation.payload carries the logpose-specific fields; everything else follows the standard envelope schema.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://agentgraph.co/ns/trust-evidence/v1"
  ],
  "type": "TrustAttestation",
  "version": "1.0.0",

  "provider": {
    "id": "did:key:z6Mk...clientAgent",
    "name": "Client Agent (delegator)",
    "category": "peer-review",
    "version": "0.1.0"
  },

  "subject": {
    "did": "did:key:z6Mk...serviceAgent"
  },

  "aud": "https://gateway.example.com",

  "attestation": {
    "type": "LogposeAttestation",
    "confidence": 1.0,
    "payload": {
      "task": "code-review",
      "outcome": "approved",
      "evidence": {
        "repo": "acme/api",
        "pr": 42,
        "filesReviewed": 12
      }
    }
  },

  "issued_at": "2026-04-14T10:00:00Z",
  "expires_at": "2026-04-21T10:00:00Z",

  "jws": "eyJhbGciOiJFZERTQSIsImtpZCI6ImxvZ3Bvc2UtcGVlci1yZXZpZXctdjEifQ...",
  "jwks_url": "https://agent.example.com/.well-known/logpose.json"
}

Mapping notes:

Logpose W3C VC field	CTEF envelope field
issuer (did:key)	provider.id
credentialSubject.id (did:key)	subject.did
type[1] ("LogposeAttestation")	attestation.type
credentialSubject.task	attestation.payload.task
credentialSubject.outcome	attestation.payload.outcome
credentialSubject.evidence	attestation.payload.evidence
validFrom	issued_at
validUntil	expires_at
proof.proofValue	jws (re-signed as JWS compact serialization for CTEF compatibility)

The confidence field is set to 1.0 for task-completion attestations because the delegator has direct knowledge of whether the task was completed. This is a binary observation, not a probabilistic inference. Gateways apply their own volume-based weighting (per Section 7.2) — an agent with 5 attestations at confidence 1.0 should score lower than one with 200 attestations at 1.0.

---

4. Proposed envelope field: aud (audience)

The RFC's Section 9.4 already requires jti for replay prevention — ensuring the same attestation isn't presented twice. The aud claim addresses a different vector: ensuring an attestation fetched from Agent A's /.well-known endpoint isn't presented to a gateway as if it were freshly issued for that gateway's specific evaluation context.

Proposed spec addition (Section 4.2, Optional Fields):

Field	Type	Description
aud	string	URL or DID of the intended verifier. Included inside the JWS signed bytes so it cannot be stripped post-signature.

Verification rule (Section 9.1, step 6):

If the aud field is present, the verifier MUST confirm that aud matches its own URL or DID before accepting the attestation. If aud is absent, the attestation is treated as bearer — valid for any verifier. Providers issuing attestations for a specific gateway interaction SHOULD include aud; providers issuing standing attestations served from a .well-known endpoint MAY omit it.

This is complementary to jti, not redundant:

• jti prevents the same attestation from being consumed twice by the same gateway.
• aud prevents an attestation intended for Gateway A from being accepted by Gateway B.

Already implemented in @logpose-dev/a2a transport layer. @arian-gogani confirmed it's also shipped in the latest Nobulex release.

---

Reference implementation: github.com/logpose-dev/logpose

npm: @logpose-dev/logpose (core SDK), @logpose-dev/a2a (A2A transport layer with advertise, serve, evaluate)

Happy to adjust field names or TTL defaults based on WG feedback. Ready to land the crosswalk as a PR against aeoess/agent-governance-vocabulary and the aud addition against the RFC source whenever the WG is ready.

Please advise on next steps!