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.

[Alan Karp]

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

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.

I don't see how.  The delegation and revocation mechanisms are quite different.

 

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

[John Carlson]

Revocation is attenuating to no access.  But revocation is really a double door thing, so it’s not really attenuated, I don’t think attenuation destroys the original capability’s usability.  Alan is right.   There’s no use making a no access capability—useless.

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/CANpA1Z1dv8tM2NkP%2BDY7xSSmRcvD_7CsDYnxrru7Bi__pSnxmQ%40mail.gmail.com.

[Matt Rice]

The argument is that if an example of attenuation is taking say a
read-write reference,
and attenuating it into a read-only reference, revocation can be
considered a similar act
of attenuation turning a read-only reference into a null reference.

Rather than just weakening, it weakens the capability into non-existence.
The rest of the differences can be explained by the explanation that
it is a dynamic
form of attenuation. The typical delegation use of attenuation where
you give someone a weaker
capability than you yourself hold is typically a static attenuation.

[John Carlson]

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.

[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.

> 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:31 PM Matt Rice <rat...@gmail.com> wrote:

The argument is that if an example of attenuation is taking say a
read-write reference,
and attenuating it into a read-only reference, revocation can be
considered a similar act
of attenuation turning a read-only reference into a null reference.

Rather than just weakening, it weakens the capability into non-existence.
The rest of the differences can be explained by the explanation that
it is a dynamic
form of attenuation. The typical delegation use of attenuation where
you give someone a weaker
capability than you yourself hold is typically a static attenuation.

I can't think of a system that provides a way to attenuate a granted capability, which is why you need a separate revocation mechanism.  

 

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

[John Carlson]

If a capability is an integer and you attenuate it to revoke it, and it’s still the same integer, then you’ve effectively revoked your own access.  Oops!  Might be useful if you fork()?  But really, it’s a different capability.  Capabilities tie resource plus operations.  AFAIC, attenuation creates a new capability, and you can still revoke (not share) the old capability if you wish.

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/CACTLOFq7Ssm202Q_70VETG08Q82VK9F6ooFQA_Q4HFiuv%2B4OKA%40mail.gmail.com.

[Matt Rice]

We're probably using a different definition of attenuation, I've
always just considered it the dictionary definition
"the reduction of the force, effect, or value of something.", and not
involved any implications like creation of a new capability.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEn5PMpEBXVFv9a-5rA5PygEe7hRFdrDnFDTNb_TMx5NHA%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

[Alan Karp]

On Tue, Feb 24, 2026 at 1:42 PM John Carlson <yott...@gmail.com> wrote:

If a capability is an integer and you attenuate it to revoke it, and it’s still the same integer, then you’ve effectively revoked your own access.  Oops!  Might be useful if you fork()?  But really, it’s a different capability.  Capabilities tie resource plus operations.  AFAIC, attenuation creates a new capability, and you can still revoke (not share) the old capability if you wish.

It's important that you also revoke all capabilities deeper in the delegation chain lest you be vulnerable to sock puppets.

 

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

[Alan Karp]

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

We're probably using a different definition of attenuation, I've
always just considered it the dictionary definition
"the reduction of the force, effect, or value of something.", and not
involved any implications like creation of a new capability.

True, but by different mechanisms.  That's why I'm insisting on making a distinction.

 

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

[Matt Rice]

I think part of this is because capability systems typically don't
provide policy, and revocation quickly turns into policy.
Plus Mark's thesis shows the normal message passing mechanisms suffice
to do so without ascribing policy.
There are also static revocation policies, "no tv after 8pm" which is
half way between a temporary revocation and attenuation,
"volume low until after 10am" is more of an attenuation. These require
some effect to trigger the revocation like a clock.
"You can borrow the car for exactly 2 hours" is more of a pure
revocation based on a clock.

Part of my point here is that these don't need attenuating a granted
capability, the dynamic attenuation is built into the granted
capability at grant time in these specific cases.

[John Carlson]

In the two door revocation scenario that would be unlocking the second door, not revocation, but unrevocation, if such a thing exists.  Unrevocation is sharing.

I’m revoking your access to my bank account. That’s not sharing.   I’m granting you access to read my account amount, that’s sharing.

I don’t like using database terms, but they make sense.

I’m an old CRUDGeR.  Revoke is delete, grant is insert, and attenuate is update.

John 

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

[John Carlson]

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.

[Matt Rice]

Sure, it's really fine with me if you feel like you need or want to
add it, I'm just saying that there is an argument that can be made
that it's already present in the first two of the original 6 things
Steigler listed. I feel like I've made that argument so don't feel
like I have
much more to add.

[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.

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

[John Carlson]

For example, if you set a file descriptor variable to -1, you might lose access, but if you forked before setting, the capability isn’t revoked.   But file descriptors can be guessed if you’re still in the same process.   My understanding is that capabilities can’t be.   I don’t know much about references except pass by reference parameters.  My knowledge of C++ fails me.   I lived too long in the Java world where stuff is pass by value.  Setting a reference to null in Java message that the object referred to might be garbage collected, unless you have another reference to the object.  Setting a pointer to NULL in C does not have the same effect. Free() the sucker, but don’t double free() it.  If you’re having issues with C, use Rust or Go.

Setting a pointer to is helpful, but has nothing to do with real revocation.

John

[Alan Karp]

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

Part of my point here is that these don't need attenuating a granted
capability, the dynamic attenuation is built into the granted
capability at grant time in these specific cases.

I agree, but aren't there cases where you need an explicit revocation mechanism?  Isn't that mechanism distinct from how you delegate?

 

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

[John Carlson]

I think some attenuation can add operations to a capability, but I’ve never heard a use.  Typically you attenuate before delegating, and reserve the original capability and ability to revoke the delegation.  If the original and delegated capabilities are the same, you cannot revoke access to the delegated capability without revoking your own access.

John 

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFoe_XSVYCSivVBR9w3ja_3XHLoUQ-TmTcandn8G-NgB7g%40mail.gmail.com.

[John Carlson]

I’ll haven’t run into that term sock puppet before, but I’ve thought of that situation, I think we discussed keeping the delegation chain in a table.

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/CANpA1Z3drkeSphCxKxMjKRJ47AyfWcxr3FmTsHFSjV-f6zdwMg%40mail.gmail.com.

[Matt Rice]

I don't feel like there is a need for an explicit revocation
mechanism, because you can flip it inside out, where the dead mans
switch requires constant prodding to be kept from being revoked. Alice
must invoke that something say every hour to keep the capability she
granted Bob to Carol from being auto-revoked.

The problem with "explicit revocation mechanisms" is when Alice wants
to revoke but her network connection to the capability she wishes to
revoke fails. She has no way to invoke the explicit revocation
mechanism. Flipping things inside out you just build the revocation
into the normal message passing, this can be completely static like
the clock based examples, or based on the normal message passing
mechanism, and specify the policy for revocation inside the
capability. Relying on mechanisms like clocks, timeouts, and
notifications of disconnection to handle the revocation at the time
when a normal message invocation from bob is received.

[Alan Karp]

On Tue, Feb 24, 2026 at 2:25 PM John Carlson <yott...@gmail.com> wrote:

I’ll haven’t run into that term sock puppet before, but I’ve thought of that situation, I think we discussed keeping the delegation chain in a table.

How you represent the delegation chain depends on the technology.  If you're using certificates, e.g., zcaps, then the delegation chain is contained in the certificate.  If you're using some kind of opaque tokens, such as web keys, where you use token exchange for attenuated delegation, the chain is held in a table at the exchange point.  Whatever you do, delegations downstream from the revoked one must be revoked, too.

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

[Alan Karp]

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

I don't feel like there is a need for an explicit revocation
mechanism, because you can flip it inside out, where the dead mans
switch requires constant prodding to be kept from being revoked. Alice
must invoke that something say every hour to keep the capability she
granted Bob to Carol from being auto-revoked.

The problem with "explicit revocation mechanisms" is when Alice wants
to revoke but her network connection to the capability she wishes to
revoke fails. She has no way to invoke the explicit revocation
mechanism. Flipping things inside out you just build the revocation
into the normal message passing, this can be completely static like
the clock based examples, or based on the normal message passing
mechanism, and specify the policy for revocation inside the
capability. Relying on mechanisms like clocks, timeouts, and
notifications of disconnection to handle the revocation at the time
when a normal message invocation from bob is received.

Having a way to revoke access when the revocation request can't be made or can't get through is a good idea, but it's not enough.  What if Alice wants to revoke without going offline?  What if she wants to revoke before the built in timeout?

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

[Matt Rice]

If Alice wants to revoke without going offline she just invokes the
disable message to flip the 'enabled' boolean manually.
This is kind of why I feel it is hard to describe a good explicit
revocation mechanism which is also policy neutral.
At least in Mark's thesis the solution described seems to be not
having an explicit revocation mechanism, but leveraging the existing
invocation mechanism, and making revocation an arbitrary message the
same as any other.

That means that each capability has to carry it's own preordained
policy for revocation though, so the system won't assign the wrong
policy.

[Alan Karp]

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

If Alice wants to revoke without going offline she just invokes the
disable message to flip the 'enabled' boolean manually.

Which makes the revocation mechanism different from the delegation mechanism.  

 

This is kind of why I feel it is hard to describe a good explicit
revocation mechanism which is also policy neutral.

Revocation is an expression of policy.

 

At least in Mark's thesis the solution described seems to be not
having an explicit revocation mechanism, but leveraging the existing
invocation mechanism, and making revocation an arbitrary message the
same as any other.

There, you said it.  Not me.  "leveraging the existing invocation mechanism"  That's not leveraging the existing delegation mechanism.  Invocation doesn't show up in Stiegler's 6 aspects of sharing.

Not all capability systems need a caretaker to support revocation.  Both certificate and opaque tokens, like webkeys, can support direct revocation.

That means that each capability has to carry it's own preordained
policy for revocation though, so the system won't assign the wrong
policy.

Such a policy is only needed as a backup if there's an explicit revocation mechanism.

 

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

[Matt Rice]

On Tue, Feb 24, 2026 at 10:55 PM Alan Karp <alan...@gmail.com> wrote:
>
> On Tue, Feb 24, 2026 at 2:43 PM Matt Rice <rat...@gmail.com> wrote:
>>
>>
>> If Alice wants to revoke without going offline she just invokes the
>> disable message to flip the 'enabled' boolean manually.
>
>
> Which makes the revocation mechanism different from the delegation mechanism.
>
>>
>> This is kind of why I feel it is hard to describe a good explicit
>> revocation mechanism which is also policy neutral.
>
>
> Revocation is an expression of policy.
>
>>
>> At least in Mark's thesis the solution described seems to be not
>> having an explicit revocation mechanism, but leveraging the existing
>> invocation mechanism, and making revocation an arbitrary message the
>> same as any other.
>
>
> There, you said it. Not me. "leveraging the existing invocation mechanism" That's not leveraging the existing delegation mechanism. Invocation doesn't show up in Stiegler's 6 aspects of sharing.
>
> Not all capability systems need a caretaker to support revocation. Both certificate and opaque tokens, like webkeys, can support direct revocation.

I'm running out the door, but this part of Mark's thesis is exploring
a limitation of the caretaker pattern, so is using a different
mechanism.
My point is largely that in the example he gives the choices
surrounding revocation must be decided when you delegate.

Another (silly) question is with an explicit revocation mechanism can
you guarantee that an unrevokable capability is unrevokable?
In this case where revocation is built in to each capabilities logic,
by default you would presume they support unrevokable capabilities.

[John Carlson]

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.

[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.

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

[John Carlson]

I think what we’re getting at is you can revoke the original capability, or you can build complex methods with capabilities to revoke capabilities including timers, which will also need revocation at times.  When does the house of cards come tumbling down?  Probably it’s best to have a capability group that has one dead man’s switch.  But that may grant too much power if concentrated.  So several capability groups.  So now you have roles, which you can grant capabilities to and revoke them.

--
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/CACTLOFot3z2Ce4ouRL0AgHeQYYO%2BxL-2XSRd1tWFpm_TZLh3yw%40mail.gmail.com.

[Matt Rice]

I guess my point is that there already exist distributed systems with
robust revocation mechanisms which
do not take revocation as a primitive property of the system. It is
derived from simpler mechanisms.
Those could end up a complex, inconvenient and inefficient clockwork
of simpler mechanisms. But the whole point I was making is it
isn't clear to me whether or not Marc Stiegler didn't include
revocation, because he thought it was already derivable from his 6
properties without adding it as a 7th property. I feel like the first
two dynamism and attenuation get you there. In which case adding it as
a 7th property doesn't really change anything fundamentally because
the model already implied revocation. Having revocation derivable
within the system also still isn't exactly the same as saying all
things have a built in mechanism for their revocation.

When does the house of cards start tumbling down? I don't know, It
feels like there would be runtime involvement, like it's probably the
same argument people have been having for decades about garbage
collection/finalizers vs explicit memory management mechanisms where
both are viable mechanisms, but *shrug*.

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

[Alan Karp]

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

I'm running out the door, but this part of Mark's thesis is exploring
a limitation of the caretaker pattern, so is using a different
mechanism.
My point is largely that in the example he gives the choices
surrounding revocation must be decided when you delegate.

That's not a requirement in all capability systems, which is one reason I like certificate capabilities.

Another (silly) question is with an explicit revocation mechanism can
you guarantee that an unrevokable capability is unrevokable?
In this case where revocation is built in to each capabilities logic,
by default you would presume they support unrevokable capabilities.

 

In the systems I'm talking about, there's no such thing as an unrevocable capability.  In a system modeled on object references as capabilities there is, but I don't know if the holder can know that it isn't revocable.

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

[Alan Karp]

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

But the whole point I was making is it
isn't clear to me whether or not Marc Stiegler didn't include
revocation, because he thought it was already derivable from his 6
properties without adding it as a 7th property.

I checked with Marc before I added revocation to the list, and he agreed that it belongs there.  

 

I feel like the first
two dynamism and attenuation get you there. In which case adding it as
a 7th property doesn't really change anything fundamentally because
the model already implied revocation. Having revocation derivable
within the system also still isn't exactly the same as saying all
things have a built in mechanism for their revocation.

You have said that revocation isn't a separate aspect of sharing, yet you introduce the caretaker pattern to show how to revoke.  That says to me that revocation is a concept that needs to be considered whether it warrants its own mechanism or not. 

 

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

[Matt Rice]

I would not put it like "Isn't a separate aspect of sharing", I'm half
wondering if you have mixed my position with John's statement that
"Oh, and revocation is probably not “sharing” by definition." or if
the word separate is just doing the heavy lifting.

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

So it doesn't really matter if you add it or not if revocation is
already derivable from the properties on the list.
But my larger point is that the ability to derive a multitude of
application specific revocation mechanisms
is not the same as being given a single revocation mechanism. A
problem which it is very much not clear that
there is even a one size fits all revocation mechanism. My concern is
that by giving people a revocation mechanism
rather than being forced to derive one you give them the means to
avoid thinking about it deeply because it is already taken care of.

I feel like you probably could come up with a single system-wide
robust policy neutral explicit revocation mechanism, but it'll
probably involve a weird dance of application layers and system layers
with application layers specifying policy.

We've already gone over network partitioning events, and that timeouts
may be application specific, but to even revoke on network partition
is also application specific. There is no "one" way to revoke right
without involving the application. So you're going to have to describe
your "explicit revocation mechanism" a whole lot more specifically
before I'm going to accept that it is the appropriate mechanism for
all applications, and not wrong for at least one application.

So, there are two issues here. Whether it belongs on the list I'm
happy to drop, we both agree it *is* on the list by different means.

[Alan Karp]

On Wed, Feb 25, 2026 at 12:03 PM Matt Rice <rat...@gmail.com> wrote:

I would not put it like "Isn't a separate aspect of sharing", I'm half

wondering if you have mixed my position with John's statement that

"Oh, and revocation is probably not “sharing” by definition." or if

the word separate is just doing the heavy lifting.

That's probably it.

So it doesn't really matter if you add it or not if revocation is

already derivable from the properties on the list.

I agree, but without revocation on the list, won't some people believe the 1980s criticism that you can't revoke a capability?

But my larger point is that the ability to derive a multitude of

application specific revocation mechanisms

is not the same as being given a single revocation mechanism. A

problem which it is very much not clear that

there is even a one size fits all revocation mechanism. My concern is

that by giving people a revocation mechanism

rather than being forced to derive one you give them the means to

avoid thinking about it deeply because it is already taken care of.

It's not application specific revocation mechanisms; it's a revocation mechanism for all applications using a particular capability system.  In an ocap program, the only revocation mechanism you have is a caretaker.  In a certificate system, have more options.  You can set up a caretaker, or you can just tell the resource not to honor the delegation certificate. The same approach works for systems based on opaque tokens where you use token exchange for delegation.  You also save the performance cost of indirection through the caretaker, which might be an issue.

So, there are two issues here. Whether it belongs on the list I'm

happy to drop, we both agree it *is* on the list by different means.

Fair enough.

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

[Matt Rice]

That is why I was asking whether a system wide revocation mechanism
for all capabilities is policy or not.
There exist things in the legal/banking world like an "irrevocable
trust", where you bury your money in a hole too deep for you to reach
the bottom, give someone else ownership of the hole and prove to the
government that you cannot revoke the transfer. In exchange you gain
some benefit like not being taxed or something.

I'd argue that if you squint your eyes, irrevocable trusts aren't too
dissimilar to the factory pattern where you are also severing ties
between yourself and the stuff you put into the factory. Now with a
system-wide explicit revocation mechanism, you can carve out
exceptions turning the caretaker pattern inside out, to introduce
irrevocable capabilties. But at what point does this just start
looking like the mechanisms your explicit revocation mechanism is
trying to replace, except it now must satisfy all the things that all
the applications on your system need.

It feels to me if you include all that flexibility in your system
mechanism, so that it can handle all the same cases that the
performance is unlikely to be much better. It feels to me that rather
it'll end up as "good enough", which can be an impediment to doing
things the right way.
I don't know what other applications might want irrevocability, or if
the irrevocable trust translates to a capability application in
actuality.
I'm just being skeptical of the convenience of this mechanism.

Because if you're going to teach people that revocation is already
built in, and they go to revoke, but the network is down, or they
don't want revocation to be possible, or any other multitude of
reasons. They should hopefully find out before they go to revoke and
they can't, or before it get's revoked when it shouldn't have been
possible.

In other words, I'm arguing that revocation *requires* application
specific logic, including whether revocation is possible.
And that not baking that logic into the system mechanism in a policy
neutral way imposes policy on the application.

[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]

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

[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

On Wed, Feb 25, 2026 at 5:28 PM Matt Rice <rat...@gmail.com> wrote:

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.

--
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/CACTLOFqMdDKjrv5R7UZmLF%3DRFTJccskzxPU7uivAbgV0OWh_zQ%40mail.gmail.com.

[Rob Meijer]

Op donderdag 26 februari 2026 om 00:50:15 UTC+1 schreef 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 think that is one of (at least two) ways to look at revocation, basicly the caretaker way. A second (incompatible) perspective I've used in the past was:

* Revocation turns an entity into a namespace.

The differenence lies in how re-delegation is perceived. If Alan delegates something to me and I delegate it to you and Alan then revokes his delegation to me, you will lose access too in the caretaker way of thinking about delegation.
But in the entity-to-namespace way of thinking, revoking my access would turn Alan's view of me into a Rob namespace where my delegation to you would live for Allan to decide upon.

Hope I'm making sense, its been a long time since I worked on a system that used that approach to revocation, so it's a little fuzzy.

[Alan Karp]

There are two topics here.  

For one, I don't know that you can always prove that a delegation of a capability can't be revoked.  In an ocap program, you can use EQ to test the reference you've been given against that of the desired endpoint, but only if you know it.  I guess you could add a "not revocable" caveat to a certificate capability, but how do you know the caveat will be enforced?

The second is revocation needing application specific logic.  Of course.  The mechanisms I've been talking about give your application various ways to implement the revocation.

--------------
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/CACTLOFpozSRjgiwzWYEaNUpL_T6V5Co5-VAYHDc9k3TDwEoaig%40mail.gmail.com.

[Alan Karp]

On Thu, Feb 26, 2026 at 10:38 AM Rob Meijer <pib...@gmail.com> wrote:

I think that is one of (at least two) ways to look at revocation, basicly the caretaker way. A second (incompatible) perspective I've used in the past was:

* Revocation turns an entity into a namespace.

The differenence lies in how re-delegation is perceived. If Alan delegates something to me and I delegate it to you and Alan then revokes his delegation to me, you will lose access too in the caretaker way of thinking about delegation.
But in the entity-to-namespace way of thinking, revoking my access would turn Alan's view of me into a Rob namespace where my delegation to you would live for Allan to decide upon.

Alan rarely knows who you delegated to, making it hard to do anything but implicitly revoke all downstream delegations.  However, it seems that there are cases where your mechanism makes sense.

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

[Mark S. Miller]

On Thu, Feb 26, 2026 at 11:01 AM Alan Karp <alan...@gmail.com> wrote:

There are two topics here.  

For one, I don't know that you can always prove that a delegation of a capability can't be revoked.  In an ocap program, you can use EQ to test the reference you've been given against that of the desired endpoint, but only if you know it.  I guess you could add a "not revocable" caveat to a certificate capability, but how do you know the caveat will be enforced?

Beyond grant-matching EQ, I think the question is meaningless. If Alice uses a caretaker to give Bob revocable access to Carol, then Alice has given Bob irrevocable access to the caretaker (the revocability attenuator).

> desired endpoint, but only if you know it

is equivalent to

> add a "not revocable" caveat to a certificate capability

How do you know that your cap with the "not revocable" caveat is not simply on a cert for the caretaker?

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z08-H_b3OQrCn7DvL3mB3XAGH7en_wuUFvka1csUMpncw%40mail.gmail.com.

[Matt Rice]

On Thu, Feb 26, 2026 at 7:12 PM 'Mark S. Miller' via cap-talk
<cap-...@googlegroups.com> wrote:
>
>
>
> On Thu, Feb 26, 2026 at 11:01 AM Alan Karp <alan...@gmail.com> wrote:
>>
>> There are two topics here.
>>
>> For one, I don't know that you can always prove that a delegation of a capability can't be revoked. In an ocap program, you can use EQ to test the reference you've been given against that of the desired endpoint, but only if you know it. I guess you could add a "not revocable" caveat to a certificate capability, but how do you know the caveat will be enforced?
>
>
> Beyond grant-matching EQ, I think the question is meaningless. If Alice uses a caretaker to give Bob revocable access to Carol, then Alice has given Bob irrevocable access to the caretaker (the revocability attenuator).
>

When I wrote this by guarantee I meant that two people can read the
implementation, and come to some agreement that the sources do not
implement a caretaker... Not a machine checked guarantee type of
thing, or a factory type of pattern that is guaranteed to give out
non-revocable capabilities... (that people can similarly agree does
not give out revocable capabilities).

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD7HxqD-tkp9eJb07VjqWPsjPgucDanKNC%2BCX5%3DtAptWeQ%40mail.gmail.com.