[CG Report v1.6.2 draft] Vouch Protocol: Continuous State Verifiability for Autonomous AI Agents

Hello Credentials Community Group,

I would like to draw the group's attention to a Community Group Report
draft for Vouch Protocol, a continuous-state-verifiability layer for
autonomous AI agents built entirely on existing W3C primitives. The work
item has been filed at:

https://github.com/w3c-ccg/community/issues/259

The draft is at v1.6.2. It incorporates one round of pre-list review
feedback (folded into v1.6.1) along with subsequent editor polish. It is
co-authored & co-sponsored by Manu Sporny (Digital Bazaar).

*Reading surfaces:*

Repository: https://github.com/vouch-protocol/vouch
Report draft (Markdown):
https://github.com/vouch-protocol/vouch/blob/main/docs/specs/w3c-cg-report.md
Tagged release v1.6.2:
https://github.com/vouch-protocol/vouch/releases/tag/v1.6.2
1-page executive summary:
https://github.com/vouch-protocol/vouch/blob/main/docs/specs/cg-report-executive-summary.md
Google Doc (comments open):
https://docs.google.com/document/d/1KYmLoY9XIuVFIW2HvhtLCW551CIE_SxZ/edit?usp=sharing

*WHAT IT SPECIFIES*

   - A W3C VC Data Model 2.0 credential profile for autonomous agent intent
   attestation, signed with W3C Data Integrity (eddsa-jcs-2022).
   - DID-based agent identity (did:web and did:key as primary methods).
   - The Identity Sidecar pattern, which physically isolates private keys
   from the LLM context window.
   - Resource-bound delegation chains (Section 9), with explicit resource
   URI binding per link to prevent confused-deputy attacks.
   - The Heartbeat Protocol (Section 11), inverting the trust model from
   "Trusted until Revoked" to "Untrusted until Renewed."
   - An optional dual-proof post-quantum profile in which a credential
   carries two independent W3C Data Integrity proofs (eddsa-jcs-2022 and
   mldsa44-jcs-2026) on the same RFC 8785 JCS-canonicalized payload bytes.
   This aligns with the Digital Bazaar mldsa44-rdfc-2024-cryptosuite family.
   - An optional Algorithm Quorum Verification mode (Section 13.6)
   generalizing the dual-proof pattern to M-of-N cryptosuite diversity.

*WHAT IT DOES NOT DO*

   - It does not introduce new cryptographic primitives where existing W3C
   standards suffice.
   - It does not replace identity or authorization specifications. It
   composes with them. Appendix A details the relationship to W3C VC, W3C DI,
   W3C DIDs, ZCAP-LD, OAuth 2.1, BitstringStatusList, and C2PA.
   - It does not address developer-time tooling for AI coding assistants. A
   companion series of disclosures (PAD-048 through PAD-055) covers that
   adjacent space and is referenced informatively in Appendix A.1.

*REFERENCE IMPLEMENTATIONS*

Three implementations, all in the same repository, produce byte-identical
credentials given the same input:

   - Python (vouch/)
   - TypeScript (packages/sdk-ts/)
   - Go (go-sidecar/)

Cross-implementation interop test vectors are in tests/interop/.

*PRIOR ART*

A 60-PAD defensive disclosure portfolio (CC0) is published in
docs/disclosures/. Most are informative; selected disclosures are cited at
architectural decision points in the Report:

   - PAD-039: cross-implementation determinism
   - PAD-040: same-canonical-bytes property under the dual-proof carrier
   - PAD-041: Multikey algorithm-agnostic verification
   - PAD-043: cryptographic weight binding
   - PAD-045: RAG-anchored reasoning
   - PAD-046: algorithm quorum
   - PAD-047: verifiable-delay-function rate-limiting
   - PAD-059: Vouch-Amnesia attestation bridge
   - PAD-060: single-use audited override of egress block

*WHAT I AM ASKING FROM THE GROUP*

   1. Review. Comments on architecture, terminology, conformance language,
   security and privacy considerations are very welcome. The Google Doc above
   is open in commenter mode if you prefer inline comments; the GitHub repo
   accepts issues and pull requests.
   2. Implementer interest. If your organization is working on agent
   identity, agent authorization, or behavioral attestation, I would value an
   indication of interest (privately or on-list).
   3. CCG agenda time. I would like to present the architecture at an
   upcoming CCG call.  A 20-25 minute walkthrough plus discussion fits the
   standard agenda slot.

*STATUS*

Apache 2.0 licensed. Open to incorporation into the CCG's incubation
pipeline, including transition discussion when the group judges traction
supports it.

Thanks for the consideration. Replies to-list or off-list are welcome.

Best regards,
Ramprasad Gaddam
Editor, Vouch Protocol
ram@vouch-protocol.com
https://vouch-protocol.com
https://github.com/vouch-protocol/vouch