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.

[Alan Karp]

On Tue, Jun 16, 2026 at 12:32 PM Raoul Duke <rao...@gmail.com> wrote:

Doesn't that assume there's a good, widespread definition of object?

You need someplace to send the request and some way to say what we want to operate on.  That's defined by the API and is the "object" in this case.

 

I mean a directory ocap is also about however many things are in the directory?

A directory is an "object" with a set of methods, such as "list contents" that doesn't necessarily give you access to its contents.

Or, what if i want a single collaborative document file but want only certain people to be able to edit different subsets?

That depends on what your API supports.  If it supports different permissions for different subsets, you can create the relevant capabilities.  If it doesn't, you're stuck.

 

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.

 

I don't think these issues are relevant to the question I asked.

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

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

One last thing that bothers me isn't the "aside from an extra line in
the spec telling you how to designate the specific resource",
it's that the unit of evidence required to perform and invocation, and
the unit of sharing required to transfer the ability to perform an
invocation are
no longer in 1:1 correspondence. I feel like this correspondence is
what makes capabilties unsurprising. It feels like the authority
invoked is a subset of the designation.
Since it still refers to a single resource it doesn't create a
confused deputy. But since the designation generally refers to the
certificate as a whole, an entirely different
designation is required to share the subset specified by any specific
resource invoked. Worryingly sharing the certificate would seem to
share all the resources.
This feels to me somewhat like a variation of posix capabilities,
where you have to explicitly drop privileges rather than a least
authority system..

Anyhow, sorry I should shut up...

[Alan Karp]

Please don't shut up.  You have nicely described my problem.  

A certificate granting permission to multiple resources doesn't "feel" like a capability, 

but it can be used as if it was one by specifying a designation in the invocation.  That 

feels  like separating designation from authorization, but I can't convince myself that it is.

I don't think it's like POSIX.  The invocation isn't dropping any privileges.  It's just saying,

"This is the one I want to use."

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

[Raoul Duke]

The reason to not separate is that it simplifies security logic for humans, yeah? If the cert + designation cannot access things outside the legal overlapping venn diagram ie designation can only be of a subset of what the cert lists, I do not see a problem. It is in effect an attenuating capability minter, no?

[Alan Karp]

On Thu, Jun 18, 2026 at 9:20 AM Raoul Duke <rao...@gmail.com> wrote:

The reason to not separate is that it simplifies security logic for humans, yeah? If the cert + designation cannot access things outside the legal overlapping venn diagram ie designation can only be of a subset of what the cert lists, I do not see a problem. It is in effect an attenuating capability minter, no?

That's exactly my problem.  I've been saying that you must not use the compound delegation certificate in the invocation, because I believe you should designate the resource with a capability to it.  You've just explained why it's not a problem if you do.  I have tried and failed to come up with a convincing argument against your conclusion.  Is there one?

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

[Matt Rice]

Yeah, I don't see any real problems on the invocation side, it's the
designation side,
particularly when it comes to transferring/delegating to others the
authority in the cert.

Particularly I think there are two potential points of confusion about
the designation:

1. Whether the designation is the certificate as a whole, including
all resources.
2. Whether the designation is the fractional portion of a certificate
designating a resource.

When both are designations we can accidentally share multiple when we
intend to share a single resource.
I feel like the problems with this are not going to appear on the
invocation side of things, but elsewhere when we
send resources from person to person.

[Alan Karp]

On Thu, Jun 18, 2026 at 9:30 AM Matt Rice <rat...@gmail.com> wrote:

Yeah, I don't see any real problems on the invocation side, it's the
designation side,

Yes

particularly when it comes to transferring/delegating to others the
authority in the cert.

For now, I'm only concerned with invocation.

Particularly I think there are two potential points of confusion about
the designation:

1. Whether the designation is the certificate as a whole, including
all resources.

Designating with just the certificate fits the capability model, but you can't do that

if the certificate specifies multiple resources.

2. Whether the designation is the fractional portion of a certificate
designating a resource.

Which you designate how?

When both are designations we can accidentally share multiple when we
intend to share a single resource.

I'm not worried about such bugs for the present discussion.

I feel like the problems with this are not going to appear on the
invocation side of things, but elsewhere when we
send resources from person to person.

Again, not the issue I'm concerned with.

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

[Matt Rice]

On Thu, Jun 18, 2026 at 9:41 AM Alan Karp <alan...@gmail.com> wrote:
>
> On Thu, Jun 18, 2026 at 9:30 AM Matt Rice <rat...@gmail.com> wrote:
>>
>>
>> Yeah, I don't see any real problems on the invocation side, it's the
>> designation side,
>
>
> Yes
>
>> particularly when it comes to transferring/delegating to others the
>> authority in the cert.
>
>
> For now, I'm only concerned with invocation.
>>
>>
>> Particularly I think there are two potential points of confusion about
>> the designation:
>>
>> 1. Whether the designation is the certificate as a whole, including
>> all resources.
>
>
> Designating with just the certificate fits the capability model, but you can't do that
> if the certificate specifies multiple resources.
>
>> 2. Whether the designation is the fractional portion of a certificate
>> designating a resource.
>
>
> Which you designate how?

Let me try and use less ambiguous terms, and maybe try and break down
how (I feel) this relates to the original
"do not separate designation from authority" related problems.

In the original problem we had a designation which referred to
something like a filesystem path, or an OS level designation,
that produces a file descriptor. With the original do not separate
designation from authority being a single designation which referenced
multiple authorities.
A directory "foo/" was one such designation.

If we take this same definition of designation, then the designation
is a certificate file
(i'm confident saying that on both posix like systems and capability
OS's, a certificate capability would return some file descriptor for
the contents of the certificate)
In these systems the granularity with which invocations wield
authority is designation.

As far as I understand it Invocation in this certificate system wields
authority at a finer granularity than designation, which we could call
resource designation.

In the old systems we had a problem of 1:designation to many:authority mapping.
Here we have a problem of 1-designation to many:resource-designation mapping.
With a 1: resource-designation to 1: authority mapping

Since invocation takes a finer grained form of designation which still
has a 1:1 mapping to authority we don't get the original problems.
I expect other designation related problems wherever designations are
used which are not restricted to resource-designations.
unless those are unusable, in which case why should they exist.

>>
>> When both are designations we can accidentally share multiple when we
>> intend to share a single resource.
>
>
> I'm not worried about such bugs for the present discussion.
>
>> I feel like the problems with this are not going to appear on the
>> invocation side of things, but elsewhere when we
>> send resources from person to person.
>
>
> Again, not the issue I'm concerned with.
>
> --------------
> 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/CANpA1Z2okOKs-YqkbZZvFQFs9B83_53i75HsLpVfO9mzovX7Fw%40mail.gmail.com.

[Alan Karp]

On Thu, Jun 18, 2026 at 12:02 PM Matt Rice <rat...@gmail.com> wrote:

In the original problem we had a designation which referred to
something like a filesystem path, or an OS level designation,
that produces a file descriptor. With the original do not separate
designation from authority being a single designation which referenced
multiple authorities.
A directory "foo/" was one such designation.

I disagree.  In this case "foo" refers to a single object, the directory with

methods such as "list contents" that don't apply to the individual elements

inside the directory.  In the systems I know, you can't access something in 

the directory with the  directory file handle.  You have to get a separate file

handle for each entry you want to use.  Maybe that's where my bias against 

using a compound delegation certificate in an invocation comes from.

If we take this same definition of designation, then the designation
is a certificate file
(i'm confident saying that on both posix like systems and capability
OS's, a certificate capability would return some file descriptor for
the contents of the certificate)

Sometimes.  It's true for UCAN, which lets you point to the certificate; 

false for zcap, where you include the authorizing certificate in the 

invocation certificate.  

 

In these systems the granularity with which invocations wield
authority is designation. 

The key point is what you mean by designation.  In an object-reference-

as-capability system (ocaps), you designate via the object reference.  If

you model a certificate capability system that way, you designate it with

a certificate granting permission to a single resource.  Using a compound

certificate with a separate way to denote which resource you're invoking

is what I've been arguing against.

As far as I understand it Invocation in this certificate system wields
authority at a finer granularity than designation, which we could call
resource designation.

Yes.  I'm concerned that distinction might confuse developers.

In the old systems we had a problem of 1:designation to many:authority mapping.
Here we have a problem of 1-designation to many:resource-designation mapping.
With a 1: resource-designation to 1: authority mapping

Is this referring back to your directory "foo" example?

Since invocation takes a finer grained form of designation which still
has a 1:1 mapping to authority we don't get the original problems.

And that's my conundrum.  I want to argue for single resource certificates only in

invocations, but I can't make a compelling argument.  All I have is that it better 

corresponds to the ocap model, which doesn't convince even me.

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

[Raoul Duke]

Personally i think the "obviously no bugs" design is always better, and a valid argument. 

[Matt Rice]

On Thu, Jun 18, 2026 at 1:41 PM Alan Karp <alan...@gmail.com> wrote:
>
> On Thu, Jun 18, 2026 at 12:02 PM Matt Rice <rat...@gmail.com> wrote:
>>
>>
>> In the original problem we had a designation which referred to
>> something like a filesystem path, or an OS level designation,
>> that produces a file descriptor. With the original do not separate
>> designation from authority being a single designation which referenced
>> multiple authorities.
>> A directory "foo/" was one such designation.
>
>
> I disagree. In this case "foo" refers to a single object, the directory with
> methods such as "list contents" that don't apply to the individual elements
> inside the directory.
>
> In the systems I know, you can't access something in
> the directory with the directory file handle. You have to get a separate file
> handle for each entry you want to use. Maybe that's where my bias against
> using a compound delegation certificate in an invocation comes from.

My example here is referring to the original systems which separated
designation from
authority. Having the orignal 1:designation many:authority problem.
Not any actual capability system without confused deputy problems.

It was just my attempt at an explanation for why "do not separate
designation from authority",
turned into a confused deputy problem for these old systems, and why
by all appearances
this new system has separated designation from authority but doesn't
appear to suffer the
*exact same* set of problems.

I wasn't trying to say anything about systems which function properly.

>>
>> If we take this same definition of designation, then the designation
>> is a certificate file
>> (i'm confident saying that on both posix like systems and capability
>> OS's, a certificate capability would return some file descriptor for
>> the contents of the certificate)
>
>
> Sometimes. It's true for UCAN, which lets you point to the certificate;
> false for zcap, where you include the authorizing certificate in the
> invocation certificate.
>
>>
>> In these systems the granularity with which invocations wield
>> authority is designation.
>
> The key point is what you mean by designation. In an object-reference-
> as-capability system (ocaps), you designate via the object reference. If
> you model a certificate capability system that way, you designate it with
> a certificate granting permission to a single resource. Using a compound
> certificate with a separate way to denote which resource you're invoking
> is what I've been arguing against.
>
>> As far as I understand it Invocation in this certificate system wields
>> authority at a finer granularity than designation, which we could call
>> resource designation.
>
>
> Yes. I'm concerned that distinction might confuse developers.

Right I'm certain it'll confuse developers and users alike,
I just don't think it's going to confuse applications being invoked
via a system call.

>>
>>
>> In the old systems we had a problem of 1:designation to many:authority mapping.
>> Here we have a problem of 1-designation to many:resource-designation mapping.
>> With a 1: resource-designation to 1: authority mapping
>
>
> Is this referring back to your directory "foo" example?

Yeah, I was trying to contrast the confused deputy suffering example
and the certificate one.
For confused deputy sufferers a directory has:
1: designation many:authority

For multi-resource certificate sufferers:
1:certificate many:resource-designation
1:resource-designation 1:authority mapping

Capability system:
1:designation 1:authority

So if invocation really requires a resource-designation, the mapping
is still 1 to 1.
I wouldn't expect there to be any problems, since it seems to have the
same 1 to 1 mapping as the capability model.

>> Since invocation takes a finer grained form of designation which still
>> has a 1:1 mapping to authority we don't get the original problems.
>
>
> And that's my conundrum. I want to argue for single resource certificates only in
> invocations, but I can't make a compelling argument. All I have is that it better
> corresponds to the ocap model, which doesn't convince even me.

I just don't think you'll find it if you limit yourself to invocations.
I would expect to find problems in grant problems which you don't care
about, but let my skepticism be noted for the record.

[Alan Karp]

I just don't think you'll find it if you limit yourself to invocations.
I would expect to find problems in grant problems which you don't care
about, but let my skepticism be noted for the record.

I care about grant problems, too, but right now my concern is if I've been

giving bad advice about invocation.

--------------
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/CACTLOFp-aoii4eUohOrFuBDhZ0RZ%3DeJg8h1sWxnVGN6ZAUpQdQ%40mail.gmail.com.

[Matt Rice]

On Thu, Jun 18, 2026 at 2:36 PM Alan Karp <alan...@gmail.com> wrote:
>
> I just don't think you'll find it if you limit yourself to invocations.
> I would expect to find problems in grant problems which you don't care
> about, but let my skepticism be noted for the record.
>
>
> I care about grant problems, too, but right now my concern is if I've been
> giving bad advice about invocation.
>

I don't get the impression that you've been giving bad advice, this feels to me
like one of those differences between the letter of the law, and the
spirit of the law
for which they've managed to find some weird loophole.

[Alan Karp]

I don't get the impression that you've been giving bad advice, this feels to me
like one of those differences between the letter of the law, and the
spirit of the law
for which they've managed to find some weird loophole.

There is a cost to what I'm recommending - creating and signing an additional 

certificate and an extra delegation hop to verity.  That's not a trivial percentage

increase in work for short delegation chains.

--------------
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/CACTLOFrmXsRDsePjYJJLDdfAYf_OKxEQ%3D2QX4ZO4Sje-Ly9JcQ%40mail.gmail.com.

[Kevin Reid]

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’ve only skimmed this thread, so I may be reiterating ideas already said, but I think that the reason you are having trouble articulating this is that what constitutes a “resource” or “object” is up to the choice of the owner of the resources. There may even be different views of the same stuff that slice them up into different designations. For example, if I have a relational database which I am providing capability access to, I could give access to:

• “this one cell”, e.g. for an external blob storage or data processor to fill in the ID/address/capability when it finishes storing/processing.
• "this one row", e.g. one user's piece of data
• "this one query", e.g. for a dashboard

These are all legitimately understandable as objects in the ocap sense, and yet they overlap. They are facets of the database. Which facets are able to exist is part of the design and use of the database software.

The difference between “designation of one object, which takes instructions about what part of itself to act on” and “designation of N objects in one certificate” is in what is efficient, what is possible to do locally/offline, etc. — not a fundamental truth that can be written down formally and independently of the application domain. You can formalize it in a specification for a protocol for access to a specific kind of resource/object, but not for a general capability communication protocol.

[Alan Karp]

You're not reiterating, and I agree with what you said.  It's just not the issue that has me puzzled.

Consider the simplest possible case.  I delegate to you in a single certificate permission to read files foo.txt and bar.txt.  How do you invoke read foo.txt?

1. You can delegate to yourself a new certificate granting read permission on just foo.txt.  Now your invocation can use the certificate as the designation.
2. The other approach is to use the certificate you got from me in your invocation and designate that the request is for foo.txt some other way, such as a string in the invocation.

Most certificate capability systems allow #2.  I have been recommending #1 because it's what you do with object references, but I'm having trouble justifying why it's better.

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

[Kevin Reid]

On Thu, Jun 18, 2026 at 7:49 PM Alan Karp <alan...@gmail.com> wrote:

You're not reiterating, and I agree with what you said.  It's just not the issue that has me puzzled.

Consider the simplest possible case.  I delegate to you in a single certificate permission to read files foo.txt and bar.txt.  How do you invoke read foo.txt?

As I see it, in order for this certificate to be understood as a capability, it must provide some specific interface to its user — some specification of how the permission should be exercised, of what message should be sent to exercise it. That interface could be “set of named files”, in which case all operations on it naturally must either specify a name, or it could be something else (say, "the concatenation of these files"), in which case the existence of the string "foo.txt" in the certificate is either an implementation detail that should be ignored by the user of the certificate, or a bug in the design that should be fixed.

1. You can delegate to yourself a new certificate granting read permission on just foo.txt.  Now your invocation can use the certificate as the designation.
2. The other approach is to use the certificate you got from me in your invocation and designate that the request is for foo.txt some other way, such as a string in the invocation.

Most certificate capability systems allow #2.  I have been recommending #1 because it's what you do with object references, but I'm having trouble justifying why it's better.

Whether these choices even make sense to compare depends on what the interface (as I define it above) is.

But to be specific, if we imagine that these are capabilities into a filesystem, then it is clearly a reasonable option to allow both, just as local filesystems allow you to express both "cd foo/bar; cat baz" (#1ish) and "cat foo/bar/baz" (#2ish). The design mistake in that case is not to do #2, but to not allow #1, because it makes POLA harder — and modularity/loose-coupling harder, too. You can argue for doing #1 only as a protection against forgetting to support #1, but I don’t think that is good practice. (Perhaps I could be convinced otherwise. I don’t really get certificate capabilities. Concrete API examples would help.)

[Matt Rice]

Something I had briefly mentioned earlier but dropped pretty quickly
was I said that the choice between #1 and #2 reminds me more of posix
capabilities than object capabilities.
Let me try and explain that by contrasting POLA and least privilege,
in least privilege you have some amount of privilege and the impetus
to avoid wielding all of it is on the user to drop/shed various
privileges.
While in least authority the impetus is on the user to compose
authorities foo.txt and bar.txt before they can be used together.

I feel like #1 is trying to synthesize POLA from a list privilege
system by recursively subdividing privileges into their least
authority during invocation. That Kevin mentions this is similar to
capabilities to databases is interesting though. I still don't like
that the system makes you choose between #1 and #2 rather than just
being POLA all the way down in the first place.

[Alan Karp]

On Fri, Jun 19, 2026 at 8:19 AM Matt Rice <rat...@gmail.com> wrote:

Something I had briefly mentioned earlier but dropped pretty quickly
was I said that the choice between #1 and #2 reminds me more of posix
capabilities than object capabilities.

There's a bit of that flavor, but you're not saying, "I don't want to use bar.txt."

You're saying, "I do want to use foo.txt."

Let me try and explain that by contrasting POLA and least privilege,
in least privilege you have some amount of privilege and the impetus
to avoid wielding all of it is on the user to drop/shed various
privileges.
While in least authority the impetus is on the user to compose
authorities foo.txt and bar.txt before they can be used together.

The problem isn't that you are using them together.  It's that you have a 

single certificate granting permission to both, but you only want to use

one of them in the invocation.

I feel like #1 is trying to synthesize POLA from a list privilege
system by recursively subdividing privileges into their least
authority during invocation. That Kevin mentions this is similar to
capabilities to databases is interesting though. I still don't like
that the system makes you choose between #1 and #2 rather than just
being POLA all the way down in the first place.

I don't see either as violating POLA.  You may need to use bar.txt in a

subsequent invocation.  Note, too, that the invocation doesn't grant any

privileges unless delegations are passed as additional parameters, 

something not done in my simple example.

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

[Alan Karp]

I'm going to reply to Kevin's note later so I can gather examples from various specs.

--------------
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/CANkSj9VkUcv1ZVF1j3CLnmhKu_vHANVfwGuO%2BOGFeB1ngS%2BukA%40mail.gmail.com.

[Matt Rice]

On Fri, Jun 19, 2026 at 9:47 AM Alan Karp <alan...@gmail.com> wrote:
>
> On Fri, Jun 19, 2026 at 8:19 AM Matt Rice <rat...@gmail.com> wrote:
>>
>>
>> Something I had briefly mentioned earlier but dropped pretty quickly
>> was I said that the choice between #1 and #2 reminds me more of posix
>> capabilities than object capabilities.
>
>
> There's a bit of that flavor, but you're not saying, "I don't want to use bar.txt."
> You're saying, "I do want to use foo.txt."

If it's never possible to use the combined "foo.txt" + "bar.txt"
authority and you
must always explicitly specify "I do want to use foo.txt", why does the combined
certificate exist? If you always have to specify "I do want to use
foo.txt" you might
as well just use separate certificates for each resource in the first place.

It just feels like the system is ripe for misuse and we're trying to
hoist principles upon one aspect of it.

>> Let me try and explain that by contrasting POLA and least privilege,
>> in least privilege you have some amount of privilege and the impetus
>> to avoid wielding all of it is on the user to drop/shed various
>> privileges.
>> While in least authority the impetus is on the user to compose
>> authorities foo.txt and bar.txt before they can be used together.
>
>
> The problem isn't that you are using them together. It's that you have a
> single certificate granting permission to both, but you only want to use
> one of them in the invocation.
>>
>>
>> I feel like #1 is trying to synthesize POLA from a list privilege
>> system by recursively subdividing privileges into their least
>> authority during invocation. That Kevin mentions this is similar to
>> capabilities to databases is interesting though. I still don't like
>> that the system makes you choose between #1 and #2 rather than just
>> being POLA all the way down in the first place.
>
>
> I don't see either as violating POLA. You may need to use bar.txt in a
> subsequent invocation. Note, too, that the invocation doesn't grant any
> privileges unless delegations are passed as additional parameters,
> something not done in my simple example.
>
> --------------
> 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/CANpA1Z21%3DCc%2BE5C22JUf9FTJ4DFEKbXzfa_Lc12%2BbvtuQSNa5Q%40mail.gmail.com.

[Matt Rice]

On Fri, Jun 19, 2026 at 10:00 AM Matt Rice <rat...@gmail.com> wrote:
>
> On Fri, Jun 19, 2026 at 9:47 AM Alan Karp <alan...@gmail.com> wrote:
> >
> > On Fri, Jun 19, 2026 at 8:19 AM Matt Rice <rat...@gmail.com> wrote:
> >>
> >>
> >> Something I had briefly mentioned earlier but dropped pretty quickly
> >> was I said that the choice between #1 and #2 reminds me more of posix
> >> capabilities than object capabilities.
> >
> >
> > There's a bit of that flavor, but you're not saying, "I don't want to use bar.txt."
> > You're saying, "I do want to use foo.txt."
>
> If it's never possible to use the combined "foo.txt" + "bar.txt"
> authority and you
> must always explicitly specify "I do want to use foo.txt", why does the combined
> certificate exist? If you always have to specify "I do want to use
> foo.txt" you might
> as well just use separate certificates for each resource in the first place.
>
> It just feels like the system is ripe for misuse and we're trying to
> hoist principles upon one aspect of it.

I should really try and practice more constructive criticism.
Previously you had said that signing each certificate individually
comes at a cost.

What I feel like I should say is that I expect neither of us would
have any problem what with the system
if they approached it in a bottom up fashion, where each certificate
designates a single resource,
and to combine resources you concatenate certificates together into a
single file.

It could be obvious to observe that 1 certificate == 1 capability.
Just doing string concatenation of certificate files
may not assuage the cost problem you mentioned previously. The way I
would approach it is to instead
try and show that the multiple resource certificates are equivalent to
a bunch of single resource certificates concatenated together.

With this top-down approach it could be a capability system within it,
but it's hard to perceive and it comes across as inventing new
ways to perform classical mistakes.

[Alan Karp]

If it's never possible to use the combined "foo.txt" + "bar.txt"

authority and you
must always explicitly specify "I do want to use foo.txt", why does the combined
certificate exist?

Exactly right.  The question is how you say you want to use foo.txt.  With a certificate that

grants permission to just foo.txt, or by some designation in the invocation with the certificate

authorizing access to both foo.txt and bar.txt as evidence that the invocation is authorized.

If you always have to specify "I do want to use
foo.txt" you might
as well just use separate certificates for each resource in the first place.

It's a convenience and an expressiveness issue.  It's convenient to create a single delegation 

certificate for multiple resources.  It's more expressive because you can delegate *.mp3,

which lets you delegate access to resources that don't exist at the time you create the

certificate.

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

To view this discussion visit https://groups.google.com/d/msgid/friam/CACTLOFoLadUwawEOh_8cS5UK4agfTxYH6iyTQTLRE2bhCV4-fg%40mail.gmail.com.

[Alan Karp]

What I feel like I should say is that I expect neither of us would

have any problem what with the system
if they approached it in a bottom up fashion, where each certificate
designates a single resource,
and to combine resources you concatenate certificates together into a
single file.

In order to be used individually, each certificate in the file needs to be signed.

That's an extra cost that grows with the number of resources you're delegating.

Your suggestion also doesn't cover the case of delegating *.mp3.

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

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

[Matt Rice]

On Fri, Jun 19, 2026 at 2:45 PM Alan Karp <alan...@gmail.com> wrote:
>
>
> If it's never possible to use the combined "foo.txt" + "bar.txt"
>
> authority and you
> must always explicitly specify "I do want to use foo.txt", why does the combined
> certificate exist?
>
> Exactly right. The question is how you say you want to use foo.txt. With a certificate that
> grants permission to just foo.txt, or by some designation in the invocation with the certificate
> authorizing access to both foo.txt and bar.txt as evidence that the invocation is authorized.
>
>
> If you always have to specify "I do want to use
> foo.txt" you might
> as well just use separate certificates for each resource in the first place.
>
> It's a convenience and an expressiveness issue. It's convenient to create a single delegation
> certificate for multiple resources. It's more expressive because you can delegate *.mp3,
> which lets you delegate access to resources that don't exist at the time you create the
> certificate.

Then this is way worse than I thought, because it's basically acting
exactly like a mutable directory.
I was under the impression that the certificate granted a static set
of resources known
at the time the certificate was signed.

> To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z1-p2NmdgKfK0e0-AAEiB6pweyh9qmjiMvnjT552WZPaw%40mail.gmail.com.

[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

[Alan Karp]

Then this is way worse than I thought, because it's basically acting

exactly like a mutable directory.
I was under the impression that the certificate granted a static set
of resources known
at the time the certificate was signed.

The feature is potentially dangerous, but it's also useful.  For example, it's nice to be able

to delegate all the music on your server to a device that doesn't have space to hold it all.

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

To view this discussion visit https://groups.google.com/d/msgid/friam/CACTLOFoHM4rFYLviQuagL%2BMCzYUeZTY0eUnBqD2qNRO7hA7ngQ%40mail.gmail.com.

[Matt Rice]

On Fri, Jun 19, 2026 at 3:33 PM Alan Karp <alan...@gmail.com> wrote:
>
> Then this is way worse than I thought, because it's basically acting
> exactly like a mutable directory.
> I was under the impression that the certificate granted a static set
> of resources known
> at the time the certificate was signed.
>
>
> The feature is potentially dangerous, but it's also useful. For example, it's nice to be able
> to delegate all the music on your server to a device that doesn't have space to hold it all.
>

Convenience is not really an excuse for including dangerous features,
It would be convenient if the dash boards on cars came with a built-in
receipt spike
for organizing gas receipts too.

I'm pretty much going to cease participating in the thread,
as basically convinced that I won't be convinced that this has anything
more than a passing resemblance to a capability system, security
is a property only obtained by omission.

> To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z055AB9Txt5hFz3j9cZkMnm4mtqV5x3RRgTTwb1hCPFRA%40mail.gmail.com.

[Alan Karp]

Good idea or not, there is more than one certificate capability system out there that has the (mis?)feature.

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

To view this discussion visit https://groups.google.com/d/msgid/friam/CACTLOFq6-dqPVr%3D8OkR-%3DShVL7pA6byuHdV6r5iPFZCcv9Zdsw%40mail.gmail.com.