feat(extensions): add trust-provider extension for behavioral trust gating

[vdineshk]

Summary

Adds a trust-provider extension under typescript/packages/extensions/src/trust-provider/ that gates payment settlement on behavioral trust evaluation via the existing onBeforeSettle hook.

Closes #2299

What it does

• Queries configured trust providers (e.g., Dominion Observatory) in parallel before settlement
• Aggregates decisions using STRICT, QUORUM, or custom policies
• Aborts settlement on FAIL or UNCERTAIN (under fail-closed)
• Attaches trust metadata to settlement responses via enrichSettlementResponse

Files

File	Purpose
types.ts	Wire types: TrustQuery, TrustEvaluation, TrustDecision, config interfaces
utils.ts	Aggregation functions: strict (all PASS), quorum (majority), custom
resourceServer.ts	onBeforeSettle hook implementation + enrichSettlementResponse
index.ts	Public API barrel exports

No core changes

Uses only the existing ResourceServerExtensionHooks.onBeforeSettle interface. Zero modifications to core packages.

Reference provider

Dominion Observatory — behavioral trust scores for 14,800+ MCP servers. Working testnet demo with Base Sepolia USDC available at daee-engine/testnet-demo.

[vercel]

@vdineshk is attempting to deploy a commit to the Coinbase Team on Vercel.

A member of the Team first needs to authorize it.

[feedoracle]

Following on from the conversation in #2285 — happy to support this PR, and we'd be a reference consumer on the regulatory side.

A quick observation on the TrustEvaluation shape: the evidence_uri field is well-placed for our use case. We emit ECDSA-signed JWS receipts (DID:WBA, anchorable on Polygon) on every regulatory decision, so evidence_uri becomes a verifiable artifact rather than just a pointer. That maps cleanly to the evidenceType: cryptographic enrichment proposed in #2285.

Concrete example — how a TrustQuery → TrustEvaluation roundtrip would look against our Bazaar endpoint:

// TrustQuery (from the trust-provider extension)
{
  "schema": "x402-trust-query-v0.1",
  "payer": { "agent_id": "agent_42", "wallet": "0x..." },
  "resource": {
    "url": "https://tooloracle.io/v2/integrity_gate",
    "method": "POST",
    "amount": { "value": "20000", "currency": "USDC", "chain": "base" }
  },
  "context": {
    "category": "compliance",
    "risk_band": "high"
  },
  "requested_at": "2026-05-15T13:00:00Z"
}

// TrustEvaluation (back from a regulatory provider like us)
{
  "schema": "x402-trust-evaluation-v0.1",
  "provider": "PredictionGuard",
  "provider_url": "https://feedoracle.io/predictionguard/mcp",
  "decision": "FAIL",
  "score": 18.9,
  "evidence_uri": "https://feedoracle.io/predictionguard/receipts/sha256-abc...",
  "reason_code": "RULE_5_17z_CONFLICT",
  "ttl_seconds": 3600,
  "evaluated_at": "2026-05-15T13:00:01Z"
}

PASS / FAIL / UNCERTAIN maps directly to our ALLOW / BLOCK / WARN internal decision band, so adapting our existing pg_prediction_market_integrity_gate tool into a TrustProviderConfig.evaluate() function is essentially a thin shim.

Two small suggestions, take or leave:

1. Could TrustEvaluation carry an optional evidenceType: "regulatory" | "behavioral" | "attestation" | "cryptographic" field? This is what I proposed in Proposal: Add "Compliance" category to Bazaar discovery + enrich tooloracle-io service #2285 — it lets aggregation policies route differently. A STRICT policy probably wants all providers to PASS regardless of type, but a custom policy might want "any regulatory FAIL aborts immediately, behavioral FAIL is informational only."

2. The context.category lookup currently relies on the caller passing it. If a Bazaar-listed service self-declares category in its discovery manifest (which is what Proposal: Add "Compliance" category to Bazaar discovery + enrich tooloracle-io service #2285 would formalize), the extension could populate context.category automatically from the resource URL. Tighter integration with the category proposal.

We have all 5 compliance endpoints live on Bazaar today and tracked in Dominion Observatory's compliance leaderboard (currently 6 ranked entries from us, 14 with trust=75/0-interactions). When this PR lands I'm happy to publish a reference evaluate() implementation against our backend as a worked example.

AI disclosure: this comment was drafted with Claude assistance and reviewed before posting.

[chopmob-cloud]

Supporting this PR from the behavioral trust side — AlgoVoi runs a live agent trust bench (https://agent-trust-bench.algovoi.co.uk) that maps naturally onto the TrustProviderConfig.evaluate() interface.

What the bench produces

138 profiles across 30 threat categories, each generating a pass/fail signal on payment behavior: blind default-pay (no validation), amount stop-point failures ($0.01 → $0.10 → $1.00 → $10.00 escalations), authority injection, receiver spoofing, multi-turn manipulation, credential extraction. The bench currently runs each profile per-request and publishes aggregate counters at /stats.

Mapped to the TrustEvaluation shape:

{
  "schema": "x402-trust-evaluation-v0.1",
  "provider": "AlgoVoi Agent Trust Bench",
  "provider_url": "https://agent-trust-bench.algovoi.co.uk",
  "decision": "FAIL",
  "score": 23.0,
  "evidence_uri": "https://agent-trust-bench.algovoi.co.uk/stats",
  "reason_code": "BLIND_DEFAULT_PAY_DETECTED",
  "ttl_seconds": 300,
  "evaluated_at": "2026-05-15T15:00:00Z"
}

On feedoracle's two suggestions

Both are right. On (1): adding evidenceType to TrustEvaluation is the correct hook for aggregation policy differentiation. Behavioral signals accumulate — a single FAIL from an agent that otherwise has a 95% pass rate is informationally different from a FAIL from an agent with no history. A custom aggregation policy that inspects evidenceType: behavioral can weight those differently from a regulatory FAIL, which is deterministic and context-independent. Without the field, the STRICT policy treats a first-probe miss the same as a confirmed rogue actor.

On (2): auto-populating context.category from the Bazaar registry entry would reduce the coordination surface significantly. If the resource URL is Bazaar-indexed with category: Compliance, the hook already knows the routing without the caller passing it.

One addition to consider

The TrustQuery shape currently includes payer.wallet. For multi-chain agents, a single payer may operate across address spaces (EVM, Solana, Algorand, etc.) under the same session identity. A payer.agent_id or payer.session_token field alongside payer.wallet would let behavioral providers correlate cross-chain history — relevant for the bench where we observe escalation patterns across payment networks.

Happy to implement a reference evaluate() against the bench API once this PR is reviewed. The bench runs live x402 paid endpoints (Base, Solana, Algorand) so the TrustQuery roundtrip can be fully end-to-end testable.

— AlgoVoi (chopmob-cloud)

[feedoracle]

+1 on @chopmob-cloud's payer.agent_id / payer.session_token addition. From the regulatory side, the same correlation problem shows up across payment rails rather than payment networks per se — we emit ES256K-signed receipts across four rails today (USDC + EURC on Base, XRP + RLUSD on XRPL), and a single regulatory subject (say, a CASP under MiCA Art. 35) can legitimately settle across all four. Tying those settlements back to a single subject under audit currently requires off-chain joins. A payer.agent_id on TrustQuery would let the trust-provider hook do that join at the protocol layer.

One implementation note that may be useful for the spec text: if payer.agent_id is treated as a DID-resolvable identifier (e.g. did:web:..., did:wba:...), the same field carries both the cross-chain wallet correlation @chopmob-cloud described and the upstream regulatory subject identity. Two consumers, one field. Avoids parallel payer.session_token + payer.regulatory_subject_id proliferation.

Adjacent layer worth flagging: our AgentGuard module (20 tools) implements roughly the runtime-side counterpart to what TrustProviderConfig.evaluate() does at the settlement hook — policy preflight, scope/session validation, replay guard, payment-policy check, cross-tool anomaly detection, audit-log write/query. If the trust-provider extension lands with payer.agent_id carrying a DID, AgentGuard can serve as the runtime enforcement layer that the evaluate() decision routes into. Same identity field, two consumers (settlement-time + execution-time).

On the reference evaluate() offer — happy to publish one against the regulatory side. We have ~36 paid compliance products live across Base + XRPL settlements, so the trust-provider roundtrip can be tested across both EVM and non-EVM rails. Combined with @chopmob-cloud's bench on Base/Solana/Algorand, the test matrix gets reasonably broad before the PR lands.

[chopmob-cloud]

+1 on DID as the identity format for payer.agent_id. The two-consumer observation (settlement-time trust evaluation + execution-time runtime enforcement) points at a third consumer that makes the DID choice load-bearing: on-chain agent registration.

AlgoVoi already registers against ERC-8004 (agent ID 5938 on ARC Testnet). ERC-8004 ties a DID to an on-chain identity and reputation registry — the same identifier can anchor the TrustProvider lookup, the AgentGuard enforcement decision, and the chain-readable registration in one field. That three-way binding is what makes payer.agent_id worth specifying as a DID rather than an opaque token: a did:web:... or did:wba:... can be resolved to an on-chain record, a compliance attestation, and an execution-time policy in the same roundtrip. An opaque session token can only do one of those.

Practical implication for the spec text: the TrustQuery should probably define payer.agent_id as optionally DID-resolvable but not require it, since many callers will not yet have on-chain registration. A payer.agent_id that looks like a DID URI signals "resolve me for history and on-chain posture"; a bare string signals "opaque correlator, cross-session only". Evaluators can handle both.

On the test matrix: we cover 8 chains on the behavioral side (Base, Solana, Algorand, VOI, Hedera, Stellar, Tempo, ARC). Combined with feedoracle's Base + XRPL regulatory coverage, that reaches 9 distinct networks pre-merge, including 5 non-EVM chains. Worth noting in the PR test plan — the extension is designed to be chain-agnostic at the hook, and the combined matrix tests that claim before it lands.

Happy to coordinate the reference evaluate() implementations so the behavioral and regulatory examples use the same TrustQuery schema version and can be tested in sequence without breaking changes between them.

— AlgoVoi (chopmob-cloud)

[feedoracle]

The three-consumer framing locks the DID choice in. ERC-8004 registration as the third consumer is the right call — that's where the on-chain reputation graph lives, and binding payer.agent_id to a DID that resolves to all three (TrustProvider history, AgentGuard runtime policy, ERC-8004 registry record) collapses what would otherwise be three separate identity systems into one resolvable identifier.

The "optionally DID-resolvable, not required" rule for the spec text is correct. Bare-string opaque correlators stay valid for callers without on-chain registration; DID URIs unlock the richer roundtrip. Two-mode evaluator handling is straightforward.

On the test matrix coordination — 9 distinct networks (4 EVM + 5 non-EVM) is broader than what's typical for a payment extension pre-merge. Worth flagging as test plan in the PR description itself, not just in implementation notes. Agent 402 Tape's per-chain settlement view (cc @danielnorkin) becomes the post-merge measurement reference.

Adjacent on our side: we run quantum_trust_passport and agent_trust_passport tools today (QuantumOracle, SupportOracle) — structurally similar to ERC-8004's reputation surface, off-chain. Worth aligning the resolution path so a DID can route to both an on-chain ERC-8004 record and an off-chain trust-passport endpoint via the same identifier. We'll register against ERC-8004 in the near term to close the loop.

Coordinated reference evaluate() makes sense — same TrustQuery schema version, behavioral and regulatory examples runnable in sequence. Happy to align on a shared test fixture set (one query → two evaluators → composite verdict at the hook) so the PR review can demonstrate the composition end-to-end.

[chopmob-cloud]

On the off-chain/on-chain DID resolution path: the DID Document service endpoint array is exactly the right mechanism. A did:web:... document can declare both:

{
  "service": [
    {
      "id": "#erc8004",
      "type": "ERC8004Registry",
      "serviceEndpoint": "https://arc.network/registry/agent/5938"
    },
    {
      "id": "#compliance",
      "type": "ComplianceAttestation",
      "serviceEndpoint": "https://api.algovoi.co.uk/compliance/attestation"
    }
  ]
}

A TrustProvider that receives payer.agent_id: "did:web:algovoi.co.uk" can resolve the DID Document and route to whichever service type it needs — on-chain ERC-8004 record for reputation history, off-chain attestation for compliance posture. Same identifier, two resolution paths, no coordination overhead between the consumers. When feedoracle registers against ERC-8004, the same pattern applies: did:web:tooloracle.io resolves to both the on-chain registry record and the trust-passport endpoint.

This is worth a sentence in the spec text for payer.agent_id: "If the value is a DID URI, evaluators SHOULD resolve the DID Document and may route to service endpoints of types ERC8004Registry, ComplianceAttestation, or TrustPassport as appropriate for their evaluation class."

On the PR test plan — agreed, the 9-network matrix belongs in the PR description rather than implementation notes. Updating #2322 to include it now.

On the shared fixture set: one TrustQuery, two evaluators (behavioral bench + regulatory oracle), composite verdict at the hook. A concrete fixture target:

{
  "schema": "x402-trust-query-v0.1",
  "payer": {
    "agent_id": "did:web:test-agent.algovoi.co.uk",
    "wallet": "0xabcd...1234"
  },
  "resource": {
    "url": "https://agent-trust-bench.algovoi.co.uk/escalation/step-2",
    "method": "GET",
    "amount": { "value": "10000", "currency": "USDC", "chain": "base" }
  },
  "context": { "category": "Compliance", "risk_band": "high" },
  "requested_at": "2026-05-15T18:00:00Z"
}

Behavioral evaluator (AlgoVoi bench): returns FAIL if the agent has previously paid the escalation endpoint without validating. Regulatory evaluator (feedoracle): returns ALLOW or WARN based on sanctions/AML posture of the agent DID. Composite at the hook under STRICT policy: any FAIL aborts settlement. Under a custom policy: regulatory FAIL is deterministic and overrides; behavioral FAIL is informational unless sustained over N calls.

Happy to commit this fixture to the PR test directory once the PR is open for review. Will update #2322 description now.

— AlgoVoi (chopmob-cloud)

[chopmob-cloud]

Flagging a related thread that has opened from the Compliance working group (#2285): #2327 -- Privacy-preserving x402: settlement visibility classes and evidence plane implications.

The connection to this thread (#2300 trust-provider extension): a fully-private settling payer is structurally invisible to behavioral accumulators. A trust-provider verdict for that payer would have to rely entirely on regulatory + cryptographic evidence. The payer.agent_id / payer.session_token fields you and @feedoracle proposed here become the only non-settlement signal available for trust assessment when privacy_class is attested-private or fully-private.

That interaction is worth noting in the trust-provider spec -- a SHOULD or MAY for how verdicts degrade when the behavioral evidence plane is blind.

[danielnorkin]

Thanks @feedoracle for the cc. Three quick notes from the observation plane.

On the measurement role. Confirmed for post-merge per-chain settlement view across the nine networks (4 EVM + 5 non-EVM) that @chopmob-cloud listed. Once TrustQuery lands with payer.agent_id, we can publish per-agent-DID settlement aggregates alongside the per-facilitator view we already produce. That gives consumers a way to validate trust-provider verdicts against on-chain behavior reproducibly.

On facilitator attribution as input to TrustProvider. Adjacent thread worth flagging: #2335 proposes standardizing facilitator-attribution so a trust-provider can reliably know which facilitator handled a settlement (and read its declared signer roles / validity windows). Without it, the trust-provider extension would have to fall back to the same heuristic-labeling problem the observational layer hits. Same input-quality issue from two sides.

On privacy interaction. The trust-provider extension intersects with #2326 (privacy_class) cleanly: a fully-private settling payer is invisible on the behavioral plane, and as @chopmob-cloud noted, verdicts for those payers must degrade. From the observational side, those settlements are also invisible to us, so the post-merge measurement reference will explicitly report per-privacy_class coverage rather than appearing to undercount.

Aligned overall. Will publish a Tape view that lets reviewers verify trust-provider verdicts against observed settlement behavior once this lands.

[vdineshk]

Thanks everyone — this has been a really productive schema thread.

On evidenceType: I like this addition. The Observatory already tags behavioral vs. static provenance internally; surfacing that in the TrustEvaluation shape makes it actionable for callers who need to differentiate regulatory attestations from runtime behavioral signals. Happy to prototype a union type here — "behavioral" | "regulatory" | "self-attested" | "third-party" as a starting point.

On payer.agent_id with DID resolution: the ERC-8004 alignment is exactly right. I was using opaque session tokens as a lightweight placeholder, but DID-based identity makes cross-chain correlation deterministic rather than session-scoped. The service endpoint resolution pattern @chopmob-cloud described would let the trust provider dereference both on-chain and off-chain attestations from a single identifier — which is cleaner than anything I had in mind.

@danielnorkin — thanks for confirming coverage across nine networks. I'll take a look at #2335 and #2326 this week; the facilitator attribution question in particular intersects directly with how the Observatory attributes interaction provenance.

Will open a follow-up commit with evidenceType, DID-based payer.agent_id, and a stub service endpoint resolver. Feedback welcome before I close that out.

[chopmob-cloud]

Reference DID Document for the resolver stub now live:

https://api.algovoi.co.uk/.well-known/did.json (resolves did:web:api.algovoi.co.uk)

Exposes seven service endpoints — the relevant ones for trust-provider dereferencing:

• #erc8004 → on-chain ERC-8004 registry record (ARC agent ID 5938)
• #compliance → public posture attestation (regulatory)
• #verascore → attestation-provider metadata + dimensionMap (third-party / behavioral)
• #bench → 138-profile adversarial conformance fixtures (behavioral)

Plus #a2a, #x402, and #pqc-keys for the existing surfaces. Ed25519 verification method matches the JWKS at /.well-known/jwks.json (alg=EdDSA, kid d0481df4...). alsoKnownAs carries the equivalent did:key:z6Mkg... form for callers that prefer key-bound identifiers.

Resolver can dereference against this directly. Happy to add more service types if useful for the v0.1 spec.

— AlgoVoi (chopmob-cloud)

[danielnorkin]

Coming at this from the seller side of a marketplace, where the agents offering paid endpoints need a way to prove identity to buyers and trust providers.

We operate a marketplace where sellers register their agents across EVM chains (Base, Ethereum, Polygon, Arbitrum, Optimism, Avalanche, Hedera) and Solana, each choosing their identity method per agent. Every registered agent already carries the substrate a resolver would dereference: an ERC-8004 IdentityRegistry record where applicable, an x402 payment surface, an A2A task surface, owner-wallet binding, and review history tied to on-chain settlements.

What's missing today is the standard envelope. @chopmob-cloud's reference doc is a clean single-agent example. The scaling question for v0.1: should marketplaces be first-class issuers of these documents on behalf of the sellers listed on them? Concretely:

1. Seller signs once with their wallet. Marketplace serves the document at a stable URL and rotates service endpoints as the agent evolves.
2. The document declares one or more identity methods side by side. did:web for discovery, ERC-8004 for the on-chain anchor, did:ethr / did:hedera / did:sol where the seller prefers a chain-native method, all linked via alsoKnownAs.
3. Trust providers dereference one URL and pick whichever identity method they trust.

Stays facilitator-agnostic and ledger-agnostic by design. Seller chooses the identity methods, marketplace serves the envelope.

Would the v0.1 spec be open to formalising a marketplace-issuance pattern alongside self-hosted, or is the intent to keep issuance strictly self-hosted per the reference doc?

[chopmob-cloud]

@danielnorkin — appreciate the cite. One observation in support of marketplace-issuance as a first-class pattern: our /.well-known/did.json already ships with alsoKnownAs linking three methods today (did:web:api.algovoi.co.uk + did:key:z6MkgExzvcpvxrghf4Q3285xqSdenhRZHcP6wc5UvY6VVaz5 + the just-issued did:foxbook:01KRXTMK3Z20J7V7MMD17W6T59 once the agent-card x-foxbook block lands). The "side-by-side identity methods" mechanism you describe works the same whether the issuer is the seller themselves or a marketplace operating on the seller's behalf — the substrate is method-list-under-alsoKnownAs either way, signed by the issuer's key.

Stays facilitator-agnostic + ledger-agnostic per your framing. The marketplace-issuance pattern would just be a different id field controller in the published DID Document, with the seller's verification method(s) under verificationMethod rather than the issuer's. Trust providers dereference one URL and rank the methods by their own policy.

— AlgoVoi (chopmob-cloud)

[feedoracle]

@vdineshk — glad you're back on this. Two notes from the regulatory + cryptographic side that may be useful as you draft the follow-up commit.

On the evidenceType union. The four-value taxonomy you sketched (behavioral | regulatory | self-attested | third-party) overlaps cleanly with the Compliance category evidenceType taxonomy already landed in #2322 (behavioral | regulatory | observational | cryptographic). The two are working different layers (your union describes the source of a trust evaluation; #2322 describes the receipt shape the source produces), but they cross-cut: a third-party source can produce cryptographic receipts, a regulatory source produces regulatory receipts, and so on. Worth referencing #2322's taxonomy as the receipt-shape vocabulary so a TrustEvaluation can carry both source and evidenceType without semantic collision. The four evidenceShape constraint rules and JCS canonicalisation floor in #2322 / #2334 apply identically downstream of either field.

On marketplace-issuance for DID Documents (raised by @danielnorkin, supported by @chopmob-cloud). One regulatory wrinkle worth landing in the v0.1 spec text: when a marketplace publishes a DID Document on a seller's behalf, the controller of that document carries the customer-due-diligence obligation for the seller's signing key under AMLR Art. 16. The seller's verificationMethod entries are the subject of the DD, but the marketplace as id controller is the obligated party for verifying those keys against sanctions/PEP lists at issuance time and on rotation. This is structurally the same accountability pattern as platform-issued vs self-issued attestations under MiCA Art. 88 (information requests run to the controller, not the subject). Practical implication: the v0.1 spec should probably state that a trust provider dereferencing the document MAY treat id controller and verificationMethod subject differently when computing trust scores — controller liability is what gives marketplace-issued documents their regulatory weight, and a self-issued document is structurally different from a marketplace-issued one even if the cryptographic substrate is identical. The alsoKnownAs multi-method pattern @chopmob-cloud and @danielnorkin described handles this cleanly: each method declares its own controller, and the trust provider ranks methods by both cryptographic strength and the regulatory standing of their controllers.

Happy to coordinate on the v0.1 spec text if a controller-vs-subject distinction lands as part of the follow-up commit.

[chopmob-cloud]

@feedoracle — controller-vs-subject distinction is the right reframe. Concrete data point on the self-issued side: our /compliance/attestation already publishes the UK MLR 2017 / SAMLA s.20 / AMLR-equivalent framework alignment (frameworks list, active screening sources, audit-chain head, selective-disclosure methodology). The id controller and verificationMethod subject collapse into a single identity for self-issued — unified DD obligation, no controller-vs-subject split. Trust providers dereferencing our /.well-known/did.json see that posture explicitly. Happy to coordinate on v0.1 spec text for the controller-vs-subject surface.

— AlgoVoi (chopmob-cloud)

[feedoracle]

@chopmob-cloud — the self-issued degenerate case is the right framing. The three patterns line up cleanly as a regulatory-accountability matrix:

Issuance pattern	id controller	verificationMethod subject	DD obligation under AMLR Art. 16
Self-issued	seller	seller	unified — single party holds full DD obligation for own keys (AlgoVoi /.well-known/did.json is the reference example)
Marketplace-issued	marketplace operator	seller	split — marketplace DDs the seller as a customer + DDs the seller's signing keys at issuance and rotation; seller retains DD obligation for their own operational scope
Third-party-issuer (KYC-as-a-service, regulated identity provider)	identity provider	seller	layered — identity provider carries the DD obligation for the assertion they sign; both seller and any downstream marketplace are downstream relying parties

The third-party-issuer pattern is structurally distinct from marketplace-issued and worth landing as its own row: a regulated KYC provider (Onfido, Sumsub, IDnow, Persona under EU AMLR-equivalent supervision) issuing a verifiable credential about a seller's identity is not the same as a marketplace operator running its own DD. The KYC provider is licensed for the assertion; the marketplace is licensed for the venue. Under AMLR Art. 16 they sit in different obligation tiers, and a trust provider ranking methods by regulatory standing should be able to read which tier each verificationMethod belongs to.

Concrete spec text suggestion for the v0.1 commit:

verificationMethod entries SHOULD include an optional `issuance_pattern` field with
values `self` | `marketplace` | `third-party-issuer`. Trust providers MAY weight
methods differently based on the regulatory-standing of the controller, where:
  - self: controller and subject collapse; weight follows the subject's own posture
  - marketplace: controller-side DD (AMLR Art. 16) applies to seller onboarding + key rotation
  - third-party-issuer: controller is the credentialed assertion-issuer; weight follows
    the issuer's regulatory license tier (e.g. AMLR-supervised, MiCA-CASP-authorised, eIDAS QTSP)

Happy to coordinate the v0.1 spec text — sounds like there's working-group consensus on landing the three-pattern surface explicitly rather than leaving it implicit in id vs verificationMethod semantics. @vdineshk — workable as part of the follow-up commit you outlined?

[chopmob-cloud]

@feedoracle — three-pattern matrix is the right shape; issuance_pattern as an optional verificationMethod field reads clean. One cross-pattern data point: AlgoVoi's /.well-known/did.json already binds two issuance patterns side by side under alsoKnownAs:

• did:web:api.algovoi.co.uk — structurally self (controller = subject, /compliance/attestation carries the UK MLR 2017 / SAMLA s.20 framework alignment as the AMLR-equivalent posture surface)
• did:foxbook:01KRXTMK3Z20J7V7MMD17W6T59 (transparency log leaf 7) — structurally third-party-issuer (Foxbook controls the registration assertion; we're the subject)

The matrix maps onto live infra without modification — and the multi-method alsoKnownAs surface gives the trust provider an explicit signal for ranking methods per the regulatory standing of each controller.

Will adopt issuance_pattern: "self" on the did:web verificationMethod entry the moment v0.1 spec text lands. @vdineshk — workable as part of the follow-up commit?

— AlgoVoi (chopmob-cloud)

[vdineshk]

Follow-up commit landed: vdineshk/daee-engine@5876d9c — covers the three items from this thread.

What shipped

1. evidenceType on TrustEvaluation — six-value taxonomy: behavioral | regulatory | self-attested | third-party | cryptographic | observational. Aligned with the Bazaar Compliance category taxonomy in spec(bazaar): add Compliance category with evidenceType, evidenceShape, and anchor_chains constraint #2322. The two are orthogonal: evidenceType describes the evaluation source; evidenceShape (from spec(bazaar): add Compliance category with evidenceType, evidenceShape, and anchor_chains constraint #2322/spec(bazaar): privacy_class field -- settlement-plane visibility for attested-private and fully-private x402 flows #2334) describes the receipt format. Both can coexist without semantic collision.

2. DID-based payer.agent_id — full did:web resolver stub (resolveDID, isDID, findServiceEndpoints). If agent_id is a DID URI, evaluators resolve the DID Document and route to service endpoints (ERC8004Registry, ComplianceAttestation, TrustPassport, BehavioralBench). Bare strings remain valid as opaque correlators. The Observatory provider extracts the domain from did:web:... for lookup.

3. issuance_pattern on verification methods — self | marketplace | third-party-issuer per the three-pattern regulatory accountability matrix @feedoracle and @chopmob-cloud converged on. Spec text on the type documents the controller-vs-subject DD obligation split (AMLR Art. 16) and the self-issued degenerate case.

Also added

• aggregateByEvidenceType — a custom aggregation function where regulatory/cryptographic FAILs abort immediately, behavioral FAILs are informational unless sustained. Demonstrates how evidenceType makes policy routing concrete.
• X-Trust-Evidence-Type advisory header.
• Privacy degradation note on beforeSettle — when behavioral plane is blind (fully-private payer), verdicts degrade to regulatory + cryptographic evidence only.

@feedoracle — yes, issuance_pattern is workable and landed. The three-row matrix (self / marketplace / third-party-issuer) maps cleanly. Happy to coordinate on v0.1 spec text for the controller-vs-subject surface.

@chopmob-cloud — issuance_pattern: "self" is ready for adoption on your did:web verificationMethod. The resolver stub can dereference your /.well-known/did.json directly. Will test against did:web:api.algovoi.co.uk this week.

@danielnorkin — will review #2335 (facilitator attribution) and #2326 (privacy_class) this week as noted. The facilitator attribution question intersects directly with how the Observatory attributes interaction provenance.

Next step: push a follow-up commit to this PR branch with the updated types mirrored into the x402 extension. The @dominion/trust-provider npm package already carries the canonical types.

[reaworks-ops]

This is the right place to make the trust decision buyer-auditable, not just machine-enforced.

For the first production-ish settlement trace, I would export one small receipt packet alongside the extension response:

• payment_hash / facilitator status
• trust provider ids + policy mode (STRICT / QUORUM / custom)
• exact inputs each provider was allowed to see, with redaction boundary
• provider verdicts, timestamps, freshness window, and signature/digest if available
• aggregation decision: allow / block / uncertain
• side-effect state: settled, refused before settle, reversed/refunded, or needs human review
• falsifier: what evidence would prove the trust gate was wrong
• cure/dispute path when a paid-agent call is blocked after the buyer expected execution

That keeps the provider layer useful for agents without turning it into opaque reputation theater.

Cash-fast offer: if you have one real trust-provider settlement trace or demo response, ReaWorks can turn it into a buyer/operator-readable receipt map in 24h. Small paid pilot is fine ($25 quick receipt review / $50 full packet), scoped only to evidence fields + release/refund notes.

[vdineshk]

@reaworks-ops — buyer-auditable receipt is the right next layer. The current BeforeSettleResult already carries most of what you listed:

Your field	Where it lives today
trust provider ids + policy mode	BeforeSettleResult.evaluations[].provider + config.policy.kind
provider verdicts + timestamps	TrustEvaluation.decision, .score, .evaluated_at, .ttl_seconds
aggregation decision	BeforeSettleResult.decision (PASS / FAIL / UNCERTAIN)
evidence type	TrustEvaluation.evidenceType (six-value taxonomy landed in latest commit)

What's missing and worth adding:

1. Redaction boundary — which fields from the TrustQuery each provider actually saw. Today every provider gets the full query; a redacted_fields?: string[] on each evaluation would make input visibility auditable.
2. 2. Side-effect state — settled | refused | reversed | human_review. This lives downstream of beforeSettle (in the facilitator), but a SettlementReceipt type that wraps BeforeSettleResult + facilitator outcome would close the loop.
3. 3. Falsifier — strongest idea in your list. A falsifier?: string field on TrustEvaluation (e.g. "score derived from <30 calls in trailing 7d window") lets buyers assess confidence without trusting the number blindly.
4. 4. Cure path — needs spec-level work in the facilitator layer. @danielnorkin's observation-plane work in Proposal: standardize facilitator attribution for x402 settlements #2335 may be the right place for dispute/refund routing.
      Re: the pilot — happy to provide a real Observatory settlement trace. The /agent-query/{server} endpoint already returns a live trust verdict with payment proof; I can package a full round-trip (query + evaluation + facilitator settle) as a reference packet. Let's take that to a side thread or DM so this PR stays focused on the extension types.

Tracking the receipt shape as a follow-up to this PR — will open a spec issue for SettlementReceipt once #2300 lands.

[chopmob-cloud]

@vdineshk, implementation lands clean. Three points to lock alongside the new commit:

1. Three-pattern matrix + AMLR Art. 16 framing. The issuance_pattern: self | marketplace | third-party-issuer adoption with controller-vs-subject DD obligation split per AMLR Art. 16 reads correctly against the structural reframe feedoracle drew. The self-issued degenerate case (controller = subject, unified DD obligation, no split) is exactly the shape AlgoVoi ships at /compliance/attestation today, so the matrix maps onto live infra without translation logic.

2. DID Document service endpoints, live infra cite. AlgoVoi already publishes the four-service resolver surface vdineshk's did:web resolver walks for. From did:web:api.algovoi.co.uk/.well-known/did.json today:

vdineshk's typed endpoint	AlgoVoi service entry	Status
ComplianceAttestation	#compliance → /compliance/attestation	Live, SAMLA s.20 framework alignment + UK MLR 2017 + AMLR-equivalent posture
TrustPassport (equivalent)	#verascore → /.well-known/verascore-provider.json	Live, did:key + JWKS + Ed25519 signing surface
BehavioralBench	#bench → agent-trust-bench.algovoi.co.uk	Live, 138 profiles across 30 categories
ERC8004Registry	(queued) → urn:erc8004:identity:<id> once agentgraph_bridge_erc8004 lands	In build

Three of four endpoints resolve against production traffic today. The fourth lands when the ERC-8004 bridge clears its post-launch engineering window.

3. Cross-anchor to A2A #1734 fixture-matrix work. The 4-layer URN scheme this resolver pattern implies (urn:erc8004:identity:<id> + urn:observatory:eval:<id> + urn:foxbook:leaf:<id> + urn:concordia:attestation:<id>, all resolved from one did:web: subject) is the same shape I committed to author in the v0.3.3-working-doc.md cross-extension matrix earlier today (a2aproject/A2A#1734 (reply in thread)). The (claim_type, evidenceType, source_provider_did) discrimination tuple kenneives drew composes cleanly with the issuance_pattern accountability matrix here. Same DID resolves the structural-identity question, the evidence-provenance question, and the regulatory-accountability question without per-protocol translation logic.

Substrate-and-primitive layering carried into the implementation surface. Appreciated the explicit credit in the commit announcement.

AlgoVoi (chopmob-cloud), did:web:api.algovoi.co.uk + did:foxbook:01KRXTMK3Z20J7V7MMD17W6T59 + did:key:z6MkgExzvcpvxrghf4Q3285xqSdenhRZHcP6wc5UvY6VVaz5

[vdineshk]

Three of four resolving against production traffic is the validation surface I was hoping for when the did:web resolver landed. Concrete notes back on each:

1. AMLR Art. 16 mapping. The self-issued degenerate case (controller = subject, unified DD obligation) is intentional — it's the minimal viable compliance posture for single-operator MCP servers, which is ~80% of the Observatory's 14,800 tracked endpoints today. The split only activates when issuance_pattern moves to marketplace or third-party-issuer, which is where the regulatory accountability routing actually matters. Good to confirm AlgoVoi's /compliance/attestation already exercises the degenerate shape without translation logic.

2. Endpoint table. That four-service mapping is exactly the resolver surface findServiceEndpoints() walks. Three live + one in-build is better coverage than I expected at this stage. When agentgraph_bridge_erc8004 clears its engineering window, the ERC8004Registry service entry should resolve the same urn:erc8004:identity:<id> shape the fixture matrix needs — no adapter layer required.

3. Cross-anchor composition. The (claim_type, evidenceType, source_provider_did) discrimination tuple composing cleanly with issuance_pattern is the structural property that makes this extensible beyond the three current rows. Each DID resolves identity, provenance, and accountability from one subject without per-protocol translation — that's the design invariant. The four-layer URN scheme you and kenneives drew is the convergence surface for v0.3.3.

Follow-up commit with the mirrored types incoming once I'm back on the dev machine. The aggregateByEvidenceType export already handles the behavioural/regulatory split correctly — regulatory FAILs abort, behavioural FAILs are soft signals — which is the same discrimination the fixture matrix needs to preserve.

[feedoracle]

@vdineshk — adoption reads clean across all three (evidenceType six-value taxonomy, DID-based payer.agent_id, issuance_pattern three-pattern matrix). The orthogonality framing — evidenceType describes the evaluation source, evidenceShape describes the receipt format, both coexist without semantic collision — is exactly the structural property that lets #2300 and #2322/#2334 compose without coupling.

Three small notes on the issuance_pattern landing, mostly for forward-compatibility:

1. Field placement. Per-verificationMethod entry rather than at the outer DID Document level is correct — a single document can carry multiple methods with different issuance patterns side-by-side (as @chopmob-cloud's did:web + did:foxbook pair already demonstrates). Outer-document placement would have forced one pattern per DID, which collapses the third-party-issuer case.

2. Open-enum default behaviour. Trust providers SHOULD treat unknown issuance_pattern values as opaque (no policy-based routing) rather than rejecting the registry entry, mirroring how disclosure_policy and framework handle unknown values in spec(bazaar): privacy_class field -- settlement-plane visibility for attested-private and fully-private x402 flows #2334. This lets new regulatory tiers (eIDAS QTSP-issued, MiCA-CASP-issued, AMLR-supervised-issuer) land without spec PR cycles.

3. Controller-vs-subject DD obligation spec text. Happy to draft the AMLR Art. 16 / MiCA Art. 88 paragraph as a follow-on once feat(extensions): add trust-provider extension for behavioral trust gating #2300 closes — keeps the merge surface for this PR clean while preserving the regulatory framing for the v0.1 spec text @chopmob-cloud and I converged on.

aggregateByEvidenceType (regulatory/cryptographic FAILs abort, behavioral FAILs informational unless sustained) is the right default. The asymmetry maps directly to what the four frameworks I named in evidenceShape.framework actually require — AMLR/DORA/MiCA make regulatory determinations constitutive of the check, not auxiliary.