Group delegation

[Alan Karp]

This use case came up in the Trusted AI Agent Working Group.  I'd like your feedback before I post the following on the group Slack channel.

-----------------------------

Say that you have a distributed system and want to delegate to a member of a defined group, but you don’t care which member.  This situation might arise if you’re using a message broker that group members subscribe to, but you don't want the broker to have the permission.

In an “object reference as capability” (ocap) system, you’d use a sealed box.  Put the capability you want to delegate in the box and send the box.  You can define group membership as those parties that have the corresponding unsealer.  

You might want to have a separately auditable capability for each group member.  If you know the members ahead of time, you can just send a bunch of sealed boxes, either separately or in a box sealed with the group’s unsealer.  Things are more complicated if you don’t know the group membership ahead of time.  In that case, you can seal a capability in the group box that the recipient can invoke to ask for a capability to a caretaker for the target object.  Bearer tokens can be used the same way by substituting encryption/decryption for sealing and unsealing.

There’s a rather direct translation to certificate capabilities.  In the first example, you can create a delegation certificate to the group’s public key and give all group members the corresponding secret key.  Similarly, you can issue a separate certificate for each of the group members or issue one certificate to a list of public keys, one per group member.  

You also have options when you don’t know the group membership at the time you create the delegation certificate.  One approach that works like rights amplification (I prefer the term rights combination, but nobody else does.) is that any use of the delegation must be signed by a secret key proving group measurement instead of the secret key corresponding to the one the certificate is issued to.

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

[Mark S. Miller]

On Fri, Mar 13, 2026 at 4:29 PM Alan Karp <alan...@gmail.com> wrote:

This use case came up in the Trusted AI Agent Working Group.  I'd like your feedback before I post the following on the group Slack channel.

-----------------------------

Say that you have a distributed system and want to delegate to a member of a defined group, but you don’t care which member.

I'm confused by this phrasing. Do you want to delegate to exactly one member, excluding all others? Or do you want to delegate to all, where each individually has the full delegated authority? I'll answer below assuming the latter, since it is simpler: essentially a multicast. The former is more interesting, but I have no idea if your audience would find it motivating.

 

  This situation might arise if you’re using a message broker that group members subscribe to, but you don't want the broker to have the permission.

Attn Christopher Allen (cc'ed). In Christopher's system, the broker is not a separate agent, but is synthesized cryptographically by the participants. It is not a thing that can act independently.

 

In an “object reference as capability” (ocap) system, you’d use a sealed box.  Put the capability you want to delegate in the box and send the box.  You can define group membership as those parties that have the corresponding unsealer.  

The trick there is how you administer group membership over time, if it not a group whose membership you define. If the members interact with something else that provides them these unsealers, then you've recreated your original problem.

If it is a group whose membership you define, why were you even concerned about a broker? Just delegate separately to each member directly.

 

You might want to have a separately auditable capability for each group member.  If you know the members ahead of time, you can just send a bunch of sealed boxes, either separately or in a box sealed with the group’s unsealer.

If you know the members ahead of time, why bother with the sealed box. Just send each a separately auditable capability, as in SCoopFS and Horton.

 

  Things are more complicated if you don’t know the group membership ahead of time.

Yes. If you're not the one defining the group, who/what does? Is this the broker you mention above?

 

  In that case, you can seal a capability in the group box

What's the "group box"?

 

that the recipient can invoke to ask for a capability to a caretaker for the target object.

This seems silly. If anyone with the cap to the group box can ask for a separate caretaker, those caretakers can be separately revoked. By the holder of the power to revoke has no info about why they'd want to revoke one vs another.

 

  Bearer tokens can be used the same way by substituting encryption/decryption for sealing and unsealing.

You're speaking at the crypto implementation level of abstraction without first being clear what problem you're trying to solve at the access control or ocap non-implementation level of abstraction. In any case, how does a "Bearer token" differ from an ocap? Is this the "caps as keys" column from Cap Myths Demolished that is distinct from the ocap column?

I think we need clarity on what you're trying to accomplish independent of the implementation before it is useful to go on to discuss certs or whatever.

There’s a rather direct translation to certificate capabilities.  In the first example, you can create a delegation certificate to the group’s public key and give all group members the corresponding secret key.  Similarly, you can issue a separate certificate for each of the group members or issue one certificate to a list of public keys, one per group member.  

You also have options when you don’t know the group membership at the time you create the delegation certificate.  One approach that works like rights amplification (I prefer the term rights combination, but nobody else does.) is that any use of the delegation must be signed by a secret key proving group measurement instead of the secret key corresponding to the one the certificate is issued to.

--------------
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/CANpA1Z1GH8VgwZwp-K4yoEMCxuThpBy5YkFc7dAtF2cgXu2UAA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Sun, Mar 15, 2026 at 5:58 PM Mark S. Miller <eri...@gmail.com> wrote:

On Fri, Mar 13, 2026 at 4:29 PM Alan Karp <alan...@gmail.com> wrote:

This use case came up in the Trusted AI Agent Working Group.  I'd like your feedback before I post the following on the group Slack channel.

-----------------------------

Say that you have a distributed system and want to delegate to a member of a defined group, but you don’t care which member.

I'm confused by this phrasing. Do you want to delegate to exactly one member, excluding all others? Or do you want to delegate to all, where each individually has the full delegated authority? I'll answer below assuming the latter, since it is simpler: essentially a multicast. The former is more interesting, but I have no idea if your audience would find it motivating.

 

  This situation might arise if you’re using a message broker that group members subscribe to, but you don't want the broker to have the permission.

If the broker defines membership in the group and the broker wants the permission, what prevents the broker from including itself in the group? Likewise, what prevents the broker from subscribing to itself?

 

Attn Christopher Allen (cc'ed). In Christopher's system, the broker is not a separate agent, but is synthesized cryptographically by the participants. It is not a thing that can act independently.

Spoiler: Christopher's system was inspired by the Club system but went significantly beyond it. 

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Sun, Mar 15, 2026 at 6:15 PM Mark S. Miller <eri...@gmail.com> wrote:

On Sun, Mar 15, 2026 at 5:58 PM Mark S. Miller <eri...@gmail.com> wrote:

On Fri, Mar 13, 2026 at 4:29 PM Alan Karp <alan...@gmail.com> wrote:

This use case came up in the Trusted AI Agent Working Group.  I'd like your feedback before I post the following on the group Slack channel.

-----------------------------

Say that you have a distributed system and want to delegate to a member of a defined group, but you don’t care which member.

I'm confused by this phrasing. Do you want to delegate to exactly one member, excluding all others? Or do you want to delegate to all, where each individually has the full delegated authority? I'll answer below assuming the latter, since it is simpler: essentially a multicast. The former is more interesting, but I have no idea if your audience would find it motivating.

 

  This situation might arise if you’re using a message broker that group members subscribe to, but you don't want the broker to have the permission.

If the broker defines membership in the group and the broker wants the permission, what prevents the broker from including itself in the group? Likewise, what prevents the broker from subscribing to itself?

 

Attn Christopher Allen (cc'ed). In Christopher's system, the broker is not a separate agent, but is synthesized cryptographically by the participants. It is not a thing that can act independently.

Spoiler: Christopher's system was inspired by the Club system but went significantly beyond it. 

but goes significantly beyond it.

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Sun, Mar 15, 2026 at 6:16 PM Mark S. Miller <eri...@gmail.com> wrote:

On Sun, Mar 15, 2026 at 6:15 PM Mark S. Miller <eri...@gmail.com> wrote:

On Sun, Mar 15, 2026 at 5:58 PM Mark S. Miller <eri...@gmail.com> wrote:

On Fri, Mar 13, 2026 at 4:29 PM Alan Karp <alan...@gmail.com> wrote:

This use case came up in the Trusted AI Agent Working Group.  I'd like your feedback before I post the following on the group Slack channel.

-----------------------------

Say that you have a distributed system and want to delegate to a member of a defined group, but you don’t care which member.

I'm confused by this phrasing. Do you want to delegate to exactly one member, excluding all others? Or do you want to delegate to all, where each individually has the full delegated authority? I'll answer below assuming the latter, since it is simpler: essentially a multicast. The former is more interesting, but I have no idea if your audience would find it motivating.

 

  This situation might arise if you’re using a message broker that group members subscribe to, but you don't want the broker to have the permission.

If the broker defines membership in the group and the broker wants the permission, what prevents the broker from including itself in the group? Likewise, what prevents the broker from subscribing to itself?

 

Attn Christopher Allen (cc'ed). In Christopher's system, the broker is not a separate agent, but is synthesized cryptographically by the participants. It is not a thing that can act independently.

Spoiler: Christopher's system was inspired by the Club system but went significantly beyond it. 

but goes significantly beyond it.

https://developer.blockchaincommons.com/clubs/history/

 

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

[Alan Karp]

Replies inline

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

On Sun, Mar 15, 2026 at 5:58 PM Mark S. Miller <eri...@gmail.com> wrote:

On Fri, Mar 13, 2026 at 4:29 PM Alan Karp <alan...@gmail.com> wrote:

This use case came up in the Trusted AI Agent Working Group.  I'd like your feedback before I post the following on the group Slack channel.

-----------------------------

Say that you have a distributed system and want to delegate to a member of a defined group, but you don’t care which member.

I'm confused by this phrasing. Do you want to delegate to exactly one member, excluding all others? Or do you want to delegate to all, where each individually has the full delegated authority? I'll answer below assuming the latter, since it is simpler: essentially a multicast. The former is more interesting, but I have no idea if your audience would find it motivating.

Sorry about that.  I tried to abstract away what I thought were superfluous details, but I guess I got too abstract.  Let me be more specific.

An example of this case is publish/subscribe through a message broker, such as Kafka.  You are publishing messages in some topic that are delivered to one or more of the subscribers to that topic.  As publisher, you do not control who subscribes, but you know they are authorized to receive the messages.  In the case of interest here the messages contain capabilities that you do not want the message broker to have.

 

  This situation might arise if you’re using a message broker that group members subscribe to, but you don't want the broker to have the permission.

Attn Christopher Allen (cc'ed). In Christopher's system, the broker is not a separate agent, but is synthesized cryptographically by the participants. It is not a thing that can act independently.

 

That's not the case of interest. 

In an “object reference as capability” (ocap) system, you’d use a sealed box.  Put the capability you want to delegate in the box and send the box.  You can define group membership as those parties that have the corresponding unsealer.  

The trick there is how you administer group membership over time, if it not a group whose membership you define. If the members interact with something else that provides them these unsealers, then you've recreated your original problem.

You trust the party that determines group membership, so it can give the unsealer to members of the group.  The question is how you get the capabilities through an untrusted message broker.

If it is a group whose membership you define, why were you even concerned about a broker? Just delegate separately to each member directly.

My bad for the confusing way I described the problem.  A somewhat silly example is a service you provide that defines a group for load balancing.  I publish a message through a third party message broker that any one of your subscribers processes.

 

You might want to have a separately auditable capability for each group member.  If you know the members ahead of time, you can just send a bunch of sealed boxes, either separately or in a box sealed with the group’s unsealer.

If you know the members ahead of time, why bother with the sealed box. Just send each a separately auditable capability, as in SCoopFS and Horton.

You don't have a way to communicate directly with the group members.  The message is going through a message broker that you don't want to have the capability.

 

  Things are more complicated if you don’t know the group membership ahead of time.

Yes. If you're not the one defining the group, who/what does? Is this the broker you mention above?

 

  In that case, you can seal a capability in the group box

What's the "group box"?

It's a box that's opened by a single unsealer possessed by every group member.

 

that the recipient can invoke to ask for a capability to a caretaker for the target object.

This seems silly. If anyone with the cap to the group box can ask for a separate caretaker, those caretakers can be separately revoked. By the holder of the power to revoke has no info about why they'd want to revoke one vs another.

Fair point.  How about if they want to record which of the group members used the capability?

 

  Bearer tokens can be used the same way by substituting encryption/decryption for sealing and unsealing.

You're speaking at the crypto implementation level of abstraction without first being clear what problem you're trying to solve at the access control or ocap non-implementation level of abstraction. In any case, how does a "Bearer token" differ from an ocap? Is this the "caps as keys" column from Cap Myths Demolished that is distinct from the ocap column?

Yes, "caps as keys" is what I'm thinking about.  The difference I see is that knowing the bits of an object reference doesn't give you the permission but knowing the bits of a bearer token does.

I think we need clarity on what you're trying to accomplish independent of the implementation before it is useful to go on to discuss certs or whatever. 

I agree.

[Alan Karp]

On Sun, Mar 15, 2026 at 6:15 PM Mark S. Miller <eri...@gmail.com> wrote:

If the broker defines membership in the group and the broker wants the permission, what prevents the broker from including itself in the group? Likewise, what prevents the broker from subscribing to itself?

The message broker does not define group membership.  That's done by someone on the subscribe side of the channel.

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

[Mark S. Miller]

I think we need more clarity on what defines a group? / how a group is defined? / what kind of thing a group is? / how does its membership change over time? Until I have a clearer picture of that, the rest seems to vague for me to process.

> The difference I see is that knowing the bits of an object reference doesn't give you the permission but knowing the bits of a bearer token does.

That is *not* the difference, though it is somewhat related. See figures 11,12,13 of Capability Myths Demolished https://papers.agoric.com/papers/capability-myths-demolished/abstract/ . Also attached. A system based on unforgeable references can be a caps-as-keys model, establishing that the core differences between the models are abstract enough to be somewhat independent of the unforgeable refs vs bits distinction. OTOH, a caps-as-bits implementation likely fails the F test below, and so pushes any caps-as-bits system towards the caps-as-keys column.

Suggestion: abstract explanations by themselves can be hard to understand. But rather than add concreteness with implementation details (bits, certs, ...), add concreteness with specific example scenarios (Alice, Bob, Carol).

I cannot yet tell whether your message broker would even appear in such an abstract statement of the problem. But my questions above about group membership and membership evolution would.

--

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/CANpA1Z0FZ4pJ1M4TibFKmHMv7MBftg3PsZ-2aq9%3DSHwRfb_JSA%40mail.gmail.com.

[Mark S. Miller]

For me, the most important distinction between caps-as-keys vs ocaps is the E test of Figure 13: "Are resources also subjects?" This accounts for the greater uniformity of Figure 12 over Figure 11. The missing line in Figure 11 is the F test, which a caps-as-bits system would fail. That missing line makes confinement impossible.

[Alan Karp]

On Mon, Mar 16, 2026 at 3:17 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

I think we need more clarity on what defines a group? / how a group is defined? / what kind of thing a group is? / how does its membership change over time? Until I have a clearer picture of that, the rest seems to vague for me to process.

The E-Speak Beta version required a capability to publish on a topic and a separate one to subscribe to that topic.  In that system, the topic creator handed out permissions to publish and/or subscribe.  That was who decided what constitutes a group by giving each member a subscribe capability.

That is *not* the difference, though it is somewhat related. See figures 11,12,13 of Capability Myths Demolished https://papers.agoric.com/papers/capability-myths-demolished/abstract/ .

 

Help me understand the difference.  As I read Figure 12, Alice can only send the capability to Bob if she has an object reference to him.  In Figure 11; Alice can send a message to Bob without being given explicit permission, but can't Bob's address be unguessable?

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

[Mark S. Miller]

On Mon, Mar 16, 2026 at 3:50 PM Alan Karp <alan...@gmail.com> wrote:

On Mon, Mar 16, 2026 at 3:17 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

I think we need more clarity on what defines a group? / how a group is defined? / what kind of thing a group is? / how does its membership change over time? Until I have a clearer picture of that, the rest seems to vague for me to process.

The E-Speak Beta version required a capability to publish on a topic and a separate one to subscribe to that topic.  In that system, the topic creator handed out permissions to publish and/or subscribe.  That was who decided what constitutes a group by giving each member a subscribe capability.

So in that system, just publish whatever you want the subscribers to see/have. The topic creator can always subscribe to their own topic, so it does not make sense to try to deny the topic creator the ability to receive the messages. No sealers/unsealers needed.

 

That is *not* the difference, though it is somewhat related. See figures 11,12,13 of Capability Myths Demolished https://papers.agoric.com/papers/capability-myths-demolished/abstract/ .

 

Help me understand the difference.  As I read Figure 12, Alice can only send the capability to Bob if she has an object reference to him.  In Figure 11; Alice can send a message to Bob without being given explicit permission, but can't Bob's address be unguessable?

That's exactly the right question and it reveals my confusion when I wrote it! Thanks!

Caps-as-unguessable bits pass the F test, filling in the line missing from Figure 11. On ocaps, that line is *stronger* in that the authorization cannot be transmitted over a bit channel. So the two issues are more orthogonal than I thought when writing the previous response. A caps-as-bits system still cannot confine, but that's beyond what is relevant to this conversation.

SPKI(*) remains the perfect example of a caps-as-keys system. The names of the subjects are not assumed protected in any way. Alice can give Bob any permission she has without needing any permission to permit Bob.

(*) ignoring the misleading "do-not-delegate" bit.

 

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

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Mon, Mar 16, 2026 at 4:20 PM Mark S. Miller <eri...@gmail.com> wrote:

On Mon, Mar 16, 2026 at 3:50 PM Alan Karp <alan...@gmail.com> wrote:

On Mon, Mar 16, 2026 at 3:17 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

I think we need more clarity on what defines a group? / how a group is defined? / what kind of thing a group is? / how does its membership change over time? Until I have a clearer picture of that, the rest seems to vague for me to process.

The E-Speak Beta version required a capability to publish on a topic and a separate one to subscribe to that topic.  In that system, the topic creator handed out permissions to publish and/or subscribe.  That was who decided what constitutes a group by giving each member a subscribe capability.

So in that system, just publish whatever you want the subscribers to see/have. The topic creator can always subscribe to their own topic, so it does not make sense to try to deny the topic creator the ability to receive the messages. No sealers/unsealers needed.

 

That is *not* the difference, though it is somewhat related. See figures 11,12,13 of Capability Myths Demolished https://papers.agoric.com/papers/capability-myths-demolished/abstract/ .

 

Help me understand the difference.  As I read Figure 12, Alice can only send the capability to Bob if she has an object reference to him.  In Figure 11; Alice can send a message to Bob without being given explicit permission, but can't Bob's address be unguessable?

That's exactly the right question and it reveals my confusion when I wrote it! Thanks!

Caps-as-unguessable bits pass the F test, filling in the line missing from Figure 11. On ocaps, that line is *stronger* in that the authorization cannot be transmitted over a bit channel. So the two issues are more orthogonal than I thought when writing the previous response. A caps-as-bits system still cannot confine,

Even that is not necessarily true in theory. If the confinement box perfectly confines bits too -- overt+side+covert channels together have zero bandwidth -- then you could confine caps-as-unguessable-bits. But that's never feasible, so you cannot in practice.

 

but that's beyond what is relevant to this conversation.

SPKI(*) remains the perfect example of a caps-as-keys system. The names of the subjects are not assumed protected in any way. Alice can give Bob any permission she has without needing any permission to permit Bob.

(*) ignoring the misleading "do-not-delegate" bit.

 

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

--

  Cheers,
  --MarkM

--

  Cheers,
  --MarkM