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-swiss-eid/>
>> <https://www.blockchaincommons.com/musings/musings-swiss-eid/>
>> 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
>>
>