Re: Access Control

Christopher,
What you've described is essentially a DRM system, but then DRM and Access
Control are very similar problems. What is being called the "capability" in
the Access Control context seems to me to be very much like what one might
refer to as a "license" in a DRM context. I have now long expired, 35-year
old patents on the Digital Distributed Software Licensing Architecture
(DDSLA), which works somewhat similarly to what you described
(including delegation).

Your approach is, I think, quite reasonable. But, given that the DRM
Pandora's box has been opened, the obvious question is: What can be
borrowed or leveraged from Open Digital Rights Language (ODRL)
<https://www.w3.org/ns/odrl/2/ODRL20.html> or similar languages? Why would
the language for expressing a DRM "license" be any different from the
language used to express an Access Control "capability?"

bob wyman


On Fri, Aug 22, 2025 at 6:03 PM Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> I've been following this delegation and object capabilities discussion
> with interest. While I'm not sure of your specific use cases, I wanted to
> share a fundamentally different approach to ocaps that we've been
> developing—one that supports the same delegation patterns you're
> discussing, but without any infrastructure dependencies.
>
> Traditional ocaps require some authority to validate them, whether that's
> checking with an issuer, verifying against a service, or confirming with
> infrastructure. But what if the capability itself could be the complete
> proof, requiring no external validation whatsoever?
>
> We're implementing cryptographic object capabilities using Schnorr adaptor
> signatures—proven cryptography from Bitcoin's Taproot and Lightning
> Network. These support familiar ocap patterns: Alice can delegate her read
> access to Bob, Bob can sub-delegate to Carol with restrictions, and so on.
> But we also support threshold capabilities—where k-of-n members must
> cooperate to grant access or create delegations. The difference is that
> these delegations and thresholds are mathematical proofs rather than tokens
> to be verified. When someone exercises a delegated capability, they're not
> checking with any authority—they're solving a cryptographic puzzle that
> directly enables the access they need.
>
> This creates capabilities that are truly autonomous. They work offline, in
> air-gapped systems, during network outages, in censorship-heavy
> environments, or decades after the issuing system has disappeared. No
> servers, no databases, no phone-home required. The delegation chain and
> threshold requirements are cryptographically proven without any external
> dependencies.
>
> The tradeoffs are real but often desirable: these capabilities can't be
> revoked once issued (old capabilities still decrypt old content, but new
> content can exclude them), and they don't support dynamic conditions
> without optional infrastructure for oracles. But for many
> scenarios—security disclosures requiring maintainer consensus, disaster
> response with distributed authority, long-term archival, adversarial
> environments—these "limitations" become strengths.
>
> We're building this as part of our Gordian Club System on top of Gordian
> Envelope and XIDs, with single-key cryptographic capabilities (including
> delegation) nearly ready as a proof of concept, and hopefully for security
> review in the late fall. Threshold-based capabilities combined with
> FROST/MuSig2 signatures offer even richer possibilities as the
> cryptographic research matures.
>
> I'd be curious if anyone here sees applications for autonomous delegation
> and threshold authority in their work. Sometimes the ability to require
> consensus or delegate authority without any infrastructure dependency opens
> possibilities we hadn't imagined when we assumed some authority would
> always be available.
>
> Happy to share more details with anyone interested in exploring this very
> different paradigm for capability-based delegation.
>
> -- Christopher Allen
>    Blockchain Commons
>
>