- From: Ramprasad G <ram@vouch-protocol.com>
- Date: Wed, 3 Jun 2026 02:13:52 +0530
- To: Alan Karp <alanhkarp@gmail.com>
- Cc: public-credentials@w3.org
- Message-ID: <CAPNHAC7uSkaSg1B-DBK1DDLTfS5qC7C13PfWLqioe__aE8h+Mw@mail.gmail.com>
Hey Alan, Afternoon! Thanks, this is a good catch and you're right. What you're describing is the classic capability-attenuation problem, and the depth limit in section 9.4 just doesn't hold up against it. If an agent hits the limit and still needs to hand a narrower permission to someone else, it can't, so it ends up proxying or sharing credentials instead. Both are worse and wreck the audit trail. Here's what we could do for v1.7: drop the depth limit and replace it with two things. First, an *actual attenuation rule*. Every delegation has to produce a smaller capability than its parent, smaller on at least one of: *action, target, resource, time, rate, *or* policy*. If it's not smaller on anything (and not bigger on anything), we would reject it. The chain just naturally ends when there's nothing left to narrow down to, like read-only on a single object. No fixed depth required. Worth saying we already do this on two dimensions today: section 9.3 makes each downstream link's resource a sub-resource of the parent's (step 5) and each link's time window fits inside the parent's (step 6). So this wouldn't adding attenuation from scratch, but generalizes the resource-and-time narrowing we already enforce to the other dimensions, while dropping the depth-cap that works against it. It also lines up with PAD-021 (Inverse Capability Pattern), which already describes this but isn't currently the actual rule. Second, let the verifier decide their own *cost budget*. A verifier can still cap how long a chain they are willing to process, by depth or total verification time or whatever, but that's a local decision, not a hard rule in the spec. And if it rejects a chain for being too long, it needs to mention it, so the agent learns to narrow earlier instead of proxying around it. Before we reword this into v1.7, I'd really value your input on a few things: 1. Is "smaller on at least one dimension" good enough? Because, if someone reduces the rate by 1 and calls it *attenuated *while keeping all the real power, then should we require meaningful narrowing on action/target/resource specifically, or leave that to the verifier? 2. Does the termination/leaf condition need to be written out explicitly, or does it just happen naturally from the subset rule on its own? 3. The one piece I haven't figured out is chain-cascade on revocation. We already have credential-level revocation, a DID-level revocation registry, key rotation, and time bounds already narrow down the chain. What's unclear is: if a link partway down gets revoked or its key is rotated, should that automatically kill everything downstream of it at validation time? Is there a pattern from the capability work you'd point me to? I've filed this as an issue to track it: https://github.com/vouch-protocol/vouch/issues/39 Would you be up for a short call to walk through the section 9 redesign, or would you prefer to hash it out on the issue thread? Either is fine with me. Thanks again, this is exactly the kind of review the spec needed :) Ramprasad On Mon, 1 Jun 2026 at 04:52, 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 20:44:12 UTC