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

Unfortunately, this specification makes the common error of limiting the
delegation depth.  The result is a system that is harder to use and less
secure.  One way to think of the issue is to recognize that blocking
delegation makes attenuation difficult.

Say that agent A is at the limit of the delegation chain, has query and
update permissions on some object, and wants to use another agent B that
only needs query permission.  Since agent A can't delegate, it can
effectively share its credentials by blindly proxying whatever requests it
receives from agent B.

--------------
Alan Karp


On Sun, May 31, 2026 at 2:43 PM Ramprasad G <ram@vouch-protocol.com> wrote:

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