Certificate capabilities

[Alan Karp]

It's not unusual for a certificate delegation to be for multiple methods and multiple resources.  For example, you can delegate read/write permission to several files in a single certificate.  I've been insisting that such a delegation certificate can't be used in an invocation; you have to delegate to yourself exactly the one resource you want to use.  My intuition is that a capability must designate a specific object.

I'm currently reviewing a spec that doesn't have that restriction, and I'm having trouble justifying that constraint.  Are there any issues with using a multi-resource delegation in an invocation aside from an extra line in the spec telling you how to designate the specific resource?

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

[Raoul Duke]

Doesn't that assume there's a good, widespread definition of object? I mean a directory ocap is also about however many things are in the directory? Or, what if i want a single collaborative document file but want only certain people to be able to edit different subsets? Seems to need clarity about how the OS, and/or the app level, constrains the possible "objects". And so cross-platform becomes complicated. Also the objects ideally are kept "solid" so the capability continues to make sense. Or so warnings can be generated if someone tries to alter an object that has caps for it out in the wild.

[Matt Rice]

On Tue, Jun 16, 2026 at 11:48 AM Alan Karp <alan...@gmail.com> wrote:
>
> It's not unusual for a certificate delegation to be for multiple methods and multiple resources. For example, you can delegate read/write permission to several files in a single certificate. I've been insisting that such a delegation certificate can't be used in an invocation; you have to delegate to yourself exactly the one resource you want to use. My intuition is that a capability must designate a specific object.
>
> I'm currently reviewing a spec that doesn't have that restriction, and I'm having trouble justifying that constraint. Are there any issues with using a multi-resource delegation in an invocation aside from an extra line in the spec telling you how to designate the specific resource?

I was never familiar with this restriction in non-certificate systems
until you had brought it up in a previous conversation.
I can kind of justify it though based on an argument against
convenience. Let's say that a father has a certificate for his
tool-shop
containing all the tools, including some dangerous power tools. It can
be more convenient to just share the list of tools (it's already
made),
than to say share a certificate granting access to just a single
screwdriver to someone who may not be capable of using the entire list
of tools safely.

People are more likely to over-share more than the necessary amount of
authority if their unit of sharing is a bucket in which they store
multiple objects.
I have less concerns about this than say directories, which are
mutable and can suffer from forgetfulness about what you've shared in
the bucket and who you've shared it with previously.
That is to say, in a certificate it seems like the full receipt of
authorities that are granted are visible at grant time, so I struggle
to see there being a problem with "confusion".
But I can imagine a situation in which it is easier to over-share,
than it is to go through the process of creating a new certificate
with just the least authority necessary for the task.
At the very least it doesn't promote or promise that the natural unit
of sharing is the least authority way.

[John Carlson]

In this case, I’m confused between delegation and attenuation.  Can you have an attenuated certificate?

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/CANpA1Z19m%2Bnwboe8H_SrwR%2B%2BuW8ZgtwQNCnMNSENVt07tqFqDA%40mail.gmail.com.

[Alan Karp]

Response inline.

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

On Tue, Jun 16, 2026 at 12:32 PM Matt Rice <rat...@gmail.com> wrote:

On Tue, Jun 16, 2026 at 11:48 AM Alan Karp <alan...@gmail.com> wrote:
>
> It's not unusual for a certificate delegation to be for multiple methods and multiple resources.  For example, you can delegate read/write permission to several files in a single certificate.  I've been insisting that such a delegation certificate can't be used in an invocation; you have to delegate to yourself exactly the one resource you want to use.  My intuition is that a capability must designate a specific object.
>
> I'm currently reviewing a spec that doesn't have that restriction, and I'm having trouble justifying that constraint.  Are there any issues with using a multi-resource delegation in an invocation aside from an extra line in the spec telling you how to designate the specific resource?

I was never familiar with this restriction in non-certificate systems
until you had brought it up in a previous conversation.
I can kind of justify it though based on an argument against
convenience. Let's say that a father has a certificate for his
tool-shop
containing all the tools, including some dangerous power tools. It can
be more convenient to just share the list of tools (it's already
made),
than to say share a certificate granting access to just a single
screwdriver to someone who may not be capable of using the entire list
of tools safely.

A certificate for the workshop that contains all the tools is not the case I'm talking about.  I'm talking

about one certificate that enumerates the flat head, Phillips, and star screwdrivers.  When you want to 

remove a screw, you designate the appropriate screwdriver.  The question is do you do that with a derived

certificate that lists only the one you are using, or can you use the composite certificate and

denote which one you are using separately?

People are more likely to over-share more than the necessary amount of
authority if their unit of sharing is a bucket in which they store
multiple objects.

I don't think that's relevant because the certificate enumerates the specific

resources rather than a collection where you might forget what's in it.

 

I have less concerns about this than say directories, which are
mutable and can suffer from forgetfulness about what you've shared in
the bucket and who you've shared it with previously.

I consider a directory to be a single object that has a set of methods.  One of them

might be "list contents," but the API may not give you access to the individual objects

inside it.

That is to say, in a certificate it seems like the full receipt of
authorities that are granted are visible at grant time, so I struggle
to see there being a problem with "confusion".

I agree.

But I can imagine a situation in which it is easier to over-share,
than it is to go through the process of creating a new certificate
with just the least authority necessary for the task.
At the very least it doesn't promote or promise that the natural unit
of sharing is the least authority way.

I don't think there's any difference in authority.  You necessarily are designating

a single resource.  The only difference is how you do it.  In one case, you are using

the multi-resource certificate and specifying the object some other way.  In the other 

case, you are creating a certificate that designates the single resource you are invoking.

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

[Alan Karp]

On Tue, Jun 16, 2026 at 12:38 PM John Carlson <yott...@gmail.com> wrote:

In this case, I’m confused between delegation and attenuation.  Can you have an attenuated certificate?

Delegation is the process of you giving me a set of permissions.  Attenuation means you can give me fewer permissions than you have.

Most delegation certificates attenuate the permissions of the certificate they are derived from.

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

[Matt Rice]

On Tue, Jun 16, 2026 at 6:00 PM Alan Karp <alan...@gmail.com> wrote:
>
> Response inline.
>
> --------------
> Alan Karp
>
>
> On Tue, Jun 16, 2026 at 12:32 PM Matt Rice <rat...@gmail.com> wrote:
>>
>> On Tue, Jun 16, 2026 at 11:48 AM Alan Karp <alan...@gmail.com> wrote:
>> >
>> > It's not unusual for a certificate delegation to be for multiple methods and multiple resources. For example, you can delegate read/write permission to several files in a single certificate. I've been insisting that such a delegation certificate can't be used in an invocation; you have to delegate to yourself exactly the one resource you want to use. My intuition is that a capability must designate a specific object.
>> >
>> > I'm currently reviewing a spec that doesn't have that restriction, and I'm having trouble justifying that constraint. Are there any issues with using a multi-resource delegation in an invocation aside from an extra line in the spec telling you how to designate the specific resource?
>>
>> I was never familiar with this restriction in non-certificate systems
>> until you had brought it up in a previous conversation.
>> I can kind of justify it though based on an argument against
>> convenience. Let's say that a father has a certificate for his
>> tool-shop
>> containing all the tools, including some dangerous power tools. It can
>> be more convenient to just share the list of tools (it's already
>> made),
>> than to say share a certificate granting access to just a single
>> screwdriver to someone who may not be capable of using the entire list
>> of tools safely.
>
>
> A certificate for the workshop that contains all the tools is not the case I'm talking about. I'm talking
> about one certificate that enumerates the flat head, Phillips, and star screwdrivers. When you want to
> remove a screw, you designate the appropriate screwdriver. The question is do you do that with a derived
> certificate that lists only the one you are using, or can you use the composite certificate and
> denote which one you are using separately?
>>

I feel like I understand the distinction better when stated this way,
and I'm not sure what to think.
If the certificate is proof of ownership of the capability, it does
reveal proof of ownership of things not invoked
to refer to the certificate. The risks as I see it are still caused
by mixing up resources.
I am reminded of the rust movie accident where there was a bucket that
mixed blanks and real bullets.
But I don't see that being particularly different from a normal
capability system where perhaps you can invoke the wrong object.
Except perhaps with a certificate system you may be relying on
certificates issued by others.
Where as in a capability system the wielder is the one putting
capabilities into directories, so there is a slight your mess vs their
mess difference.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3zppnTTOBu6oejCm%2BHqEirCB_vs2beEKrsSFBBkmfBPQ%40mail.gmail.com.

[Alan Karp]

Let me restate my conundrum.

I define a capability as being an unforgeable, transferable, permission to use the thing it designates. 

Based on that definition, a certificate delegating multiple resources is not a capability; it's just a

delegation.  A certificate delegating a single resource is a capability.  I haven't seen that distinction

before.

Maybe that's because object reference as capability necessarily designates a specific object.  Most certificate

capability systems do that, too.  I've only encountered the compound delegation certificates recently. Those 

systems submit the compound delegation in an invocation, designating the specific resource being invoked by 

a separate designation of the resource in the invocation certificate.  That feels off to me, but I can't come up

with a convincing reason why.

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

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

[Matt Rice]

On Tue, Jun 16, 2026 at 8:06 PM Alan Karp <alan...@gmail.com> wrote:
>
> Let me restate my conundrum.
>
> I define a capability as being an unforgeable, transferable, permission to use the thing it designates.
> Based on that definition, a certificate delegating multiple resources is not a capability; it's just a
> delegation. A certificate delegating a single resource is a capability. I haven't seen that distinction
> before.
>
> Maybe that's because object reference as capability necessarily designates a specific object. Most certificate
> capability systems do that, too. I've only encountered the compound delegation certificates recently. Those
> systems submit the compound delegation in an invocation, designating the specific resource being invoked by
> a separate designation of the resource in the invocation certificate. That feels off to me, but I can't come up
> with a convincing reason why.
>

Could you comment on how naming of resources works in multiple
resource delegation?
Because one thing that bothers me is, a certificate delegating a
single resource can go one of two ways.
It can name the resource within, (named by the issuer), or it can
leave the resource as an opaque identifier to be named by the
receiver.

I'm unfamiliar with any capability systems that have capabilities
named by their issuer or origin. It seems like trouble.
I find it unfathomable that a certificate with multiple resources
follows the pattern where resources are named by the receiver.
How would such a system distinguish the individual resources delegated?

I probably would not have considered a certificate delegating a single
resource, which carries its name from the issuer to be a capability.
Because issuer supplied names shouldn't necessarily be trusted. The
closest I can come up with in a capability to something that
distinguishes
one capability from another in the capability systems I'm familiar
with is the "allegedType", which it seems people felt the need to
ensure that it
could not be interpreted as a definitive type enough to name it
alleged. "allegedName" sounds silly btw.

This is not a problem of invocation of a resource within a
multi-resource delegation though. But something which feels like an
underlying problem.
I still don't like that supplying a multi-resource certificate as
proof of the single resource you tend to invoke seems to reveal more
information than is necessary to invoke the single resource.

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

[Alan Karp]

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

On Tue, Jun 16, 2026 at 8:59 PM Matt Rice <rat...@gmail.com> wrote:

Could you comment on how naming of resources works in multiple
resource delegation?

Names part of the application API and are set by the creator of the root certificate. 

How it's done is system specific.  For example, UCAN splits the resource designation 

into two parts, the "subject" and a "policy."  You can see an example at 

https://github.com/ucan-wg/delegation#resource.

Although I can't find an example, at least an earlier version supported specifications

like *.mp3.

 

Because one thing that bothers me is, a certificate delegating a
single resource can go one of two ways.
It can name the resource within, (named by the issuer), or it can
leave the resource as an opaque identifier to be named by the
receiver.

An opaque identifier is possible, but I haven't seen that done.  The important thing

is that the delegate knows what resource the certificate is for.

I'm unfamiliar with any capability systems that have capabilities
named by their issuer or origin. It seems like trouble.
I find it unfathomable that a certificate with multiple resources
follows the pattern where resources are named by the receiver.
How would such a system distinguish the individual resources delegated?

The issuer of the root certificate names the resources.  The receiver of the 

delegation has a local name for the certificate.  Is that your concern?

I probably would not have considered a certificate delegating a single
resource, which carries its name from the issuer to be a capability.
Because issuer supplied names shouldn't necessarily be trusted.

The issuer supplied name combined with the resource address corresponds

to the memory location of an object in an ocap system.  It tells the runtime

what to operate on.  I don't see any threat there.

This is not a problem of invocation of a resource within a
multi-resource delegation though. But something which feels like an
underlying problem.
I still don't like that supplying a multi-resource certificate as
proof of the single resource you tend to invoke seems to reveal more
information than is necessary to invoke the single resource.

You don't have a choice because proving the invocation request is authorized

requires access to the whole delegation chain.

> --------------
> Alan Karp

[Matt Rice]

Yes, that is basically my concern.

The veracity of issuer supplied names are pretty suspect
and highly dependent upon the trust relationship between the issuer
and the receiver.

For instance if I have a capability named "inbox for the bob donation fund",
which I didn't receive from bob, but rather received from one Mr.
Ponzi whom I have no real
relationship with, despite knowing and trusting bob the purported
destination (Mr. Ponzi may know that and exploit it).

I'm pretty skeptical of anything involving remote human meaningful naming.
Moreso if these are objects like inboxes rather than data files like *.mp3.

>>>
>>>
>>> I probably would not have considered a certificate delegating a single
>>> resource, which carries its name from the issuer to be a capability.
>>> Because issuer supplied names shouldn't necessarily be trusted.
>
>
> The issuer supplied name combined with the resource address corresponds
> to the memory location of an object in an ocap system. It tells the runtime
> what to operate on. I don't see any threat there.
>>>
>>>
>>> This is not a problem of invocation of a resource within a
>>> multi-resource delegation though. But something which feels like an
>>> underlying problem.
>>> I still don't like that supplying a multi-resource certificate as
>>> proof of the single resource you tend to invoke seems to reveal more
>>> information than is necessary to invoke the single resource.
>
>
> You don't have a choice because proving the invocation request is authorized
> requires access to the whole delegation chain.
>>
>>
>> > --------------
>> > 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/CANpA1Z3LXdQxbDX3uoNC-3xwWD_ZVsiuGDV8r%3DXEh0XeKqhWXg%40mail.gmail.com.

[Alan Karp]

On Wed, Jun 17, 2026 at 11:18 AM Matt Rice <rat...@gmail.com> wrote:

>
> The issuer of the root certificate names the resources.  The receiver of the
> delegation has a local name for the certificate.  Is that your concern?

Yes, that is basically my concern.

The veracity of issuer supplied names are pretty suspect
and highly dependent upon the trust relationship between the issuer
and the receiver.

For instance if I have a capability named "inbox for the bob donation fund",
which I didn't receive from bob, but rather received from one Mr.
Ponzi whom I have no real
relationship with, despite knowing and trusting bob the purported
destination (Mr. Ponzi may know that and exploit it).

I'm pretty skeptical of anything involving remote human meaningful naming.
Moreso if these are objects like inboxes rather than data files like *.mp3.

You've answered your own question.  You won't trust the name in the certificate

you got from Mr. Ponzi because you don't have a trust relationship with him.  We

always have to evaluate ways in which we are made vulnerable by interacting

with others.

Is there an alternative?

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

[Matt Rice]

People like me should know better, the problem with these sorts of things
is people start out only ever interacting with system granted objects,
and objects they receive from people they trust, and then their worldview
expands but their usage of it does not change as their change in behavior
changes the risk profile.

I don't get the "you've answered your own question" part, because
I know enough to know I won't use a system that works this way.
It's too easy to just rely on remote names, only realizing later that
you messed up by doing so.

If misrepresented trust was the common case people were attuned to
rather than modify their behavior
to avoid the noise in the signal, they would be better served by
avoiding the system which introduces noise in the signal.

> Is there an alternative?

I always felt that the alternative was well known, and this was why we
don't transfer capabilities around along with human meaningful names.
differentiate them by opaque blobs that make people's eyes glaze over.


> --------------
> Alan Karp

[Matt Rice]

I think I should state it another way:

If the appropriate response to receiving a named resource is to
disregard the name because it cannot be trusted,
why should we be teaching people not to trust the name, and instead
just not include the name.

[Alan Karp]

If the appropriate response to receiving a named resource is to

disregard the name because it cannot be trusted,

why should we be teaching people not to trust the name, and instead

just not include the name.

It's not the name that you trust or don't trust.  It's the provider of the name that matters. 

You'll still have to call it something, and that something is unlikely to be an opaque

identifier.

I think we're getting into psychology here, which is not my area of expertise.

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

[Matt Rice]

I guess my question is what other capability systems assign remotely
provided names during designation rather than
opaque identifiers. I am familiar with zero. Everything I know treats
capabilities as having opaque identifiers.
Until users themselves assign them human meaningful local names.

The pet name systems I'm familiar with that have discussed sharing
names have done so through a different mechanism than capability
channels.
So Bob would separately share a capability, and a view which assigns
that capability to "Bob's mom" or "Mom according to Bob".
When Bob shares a "Mom" capability, that is unlikely to be appropriate
for anyone outside Bob's immediate family.

The problem is that names alone lose the frame of reference to their
origin once they've been saved/stored somewhere.
By avoiding remote names entirely, we can at least ensure that all
names are locally relevant ones.

[Alan Karp]

We discussed this issue at today's meeting and came up with an answer to my concern. 

First the setup (because I've added cap-talk).

In a certificate capability system, you can delegate permission to use multiple, perhaps unrelated, resources, say /a/foo and /b/bar, in a single certificate.  There's no way to express that in an object reference as capability (ocap) system.  (You can delegate to a collection object, but that's not the same thing.)  With certificates, there are two ways to designate the resource.  You can use the certificate itself if it is for a single resource, or you can designate the resource in the invocation with the certificate as proof that your request is authorized.

My concern

Do we lose any of the good properties of ocaps if we use something other than the certificate to designate the resource?

The answer

Yes.  In an ocap system, the invoked object gets no information on other ocaps you may hold.  That's not the case if you use the certificate as evidence.

Are there more significant differences?

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

[David Nicol]

What exactly is an "invocation?" In my developing system Op256, there are "assertions" which are signed references to claims, which can be revoked, as the underlying mechanism is DHT mutables. Also there are "operations" which start with an operator identifier, followed by argument data appropriate to the operator. In these terms, a "certificate" is a kind of assertion, which takes two pieces: the claim, and the certifying entity's unrevoked signature on a reference to the claim. Meanings like "this certificate is only valid when signed by this specific certifying entity" may be embedded into a claim.

I suppose that an "invocation" has the usual meaning -- transmitting a message to a machine that is capable of performing whatever spell (a/k/a operation) is invoked.

Capability security in Op256, or something similar to it, is provided by requiring some operations to be signed by the invoking party, along with requiring the machine receiving the invocation to check for an assertion that the invoking party has proper permission to apply the operation, which is done by deriving a mote (a 256-bit opaque value, either hash or key) from the provided key used to sign the message and the invoked operator, and chasing assertions "upwards" authority-wise to verify that the root keys for the operation allow (through an arbitrarily long chain of signed claims) the signing entity to invoke the operation. This approach, including the detail of currying arguments to create per-invocation operators, does require "delegate to yourself exactly the one resource you want to use" in a general way, as "resource" becomes, here, a type of argument.

So about "issues with multi-resource delegation." In Op256, a "multi-resource delegation" would have to get expanded into a separate assertion for each resource. Otherwise, the security checks would become more complicated. But maybe not unreasonably so.

Given an invocation discipline like

1. create a new key for the invocation (or the session -- anyway it's ephemeral)
2. draft the invocation
3. use the authority under your key to grant the new key authority to invoke the invocation
4. invoke the invocation

a "multi-resource delegation" would be part of "the authority under your key" and could simplify things. The upward chasing security check mechanism would have to know about multi-resource (a/k/a bundled) delegations. The delegation to the limited key would cite the bundle as authority.

"a capability must designate a specific object" presumes a model of "capability" that involves some presumptions which might not be necessary. Op256 signed operations are available at all grain sizes. "Capability" may imply a grain size, such as "this operator on this object" with or without "invoked by this entity."

I think Op256 is a capability system rather than an access-control-list system because the empowering assertions are carried in a DHT as signed mutable data, rather than requiring a centralized access control oracle. For normal ephemeral permission for a particular invocation, publishing to a DHT is not necessary, the signed assertion is transmitted as part of the invocation, transmitting both the step 3 and step 4 messages together,

So the two concepts -- bundled permissions, and fine-grained invocation -- are perfectly compatible, in my amateur analysis of the question.

David "tipjar" Nicol

--

"The profit motive is often in conflict with the aims of art." -- Ursula K. Le Guin

[Alan Karp]

What exactly is an "invocation?" 

In any capability system there are delegations and invocations.  In an object reference as capability system, a.foo(b) is an invocation, and b is a delegation because object a will be able to use object b.  In a certificate capability system, a delegation is a certificate granting one or more permissions to one or more resources.  In such a system, an invocation is a message sent to a resource consisting of a certificate designating the resource and method and containing a delegation certificate as evidence that the request is authorized.  It can also contain delegation certificates for resource arguments.  The authorizing delegation is issued to a public key, and the invocation must be signed by the corresponding secret key.

Some certificate capability systems allow a delegation to be for multiple resources.  Those systems have you designate which of the delegated resources you're invoking with a string.  In UCAN, for example, the string can be the CID of the authorizing delegation certificate or one that matches a resource designation in the authorizing certificate.

So about "issues with multi-resource delegation." In Op256, a "multi-resource delegation" would have to get expanded into a separate assertion for each resource. Otherwise, the security checks would become more complicated. But maybe not unreasonably so.

That's what I've been arguing for, but, as my original note said, I've been having trouble justifying the additional work to create the new certificate and validate the longer delegation chain.  I came up with a justification at the end of the last friam.  Using a muilti-resource delegation in an invocation tells the invoked resource what additional permissions were delegated to you.

--------------
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/CAFwScO_5qJtcQsrSgdWMgSHWQ%2BcffEE5B%2B6wLK0uVEmwPUOxwA%40mail.gmail.com.

[Matt Rice]

On Sat, Jun 20, 2026 at 4:58 PM Alan Karp <alan...@gmail.com> wrote:
>
> What exactly is an "invocation?"
>
>
> In any capability system there are delegations and invocations. In an object reference as capability system, a.foo(b) is an invocation, and b is a delegation because object a will be able to use object b. In a certificate capability system, a delegation is a certificate granting one or more permissions to one or more resources. In such a system, an invocation is a message sent to a resource consisting of a certificate designating the resource and method and containing a delegation certificate as evidence that the request is authorized. It can also contain delegation certificates for resource arguments. The authorizing delegation is issued to a public key, and the invocation must be signed by the corresponding secret key.
>
> Some certificate capability systems allow a delegation to be for multiple resources. Those systems have you designate which of the delegated resources you're invoking with a string. In UCAN, for example, the string can be the CID of the authorizing delegation certificate or one that matches a resource designation in the authorizing certificate.
>
> So about "issues with multi-resource delegation." In Op256, a "multi-resource delegation" would have to get expanded into a separate assertion for each resource. Otherwise, the security checks would become more complicated. But maybe not unreasonably so.
>
>
> That's what I've been arguing for, but, as my original note said, I've been having trouble justifying the additional work to create the new certificate and validate the longer delegation chain. I came up with a justification at the end of the last friam. Using a muilti-resource delegation in an invocation tells the invoked resource what additional permissions were delegated to you.
>

I had mentioned this, and I thought that you had said that this would
happen anyways when redelegating the single resource, because the new
certificate forms a chain which relies upon the original delegation.
Perhaps we were talking past one another.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0hzG%2BBhEjPnQoppS3tghX-iXEiZi%2BN88Z3Tr3jEGd_7w%40mail.gmail.com.

[Alan Karp]

I had mentioned this, and I thought that you had said that this would

happen anyways when redelegating the single resource, because the new
certificate forms a chain which relies upon the original delegation.
Perhaps we were talking past one another.

You're absolutely right.  Now I have no justification for my advice.

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

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

[David Nicol]

 In an object reference as capability system, a.foo(b) is an invocation, and b is a delegation because object a will be able to use object b.

It seems that an object-reference-as-capability system is already implicitly bundling permissions, as it appears that a capability to object-a grants permission to invoke all of object-a's methods. 

[Matt Rice]

On Sat, Jun 20, 2026 at 11:37 PM David Nicol <david...@gmail.com> wrote:
>
>
>>> In an object reference as capability system, a.foo(b) is an invocation, and b is a delegation because object a will be able to use object b.
>
>
> It seems that an object-reference-as-capability system is already implicitly bundling permissions, as it appears that a capability to object-a grants permission to invoke all of object-a's methods.
>

In theory yes, However bundling a bunch of named resources like a
directory is bundling an organizational unit, while a capability is
typically a functional unit composed of the transitive authority
necessary to perform the function the object intends to convey. An
organization unit containing more than one object exceeds the
necessary authority basically by definition.

[Alan Karp]

On Sat, Jun 20, 2026 at 11:37 PM David Nicol <david...@gmail.com> wrote:

 In an object reference as capability system, a.foo(b) is an invocation, and b is a delegation because object a will be able to use object b.

It seems that an object-reference-as-capability system is already implicitly bundling permissions, as it appears that a capability to object-a grants permission to invoke all of object-a's methods. 

That's a difference from a certificate capability that can delegate a subset of methods.  You have to plan ahead to do that with ocaps by creating a caretaker.

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