Delegation technologies

[Alan Karp]

I'm working with folks on the Distributed Identity Foundation's Trusted AI Agent Working Group's Delegated Authority Task Force.  (Whew!  That's a mouthful.) 

I've produced a document spelling out the requirements, which includes Stiegler's 7 aspects of sharing.  (He said 6, but he forgot about revocation.)  Unfortunately, the document is not ready for public release yet.

I'd like to add a list of technology options.  Clearly, zcap-ld is in the list.  I'm not sure about something like the way Agoric has adapted E.  Please send me your candidates for inclusion.  I've already got zcap-ld, SPKI, Zebra Copy, UCAN, Macaroons, and waterken.

--------------
Alan Karp

[Matt Rice]

On Tue, Feb 24, 2026 at 5:54 PM Alan Karp <alan...@gmail.com> wrote:
>
> I'm working with folks on the Distributed Identity Foundation's Trusted AI Agent Working Group's Delegated Authority Task Force. (Whew! That's a mouthful.)
>
> I've produced a document spelling out the requirements, which includes Stiegler's 7 aspects of sharing. (He said 6, but he forgot about revocation.) Unfortunately, the document is not ready for public release yet.
>

Maybe, but you can also argue that revocation are just aspects of the
first two (dynamic & attenuation), it's just the south pole of
attenuation.

[Matt Rice]

I would argue that revocation can be sharing, particularly when you include
the section 11.5.3 "Implications for revocation" in MarkM's thesis, because in
a distributed system reliable revocation is difficult where Alice may
intermittently be out of
contact, the revocation may be a mechanism of sharing like a dead
man's switch that
revokes itself upon Alice's disappearance. This dead mans switch is a
mechanism of both
sharing and non-sharing.

On Tue, Feb 24, 2026 at 9:32 PM John Carlson <yott...@gmail.com> wrote:
>
> Oh, and revocation is probably not “sharing” by definition.
>
> John

>> --
>> You received this message because you are subscribed to the Google Groups "cap-talk" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
>> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFrvUOG2hRk5yLkhCVfL0gzo0mhM0fS-1_0A%2B3Y3QbbGhA%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UE%3Dj8gBPhJkKTRGYpdQsW%2BJOnmzcu85aabqqfO3nH-zROA%40mail.gmail.com.

[Alan Karp]

On Tue, Feb 24, 2026 at 1:38 PM Matt Rice <rat...@gmail.com> wrote:

I would argue that revocation can be sharing, particularly when you include
the section 11.5.3 "Implications for revocation" in MarkM's thesis, because in
a distributed system reliable revocation is difficult where Alice may
intermittently be out of
contact, the revocation may be a mechanism of sharing like a dead
man's switch that
revokes itself upon Alice's disappearance. This dead mans switch is a
mechanism of both
sharing and non-sharing.

I'd say that the key difference is that delegation involves delegator-delegate communication; revocation doesn't.  

 

--------------
Alan Karp

[Matt Rice]

No I'm not ascribing any machine instructions at all, I don't see in
the quoted text where I mentioned null,
or a "null cap", I mean a capability which conveys zero authority to
the holder. In the chapter I mentioned it's a boolean 'enabled' field,
which if true grants authority if false grants zero authority.

On Tue, Feb 24, 2026 at 9:59 PM John Carlson <yott...@gmail.com> wrote:
>
> I think you’re thinking of setting a pointer to null? Pointers aren’t capabilities, capabilities tie resources to operations. A file descriptor is a capability, a File pointer is not.
>
> I hope we don’t get into references into shared memory.
>
> John

>> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFpQvysB2Xfyv2%2BP_m%3D8xu6_%3DvqtKkf-QuF9Tss-vJCecQ%40mail.gmail.com.

>
> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UE%3DK-BR8SaFT%2B3u02jgdxnAJ42uk8tjZ45_HRCCNxPN7jQ%40mail.gmail.com.

[Matt Rice]

Indeed there *are* multiple caps involved in that section of Mark's
thesis, sorry I didn't describe the whole thing in a rush out the
door.

On Tue, Feb 24, 2026 at 11:02 PM John Carlson <yott...@gmail.com> wrote:
>
> Probably me misinterpreting.
>
> I wasn’t referring to machine instructions, more like memory addresses. A null capability has either no resources, and can’t operate on something, or has no operations, so cannot do something to any resources.
>
> No need for any boolean. Expensive.
>
> But apparently you want a capability to turn on and off a capability is my understanding. Use the double door metaphor. The second door is the dead man’s switch. It doesn’t do anything to the key/capability on the outer door. The capability (the ability to get in the inner room) has been revoked.
>
> Think of a doctor’s office doors and who has access to open them in normal situations. Alan mentioned something like appointments.
>
> How many useless keys do you keep on your keychain or in a drawer?
>
> I can erase a pointer in memory, but it doesn’t erase the address the pointer refers to. Capabilities are unforgeable. They are often hardware-tagged pointers. I am thinking of pointers like a FILE pointer in stdio.h, not really anywhere else.
>
> John

>> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFpaYz6Zfhiv9d%2BSvAP-N30E89%2B_aBtUYhMoq5vj7qDEHQ%40mail.gmail.com.

>
> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEneq6_k147-wH3u1Qn1LVu5yZmsZd7TEyc21%3DYeAH0MpQ%40mail.gmail.com.

[Mark S. Miller]

[+Kris]

On Tue, Feb 24, 2026 at 9:54 AM Alan Karp <alan...@gmail.com> wrote:

I'm working with folks on the Distributed Identity Foundation's Trusted AI Agent Working Group's Delegated Authority Task Force.  (Whew!  That's a mouthful.) 

I've produced a document spelling out the requirements, which includes Stiegler's 7 aspects of sharing.  (He said 6, but he forgot about revocation.)  Unfortunately, the document is not ready for public release yet.

I'd like to add a list of technology options.  Clearly, zcap-ld is in the list.  I'm not sure about something like the way Agoric has adapted E. 

You mean Endo http://endojs.org , which is a full E-like distributed persistent* ocap system built on top of Hardened JS as the local ocap language (like local-E) and ocapn as the distributed secure cryptocaps object-invocation protocol. This is like E's CapTP except that ocapn is language independent. This of course fully supports Stiegler's 7 aspects, just as E does.

Kris (cc'ed) both believe in UI affordances for transitive revocation in our UI (the Familiar). But his emphasis is on full transitive revocation, which arguably has a simpler more intuitive UI. My emphasis remains on transitive selective revocation, like SCoopFS and Horton. I expect we'll get Kris' wish soon and my wish much later.

 

Please send me your candidates for inclusion.  I've already got zcap-ld, SPKI, Zebra Copy, UCAN, Macaroons, and waterken.

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1gYFjFzJgi9-TCZaNiz2ariEi-qjjQ5%2BqQmB06zoVZmA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Tue, Feb 24, 2026 at 12:49 PM Matt Rice <rat...@gmail.com> wrote:

On Tue, Feb 24, 2026 at 5:54 PM Alan Karp <alan...@gmail.com> wrote:
>
> I'm working with folks on the Distributed Identity Foundation's Trusted AI Agent Working Group's Delegated Authority Task Force.  (Whew!  That's a mouthful.)
>
> I've produced a document spelling out the requirements, which includes Stiegler's 7 aspects of sharing.  (He said 6, but he forgot about revocation.)  Unfortunately, the document is not ready for public release yet.
>

Maybe, but you can also argue that revocation are just aspects of the
first two (dynamic & attenuation), it's just the south pole of
attenuation.

Yes. I like to say that revocation is temporal attenuation. Revocable Carol provides Bob all the authority of Carol until Alice decides to shut it off.

 

> I'd like to add a list of technology options.  Clearly, zcap-ld is in the list.  I'm not sure about something like the way Agoric has adapted E.  Please send me your candidates for inclusion.  I've already got zcap-ld, SPKI, Zebra Copy, UCAN, Macaroons, and waterken.
>
> --------------
> Alan Karp

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CACTLOFrvUOG2hRk5yLkhCVfL0gzo0mhM0fS-1_0A%2B3Y3QbbGhA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Kris Kowal]

On Feb 25, 2026, at 3:47 PM, Mark S. Miller <eri...@gmail.com> wrote:

[+Kris]

On Tue, Feb 24, 2026 at 9:54 AM Alan Karp <alan...@gmail.com> wrote:

I'd like to add a list of technology options.  Clearly, zcap-ld is in the list.  I'm not sure about something like the way Agoric has adapted E.  

You mean Endo http://endojs.org , which is a full E-like distributed persistent* ocap system built on top of Hardened JS as the local ocap language (like local-E) and ocapn as the distributed secure cryptocaps object-invocation protocol. This is like E's CapTP except that ocapn is language independent. This of course fully supports Stiegler's 7 aspects, just as E does.

Kris (cc'ed) both believe in UI affordances for transitive revocation in our UI (the Familiar). But his emphasis is on full transitive revocation, which arguably has a simpler more intuitive UI. My emphasis remains on transitive selective revocation, like SCoopFS and Horton. I expect we'll get Kris' wish soon and my wish much later.

I think we’ll get both, soon.

1. Deleting a petname associated with an ocap locator may lead to revocation, but isn’t necessarily sufficient to down the refcount far enough to induce the reaping of the corresponding live reference and any ongoing captp sessions that expose it.

2. Opening a listing of all local petname retention paths to the same locator as a given petname, then pressing “delete all” would be the mechanism I believe MarkM is ascribing to me.

3. Selectively deleting edges from that display is I believe the mechanism MarkM is ascribing to Horton.

[Chris Hibbert]

This doesn't seem to have been delivered, so I'm resending.

On 2/25/26 12:03 PM, Matt Rice wrote:

I'm saying two things.

First, Marc's original 6 things:
Sharing →Dynamic ∧ Attenuated ∧ Chained ∧ Cross domain ∧ Recomposable
∧ Accountable

Second, the original 6 things implies revocation.
Dynamic ∧ Attenuated → Revocation

Thus:
Sharing → Revocation

This seems like an overgeneralization to me. I've used several OCap based systems in which attenuation was trivial, and revocation took some work, and was done in different ways in different subsystems (if at all).

Attenuation can mean only that I get read-write access to some object, and I can trivially wrap that and pass on read-only access to my clients.

If I want to add revocability, I have to write a different wrapper, and manage an API allowing someone to wrap an OCap, and return two facets to their clients so they can keep the management facet, and pass on the revocable facet. The stricter the type system, the more likely it is that I'll have to coordinate with the provider of the original OCap in order to make my wrapped version compatible when it should be and recognizably incompatible to clients who needed the fully-powered version.

Revocability is implied by our standard tooling for sharing, but if it's not built in to the programming library, it's a hassle to provide.

Chris

-- 
When telephones, airlines, radio and TV, and trucks were
deregulated in the 1970s, we found that all the stories about
consumer and social harm, safety, or “market failures” were wrong,
but regulatory stifling of innovation and competition was very
real.  -- John Cochrane (aka Grumpy Economist)
https://www.grumpy-economist.com/p/ai-society-and-democracy-just-relax

Chris Hibbert
hib...@mydruthers.com
Blog:   http://www.pancrit.org
http://mydruthers.com

[Matt Rice]

On Thu, Feb 26, 2026 at 1:13 AM Chris Hibbert <hib...@mydruthers.com> wrote:
>
> This doesn't seem to have been delivered, so I'm resending.
>
> On 2/25/26 12:03 PM, Matt Rice wrote:
>
> I'm saying two things.
>
> First, Marc's original 6 things:
> Sharing →Dynamic ∧ Attenuated ∧ Chained ∧ Cross domain ∧ Recomposable
> ∧ Accountable
>
> Second, the original 6 things implies revocation.
> Dynamic ∧ Attenuated → Revocation
>
> Thus:
> Sharing → Revocation
>
>
> This seems like an overgeneralization to me. I've used several OCap based systems in which attenuation was trivial, and revocation took some work, and was done in different ways in different subsystems (if at all).
>
> Attenuation can mean only that I get read-write access to some object, and I can trivially wrap that and pass on read-only access to my clients.
>
> If I want to add revocability, I have to write a different wrapper, and manage an API allowing someone to wrap an OCap, and return two facets to their clients so they can keep the management facet, and pass on the revocable facet. The stricter the type system, the more likely it is that I'll have to coordinate with the provider of the original OCap in order to make my wrapped version compatible when it should be and recognizably incompatible to clients who needed the fully-powered version.
>
> Revocability is implied by our standard tooling for sharing, but if it's not built in to the programming library, it's a hassle to provide.
>

I certainly agree with this, and am not arguing against any of this,
I'm just arguing that tooling provided revocation is easy to
underspecify with too simple of an implementation for all purposes.
Thus advocating for implementing it in the standard tooling probably
needs to be done with care and
taking into consideration the various corner cases and pitfalls of
distributed faults. I don't doubt that people of this audience could
build a good system-wide revocation mechanism. I doubt that people
from a general audience could if given a vague description of
revocation, and thus advocating for a system wide revocation mechanism
to such an audience has risks...

If anything my argument is that all the complexity of the application
derived revocation mechanisms doesn't just disappear by making it
system wide, but may alter it or in some cases introduce complexities
like the need for irrevocability.

> Chris
> --
> When telephones, airlines, radio and TV, and trucks were
> deregulated in the 1970s, we found that all the stories about
> consumer and social harm, safety, or “market failures” were wrong,
> but regulatory stifling of innovation and competition was very
> real. -- John Cochrane (aka Grumpy Economist)
> https://www.grumpy-economist.com/p/ai-society-and-democracy-just-relax
>
> Chris Hibbert
> hib...@mydruthers.com
> Blog: http://www.pancrit.org
> http://mydruthers.com
>
>
>
>
>

> --
> You received this message because you are subscribed to the Google Groups "friam" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/friam/a54b77a5-4f90-4190-9676-652de57d6a48n%40googlegroups.com.

[Alan Karp]

I want to apologize to all the folks I've drawn down this rabbit hole.  I've been arguing about online revocation mechanisms, but Stiegler's aspects of sharing are what we rely on in the physical world.  

Revocation is common.  I take my key back when the valet brings my car.  I disable your badge when you leave the company.  We just need to make sure that we can take analogous action in the digital world.  As has been noted, you don't need an explicit mechanism to achieve that effect, although you may want one in some circumstances.

I haven't read the replies to this thread that came in late yesterday, but I'll get to them later.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/friam/CACTLOFqMdDKjrv5R7UZmLF%3DRFTJccskzxPU7uivAbgV0OWh_zQ%40mail.gmail.com.