- From: Ramprasad G <ram@vouch-protocol.com>
- Date: Wed, 3 Jun 2026 03:05:59 +0530
- To: Amir Hameed <amsaalegal@gmail.com>
- Cc: public-credentials@w3.org
- Message-ID: <CAPNHAC6DFhb2kY80d5VATJmdS7Pjt2oq8rkpdJjiDExJ+3f-jw@mail.gmail.com>
Hey Amir, you've read it correctly, and the honest answer is: yes, these primitives are general-purpose, and no, there's no technical property that restricts them to AI agents. Delegation, heartbeat renewal, and state verifiability would all work for human actors, service accounts, and non-AI workloads. Nothing in the cryptography or the mechanisms lock them to AI. The scope is AI agents by choice and not by technical necessity, for two reasons: 1. The defaults are tuned to how AI agents fail. Heartbeat lifetimes are short because the AI threats are fast like the prompt injection, a swapped model or a behavioral drift mid-session. For a steady service account that renewal cadence will be overhead. Same mechanism, different setting. 2. A few mechanisms are AI-specific in motivation: keeping keys out of the model's context window, binding identity to model weights to catch a swap, canary checks to tell a dead or hijacked agent from an idle one - these are AI-relevant, but they sit alongside the general primitives instead of restricting them. - On your middle question, should the scope reflect this: yes, and right now it doesn't say so clearly. I'll add a short paragraph to the scope section stating that the AI-agent scope is a deliberate threat-model choice rather than a technical boundary, and that the underlying primitives generalize. - - Applying them to humans or service accounts would require a separate profile with re-tuned defaults, which is a reasonable future work rather than something we should consider adding to the v1.0 scope, IMHO. If a non-AI profile is something you or your team would find useful, I'm happy to figure out the right home for it, whether that's a separate spec here in the CCG or somewhere else. Thanks for reading it closely. Best, Ramprasad On Mon, 1 Jun 2026 at 10:38, Amir Hameed <amsaalegal@gmail.com> wrote: > Hi Ramprasad, > > The delegation, heartbeat, and state verifiability primitives in this > specification are general-purpose authorization and session-management > mechanisms. Do you anticipate these being applicable to human actors, > service accounts, and non-AI workloads? If so, should the specification's > scope reflect that? If not, what technical property restricts these > mechanisms to AI agents specifically. > > Regards > Amir Hameed Mir > > > On Sun, 31 May 2026 at 16:24, Alan Karp <alanhkarp@gmail.com> wrote: > >> 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 >>> >>
Received on Tuesday, 2 June 2026 21:36:15 UTC