[Feature]: ScopeBlind Receipt Extension for Verifiable Agent Actions

[tomjwxf]

Is your feature request related to a problem?

Bindu's DID extension already signs artifact parts with Ed25519 (did.message.signature), proving "this agent said this." But there's no mechanism to prove "this action was authorized under a specific policy" or to verify receipts without trusting the signing agent. The DID signature proves identity but not authorization.

For enterprise deployments where Bindu agents act as microservices handling sensitive operations, teams need to answer: "Can you prove this agent was authorized to take this action, and can a third party verify that without trusting your infrastructure?"

Describe the solution you'd like

A ScopeBlindExtension (following the pattern of DIDAgentExtension and X402AgentExtension) that adds cryptographic receipt signing to Bindu agents:

from bindu.extensions.scopeblind import ScopeBlindExtension

config = BinduConfig(
    name="my-agent",
    extensions=[
        ScopeBlindExtension(
            mode="enforce",           # or "shadow" for logging-only
            cedar_policies="./policies/",  # Cedar policy directory
        )
    ]
)

What this adds on top of DID signing

	DID Extension (current)	ScopeBlind Extension (proposed)
Proves	"This agent said this"	"This action was authorized under policy X"
Signing	Agent's DID key	Issuer key (separate from agent identity)
Verification	Requires knowing the agent's DID	Issuer-blind -- verifier doesn't need to trust the issuer
Policy	None	Cedar (AWS's authorization engine)
Format	DID-specific	IETF Internet-Draft (open standard)

Integration surfaces

1. Extension system (bindu/extensions/) -- Most natural. Follows DIDAgentExtension pattern. Registers middleware, adds receipt metadata to task artifacts.
2. Middleware layer (bindu/server/middleware/) -- A ScopeBlindMiddleware that wraps task execution, evaluates Cedar policies, and attaches receipts to A2A responses.
3. TaskManager (bindu/server/task_manager.py) -- Task completion is where artifacts are produced. Receipt signing hooks here.
4. OpenTelemetry pipeline (bindu/observability/) -- @scopeblind/otel-exporter attaches receipt metadata as span attributes.

Receipts are issuer-blind

The key differentiator: ScopeBlind uses VOPRF (RFC 9497) for verification. A verifier can confirm a receipt is valid without knowing or trusting the issuer. This matters for Bindu's multi-agent mesh -- Agent A can verify Agent B's receipts without either trusting a central authority.

Describe alternatives you've considered

• Extending the existing DID extension to include policy assertions -- but DID signing proves identity, not authorization. Mixing the two creates a confused deputy problem.
• Custom middleware without a standard format -- works but receipts aren't portable or interoperable with other agent frameworks.

Additional context

• npm: protect-mcp (MIT licensed)
• PyPI: scopeblind (MIT, Python SDK)
• IETF Internet-Draft: draft-farley-acta-signed-receipts
• Merged into Microsoft Agent Governance Toolkit
• Demo: 30-second receipt chain

Happy to build a proof-of-concept extension. Bindu's extension architecture makes this straightforward -- the pattern is already established by DID and X402.

[vipul674]

I will work on this

[vipul674]

I have created a pr for this feature at #459

[desiorac]

Worth examining: verify_receipt() falls back to receipt.get("verification_key") when no key is passed explicitly. That means the verifier trusts the key embedded in the receipt being verified — which doesn't achieve "verify without trusting the signing agent" unless you source the key out-of-band.

For genuine third-party verification, you'd want the issuer to publish their verification key independently — agent card extension, DID document, or a signed manifest. VOPRF (the original spec) avoids the key distribution problem entirely, at the cost of complexity.

policy_hash has a parallel gap: it proves which policy ran, not what it says. Policy content publication or pinning would close that.

Building similar receipt infrastructure for multi-agent trust at ArkForge (arkforge.tech). The key distribution problem is where most implementations stall.

[tomjwxf]

@desiorac good catch, this needed clarification from me:

• Canonical @veritasacta/verify does NOT have this bug. It requires --key,--jwks, or --trust-anchor and refuses to trust a verification_key field embedded in the receipt body (source).
• draft-farley-acta-signed-receipts-01 is silent on key distribution, which is what allowed a conformant-looking fallback in this implementation.

The fix is in three places, all owed this week:

1. draft-02 will include a Security Considerations section with a normative "MUST NOT accept a verification key transported inside the receipt unless that key is independently anchored" requirement.
2. @veritasacta/verify 0.4.0 will emit an explicit error if a receipt body contains a verification_key field and no external key source was provided.
3. Negative conformance test vector will land inScopeBlind/agent-governance-testvectors showing the rejection.

Appreciate the stress-test, this is exactly the review the spec needs pre-WG-adoption.

Separately: the ArkForge work sounds directly adjacent. Once verify 0.4.0 and draft-02 land, happy to cross-check the key-distribution pattern against ArkForge's approach. The more implementations that converge on the same anchoring model, the faster the WG picks it up.

[raahulrahl]

Thanks @tomjwxf for the detailed write-up, @vipul674 for the PR, and
@desiorac for the careful review, the thread has been genuinely
useful.

Feature concept — we agree in principle

Separating identity attestation (what our DID layer does today) from
authorization attestation (what ScopeBlind proposes) is a real
distinction and a direction we want to invest in.

Concerns with the current shape of #459

1. verify_receipt() key fallback — as @desiorac flagged,
   falling back to receipt.get("verification_key") collapses the
   issuer-blind property. A verifier that accepts a key transported
   inside the receipt it's verifying isn't verifying anything a
   malicious issuer couldn't forge end-to-end.
2. policy_hash without policy content anchoring — the receipt
   commits to a hash but the verifier has no independent way to
   recover the policy text. Policy pinning or publication needs to
   be part of the wire format, not deferred to operator discipline.
3. VOPRF ↔ issuer-blind claim — VOPRF (RFC 9497) solves a
   different problem than "verify a signature without trusting the
   signer." Could you walk through specifically how VOPRF produces
   the issuer-blind property you describe? If the actual primitive
   is something else (BBS+, SD-JWT, a verifiable-credentials flow),
   the extension docs should say so precisely — this affects what
   review the code path needs.

Path forward we can support

If you want to land an initial version of this soon, we'd merge a
reduced form of the extension that is low-risk:

• Shadow mode only in the first iteration. No enforcement path.
  Receipts are produced, logged, attached to OpenTelemetry spans —
  but nothing in the task flow gates on them. That gives operators
  policy-attestation as observability without the extension becoming
  a trust surface before the verify path is hardened.
• Enforcement mode gated on a test vector that demonstrates
  rejection of receipts containing their own verification_key
  field. The negative-conformance vector @tomjwxf mentioned is
  exactly what we'd want here — we'd wire it into CI and make it a
  precondition for flipping the default.
• Wait for draft-02 and @veritasacta/verify 0.4.0 before the
  enforcement path lands. If the upstream spec doesn't actually
  update, that tells us the durability of the primitive and we can
  re-evaluate.
• Package boundary: we'd prefer this live as a separate
  installable extension (e.g. bindu-scopeblind) rather than inside
  bindu/extensions/ in the core repo. Our extensions system is
  designed for exactly this — it keeps the core review surface
  narrow and lets the extension iterate on its own version cadence.
  Happy to walk through the scaffolding for that if useful.

Let's sync

Given this has a few moving pieces (spec draft-02, a canonical
verify library with its own release, this PR, and how it fits into
Bindu's existing DID layer), I think a 30-minute call would move
faster than back-and-forth in comments. Happy to include:

• @tomjwxf to walk through the spec trajectory and the VOPRF role
• @vipul674 to walk through the PR
• @desiorac if they're interested — the review caught something
  concrete and the ArkForge angle on key distribution sounds
  directly relevant

Proposing sometime next week. Three slots that work on our side:

• Mon Apr 22, 10:00 UTC (11:00 BST / 12:00 CEST)
• Wed Apr 24, 14:00 UTC (15:00 BST / 16:00 CEST)
• Thu Apr 25, 08:00 UTC (09:00 BST / 10:00 CEST)

Agenda:

1. Shape of the shadow-mode-first plan — 10 min
2. Key-anchoring model (how the extension surfaces issuer keys —
   agent card extension? DID doc service endpoint? Independent
   manifest?) — 10 min
3. Test-vector hookup and what "ready to enable enforcement by
   default" looks like — 10 min

If a call doesn't work, I'll write the same questions up as inline
review comments on #459.

[tomjwxf]

Thanks @raahulrahl, this is a thoughtful review, and I want to address it all specifically.

The three technical concerns are now addressed in the updated stack:

1. verify_receipt() embedded-key fallback. Agreed unreservedly. @veritasacta/verify@0.5.0 is live on npm as of today (previously 0.3.0) with explicit embedded-key rejection: any payload carrying verification_key, issuer_key, or signer_public_key fails closed before signature check, even when an external --key/--jwks is provided. draft-farley-acta-signed-receipts-02 carries a normative Security Considerations section ("MUST NOT accept a verification key transported inside the receipt unless independently anchored"); submission to IETF datatracker this week. Negative conformance fixtures live at ScopeBlind/agent-governance-testvectors. The reference Bindu extension inherits the fail-closed posture and adds a require_conformance_check=True constructor flag that exercises a negative vector at init.

2. policy_hash without policy content anchoring. Agreed. The reference extension commits to policy_digest = sha256(concatenated .cedar source) but does not ship a policy-text publication mechanism. That's a design decision worth making on the call: policyManifestUrl field in the agent card extension, or a DID document service endpoint, or deferred to the operator. Both are viable.

3. VOPRF scope clarification. You were right to flag the conflation in the original issue text. The reference extension operates at conformance tier T1 (Ed25519 + JCS + chain linkage). It does not emit VOPRF tokens. VOPRF sits at a separate tier (T4) in the wider stack: full Schnorr DLEQ verification for both πI and πC is now in @veritasacta/verify@0.5.0 (shipped today alongside the Bindu extension), but issuance is a proprietary service, and the Bindu extension does not depend on VOPRF being reachable. If a future proposal wants VOPRF-backed Bindu receipts, that's a separate conversation with a different threat model.
On the shape of the plan. Your "shadow mode first, separate package, gated on draft-02 and verify updates" framing is exactly right. Rather than iterate against PR #459, I've scaffolded a clean reference package at ScopeBlind/bindu-scopeblind that bakes in all of the above:

Shadow mode is the default. Enforce requires explicit opt-in and a non-empty Cedar policy directory.
No embedded-key fallback anywhere. Construction fails closed if the build cannot prove rejection.
Four KeySource implementations for external key anchoring (agent card extension, DID document, JWKS, pinned trust anchor).
ScopeBlindExtension.agent_card_extension() publishes the issuer pubkey via an A2A extension block so verifiers never see it in the receipt body.

19 passing tests covering default posture, signing and chain linkage, embedded-key rejection, tamper detection, key resolution, and the agent card publication surface.

DESIGN.md walks through each of your three concerns specifically; CALL-AGENDA.md proposes an agenda mirroring your 10/10/10 structure.

On the call. Thu Apr 25 08:00 UTC works for me (I am in Perth, AU, so that is comfortable from the timezone side). Happy to include @desiorac if they want to join (the ArkForge key-distribution angle sounds directly relevant to agenda block 2). If @vipul674 wants to walk through #459 thinking, also welcome. Equally, if a written exchange here in comments is easier, I am fine with that.

On #459. I'd suggest closing with thanks to @vipul674 for the spike; the learnings land in the separate package and the review-surface constraints you described are real. Happy to defer to your judgment there.