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

VTCs are a way to bind together arbitrary collections of DID Identities…

[image]


From: Alan Karp <alanhkarp@gmail.com>
Sent: Thursday, April 2, 2026 5:33 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Cc: Bob Wyman <bob@wyman.us>; dzagidulin@gmail.com; Christopher Allen <ChristopherA@lifewithalacrity.com>; Credentials Community Group <public-credentials@w3.org>
Subject: 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<mailto: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<mailto:bob@wyman.us>>
Sent: Thursday, April 2, 2026 3:05 PM
To: dzagidulin@gmail.com<mailto:dzagidulin@gmail.com>
Cc: Christopher Allen <ChristopherA@lifewithalacrity.com<mailto:ChristopherA@lifewithalacrity.com>>; Credentials Community Group <public-credentials@w3.org<mailto: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<mailto: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<mailto: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