Re: Restarting work on the zCap (Authorization Capabilities) work item

(I didn't do a deep dive, as you can tell from the time stamp on my
response.  Please forgive me if I missed something important.)

Capabilities are agnostic on how you get your initial set.  You can use
roles, attributes, even ACLs.  Trust circles appear to be another option.

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


On Thu, Apr 2, 2026 at 4:23 PM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> If you think of a capability/right/permission (or sets of the same) as a
> DID Identity (e.g. did:drn), you can consider using VTCs to bind specific
> groups of subjects with specific sets of capability/right/permission.
>
>
>
> Reference:
> https://hyperonomy.com/2026/03/26/sdo-verifiable-trust-circles-vtcs-using-vc-proof-sets-web-7-0/
>
>
>
> *From:* Bob Wyman <bob@wyman.us>
> *Sent:* Thursday, April 2, 2026 3:05 PM
> *To:* dzagidulin@gmail.com
> *Cc:* Christopher Allen <ChristopherA@lifewithalacrity.com>; Credentials
> Community Group <public-credentials@w3.org>
> *Subject:* Re: Restarting work on the zCap (Authorization Capabilities)
> work item
>
>
>
> Dmitri wrote:
>
> "I think the zCap approach is explicitly philosophically opposed to the
> "cryptographic capabilities" approach (cCaps? :) )."
>
> I'd suggest the zCap vs. cCap difference is less fundamental than it
> appears — and dissolves if we separate zCaps' "capability envelope" from
> the Rights Expression Language (REL).
>
> The zCap envelope provides generic infrastructure: object identity,
> delegation chain, controller binding, temporal bounds, proofs, revocation,
> error reporting. None of this is specific to any particular REL. The caveat
> field carries the rights expression — what is actually permitted and under
> what conditions — and that is where the real differences lie.
>
> Under this framing, Gordian Clubs' cryptographic caps are simply a caveat
> written with a REL that enforces itself mathematically rather than through
> a server. There is no reason a zcap envelope cannot carry one as its
> caveat. Whether enforcement requires a trusted server or just mathematics
> becomes a property of the chosen REL, not of the envelope.
>
> The same logic applies to the endless "Capabilities vs. ACL" debate. An
> ACL ("Alice may read this") and a capability ("the holder of this token may
> read this") both require largely identical infrastructure: object identity,
> authority claims, distribution, verification, revocation. They differ only
> in their REL. The zcap envelope is general enough to carry both.
>
> The one normative requirement that makes this safe: a verifier that
> encounters a caveat type it does not recognise MUST deny access. Fail
> closed. This makes the caveat field safely pluggable without creating
> security gaps.
>
> For v0.5 this suggests: define the envelope normatively, define URL-path
> attenuation as a minimal default REL profile for backward compatibility,
> and specify the deny-if-not-understood rule. Then let ODRL profiles,
> cryptographic caps, and anything else conforming to that rule plug in as
> additional REL profiles.
>
> bob wyman
>
>
>
> On Thu, Apr 2, 2026 at 4:21 PM Dmitri Zagidulin <dzagidulin@gmail.com>
> wrote:
>
> Thanks Christopher,
>
> As always, really good work, that I'll be following with interest.
>
>
>
> I think the zCap approach is explicitly philosophically opposed to the
> "cryptographic capabilities" approach (cCaps? :) ).
>
>
>
> Cryptographic cap approach says "crypography (ie, encryption) is
> sufficient to enforce authorization. no authz enforcement servers needed."
>
>
>
> zCaps approach says: "all encryption has a half life. By itself, it is not
> secure enough for an important category of use cases. what's needed is
> encryption PLUS trusted authorization enforcement servers".
>
>
>
>
>
>
>
> On Thu, Apr 2, 2026 at 3:15 PM Christopher Allen <
> ChristopherA@lifewithalacrity.com> wrote:
>
> At Blockchain Commons we’ve been working on a different approach to object
> capabilities, which we call cryptographic capabilities.
>
>
>
> Instead of authorization for access to a process on a server, it allows
> access to read and write privileges in an autonomous cryptographic object
> (ACO) and supports delegation and attenuation (but has limitations on
> revocation). These objects can reside anywhere and do not require
> infrastructure (i.e., you can read and write ACOs entirely on your offline
> machine using sneakernet).
>
>
>
> We’ve implemented this initial in Gordian Clubs, inspired by Mark S
> Miller’s Xanadu Club System:
>
>
>
> https://developer.blockchaincommons.com/clubs/
>
>
>
> More details at:
>
> https://developer.blockchaincommons.com/clubs/ocaps/
>
>
>
> Also an article on the goals:
>
> https://www.blockchaincommons.com/musings/musings-exodus-protocol/
>
>
>
> ABSTRACT: Digital infrastructure is built on sand due to its control by
> centralized entities, most of which are focused on profit over service. We
> need Exodus Protocol services that build infrastructure without
> centralization, ensuring its continuation into the far future. Bitcoin
> offers our prime example to date. Five design patterns suggest how to
> create similar services for coordination, collaboraiton, and identity.
>
> KEYQUOTE (relevant to this thread):
>
> > Not every digital service needs to be an Exodus Protocol. In fact, there
> are definitely services where you want centralization. You want more
> vulnerable people to be able to recover their funds in case of fraud. You
> want parents to be able to act as guardians for their children.
>
> >
> > But there are services that are irreplaceable and so would benefit from
> Exodus. These are digital services that store data, create identity, and
> manage assets that would be difficult to replace. And there are times when
> Exodus Protocols become more important than ever: when we’re under threat,
> under siege, or just struggling to survive.
> >
> > We still want to offer the ease of access and usability of centralized
> services in those situations where they’re appropriate, but we want to
> build those centralized services upon a strong, unwavering foundation of
> Exodus. If the centralized services fail, there must still be foundations
> that cannot fall.
>
>
>
> This relates to what Vitalik Buterin and the Ethereum Foundation have been
> calling "Sanctuary Technologies" in recent weeks.
>
>
>
> I hope that at some level anyone working on standards for more traditional
> zcaps will consider this form of object capabilities as well.
>
>
>
> -- Christopher Allen
>
>