Re: Access Control

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