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

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
>