Designating the resource with certificate capabilities

[Alan Karp]

I'm back again with this topic.  If you recall, in my last message on this topic I concluded that I'm an idiot.  That may be true, but I'm a stubborn one.

To refresh your memory, some certificate capability systems designate resources with the delegation certificate.  Others designate the resource with an identifier of the certificate, such as the hash of its contents.  I have no problem with them.

In other systems, you designate a resource by a string that denotes the name of the resource specified in the delegation certificate.  Most systems avoid name collisions by using URIs or something similar.  My intuition is that this option can lead to confusion, but I hadn't come up with an example until now.

Imagine that Alice delegates to Bob query permission on some resource, say example.com/foo and that Carol delegates update permission to the same resource.  Bob now wants to invoke Dave's service, providing the query permission for the first argument and the update permission for the second.  He has no way to express his intent.

It's a corner case to be sure, but is it convincing enough?

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

[Matt Rice]

Rather than answer your question, Let me just repeat back what I think
you are saying,
Since we can have multiple certificates designating separate
authorities to the same resource, and those authorities are designated
by a single resource name,
If we classify these as injective/surjective/bijective (as we
discussed while discussing the proposed proof of your rule for
avoiding confused deputy problems)
then we see this is surjective, has multiple arrows pointing from
authority to designation.

Where the arrows bijective function can be traversed going either
direction without ambiguity,
the same is not so for this particular surjective configuration...
Each authority points to a single
designation, but the reverse mapping has a designation which points to
multiple authorities.

If the whole point of designation is to designate authority
unambiguously, this feels like it is doing a bad job at that.

[Pierre Thierry]

Le 08/08/2026 à 00:30, Alan Karp a écrit :

Imagine that Alice delegates to Bob query permission on some resource, say example.com/foo and that Carol delegates update permission to the same resource.  Bob now wants to invoke Dave's service, providing the query permission for the first argument and the update permission for the second.  He has no way to express his intent.

I'm not sure I understand what the issue is supposed to be here. Dave's service has to have been designed to use its first argument capability to query something, and as a result, use its second argument capability to update something. What intent from Bob should change what?

Curiously,

Pierre Thierry
--

pie...@nothos.net
0xD9D50D8A

[Matt Rice]

I believe the issue is that Bob's designation to both Alice and
Carol's permissions is "example.com/foo"
So short of Bob proxying Alice and Carol somehow via
example.com/bob/alice/foo and example.com/bob/carol/foo to give dave
an unambiguous designation.

Interestingly in this example there is a circular chain of blame, and
pretty much everyone has a reasonable excuse why they are not the
problem.
Alice and Carol could be oblivious to the reuse of the designation
identifier. Bob and Dave are kind of both working with what they were
given:
"You gave me two cans of chicken noodle soup, and asked for chicken
noodle soup, what else did you expect?"

[Alan Karp]

On Sat, Aug 8, 2026 at 2:46 PM Pierre Thierry <pie...@nothos.net> wrote:

I'm not sure I understand what the issue is supposed to be here. Dave's service has to have been designed to use its first argument capability to query something, and as a result, use its second argument capability to update something. What intent from Bob should change what?

Dave's service takes 2 parameters.  It queries the first and updates the second.  How does the system know which capability to use when Bob says example.com/foo for each argument?  If it provides the arguments in the right order, the invocation succeeds.  If it provides them in the wrong order, the invocation fails for lack of permission.  I expect Bob would find that puzzling, since he thinks he provided both permissions.

I don't want to spend too much time on this example as it's clearly not the common case.  I'm just trying to illustrate a danger of using something other than the capability to designate the resource.

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

[Raoul Duke]

aren't arguments usually documented? 

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

[William ML Leslie]

On Sun, 9 Aug 2026 at 11:04, Alan Karp <alan...@gmail.com> wrote:

On Sat, Aug 8, 2026 at 2:46 PM Pierre Thierry <pie...@nothos.net> wrote:

I'm not sure I understand what the issue is supposed to be here. Dave's service has to have been designed to use its first argument capability to query something, and as a result, use its second argument capability to update something. What intent from Bob should change what?

Dave's service takes 2 parameters.  It queries the first and updates the second.  How does the system know which capability to use when Bob says example.com/foo for each argument?  If it provides the arguments in the right order, the invocation succeeds.  If it provides them in the wrong order, the invocation fails for lack of permission.  I expect Bob would find that puzzling, since he thinks he provided both permissions.

I see that Bob is not designating the resource with certificate capabilities, but with a resource name.  Can you do something with the UA to give him a better way to designate his certificates?  Maybe some petnames.

I'm just guessing as to how invocation works in this system, imagining Bob sends two certificates to this service as parameters, maybe I am missing something there.

--

William ML Leslie

->.

[Alan Karp]

On Sat, Aug 8, 2026 at 8:34 PM Raoul Duke <rao...@gmail.com> wrote:

aren't arguments usually documented? 

The API for Dave's service says that the first argument is queried and the second updated.  Bob's invocation is dave.service(example.com/foo, example.com/foo).  Whether that invocation satisfies the API depends on which capability is selected for each argument, but Bob has no way to express what he wants.

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

[Alan Karp]

On Sat, Aug 8, 2026 at 8:53 PM William ML Leslie <william.l...@gmail.com> wrote:

I see that Bob is not designating the resource with certificate capabilities, but with a resource name.  Can you do something with the UA to give him a better way to designate his certificates?  Maybe some petnames.

I am arguing that a certificate capability system that selects capabilities by name is flawed.  This example is the best I've come up with to make that point.  Your suggestion is one of the many possible workarounds.  For example, UCAN allows names, such as example.com/foo, but it also allows you to use the certificate's CID (essentially its hash).

I'm just guessing as to how invocation works in this system, imagining Bob sends two certificates to this service as parameters, maybe I am missing something there.

You're not missing anything.  The invocation includes a certificate for each argument.  The problem arises when Bob designates them by name, and they have the same name.  You need a way to disambiguate them, but these systems don't always provide one.

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

[Matt Rice]

On Sun, Aug 9, 2026 at 11:51 AM Alan Karp <alan...@gmail.com> wrote:
>
> On Sat, Aug 8, 2026 at 8:53 PM William ML Leslie <william.l...@gmail.com> wrote:
>>
>>
>> I see that Bob is not designating the resource with certificate capabilities, but with a resource name. Can you do something with the UA to give him a better way to designate his certificates? Maybe some petnames.
>
>
> I am arguing that a certificate capability system that selects capabilities by name is flawed. This example is the best I've come up with to make that point. Your suggestion is one of the many possible workarounds. For example, UCAN allows names, such as example.com/foo, but it also allows you to use the certificate's CID (essentially its hash).
>>

I feel like it's so flawed that I'm kind of perturbed that we keep
calling it a capability system, it feels to me like a directory system
minus the ambient authority of a globally shared filesystem.

>>
>> I'm just guessing as to how invocation works in this system, imagining Bob sends two certificates to this service as parameters, maybe I am missing something there.
>
>
> You're not missing anything. The invocation includes a certificate for each argument. The problem arises when Bob designates them by name, and they have the same name. You need a way to disambiguate them, but these systems don't always provide one.
>
> --------------
> 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/CANpA1Z2-0pQs_z%2BHi6wsJ%2BQ%3D-BCzdn3J9Ki3FL0b%2B9FEqR3pvA%40mail.gmail.com.

[Alan Karp]

On Sun, Aug 9, 2026 at 11:56 AM Matt Rice <rat...@gmail.com> wrote:

 

I feel like it's so flawed that I'm kind of perturbed that we keep
calling it a capability system, it feels to me like a directory system
minus the ambient authority of a globally shared filesystem.

It's not that bad.  It took me months to come up with an example of where it breaks, and even that is just a corner case.

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

[Matt Rice]

I feel like you were also ignoring a lot of problems where the app
developer has some obvious deficiency, and all the
problems outside the scope of invocation. That there is usually a
simple solution doesn't make it the obvious solution
people would generally reach for unprompted.

Lets ignore all the problems. What other capability systems have
by-name designation of references?

> --------------
> 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/CANpA1Z0OpYoE-xJemRGx-M3NLzLO5eCzdwoBcFpntuKekUCDrg%40mail.gmail.com.

[Alan Karp]

On Sun, Aug 9, 2026 at 1:20 PM Matt Rice <rat...@gmail.com> wrote:

Lets ignore all the problems. What other capability systems have
by-name designation of references?

I don't believe the problem is expressible with object references as capabilities.  You probably could construct an example with opaque tokens. but I've never seen one that does.

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

[Matt Rice]

I don't mean "construct an example", I mean in the base system itself
where capabilities are sent by-name, or lists of capabilities are sent
by-name as a part of normal use of the system.
In my opinion it only weakens the model, and there is no reason to
even consider including it under the umbrella of capability systems.

[Matt Rice]

Sorry, I should be less adamant. I should really ask:
If all I see is it weakening the model, then what reason could there
be for including it?

[Alan Karp]

On Sun, Aug 9, 2026 at 2:07 PM Matt Rice <rat...@gmail.com> wrote:

I don't mean "construct an example", I mean in the base system itself
where capabilities are sent by-name, or lists of capabilities are sent
by-name as a part of normal use of the system.
In my opinion it only weakens the model, and there is no reason to
even consider including it under the umbrella of capability systems.

I mean that I haven't seen an example of such a base system.

My claim is that you shouldn't do that for a certificate system, either, for the reason you state.

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

[Alan Karp]

On Sun, Aug 9, 2026 at 2:23 PM Matt Rice <rat...@gmail.com> wrote:

Sorry, I should be less adamant. I should really ask:
If all I see is it weakening the model, then what reason could there
be for including it?

The people I spoke to didn't think it was a weakness in the model.  I'm hoping this example will convince them that it is.

--------------
Alan Karp\

[Matt Rice]

I hope it does, but to me it feels like there are simpler arguments.
I'll try to convey.
You've already pretty much covered the non-uniqueness of shared names,
My primary objections
have been along different lines, which are not restricted to name sharing.
FWIW, one of the things that allows this to slip through the "Do not
separate designation from authority" is that
we weren't specifying that a designation should be unique. It is kind
of an implicit assumption in most global and local namespaces that
names have some point of reference to which they are bound, and might
as well be meaningless data outside of that bound.

Anyhow, my biggest objection is different and fundamental, systemic
sharing of bundled capabilities is not conducive to a system being a
least authority system.
The number of applications that need shared enumerable lists of
capabilities is vanishingly small, I know of the c-preprocessor with
distributed compilation, and shared playlists.
Both are better suited to treating named blobs as *data* rather than
named capabilities, because sharing randomly accessible named data is
not problematic to least authority.
E.g. the star property somewhat deals with multitudes of capabilities,
and does so by separating data channels from capability channels. The
vanishingly small number of applications
that need that seem better suited to working over data channels IMO.

But once you start normalizing invocation with bundled authorities,
there becomes a tendency for the *invoked* capability to do selection,
rather than the *invoker* which is all kinds of backwards.

[Raoul Duke]

bob expresses what he wants by supplying the arguments in the right positions, based on the documentation? how is it any different than any other api invocation habits?

but yeah 1 capability as both read & write seems like that can confuse things, i guess?

--

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

[Matt Rice]

As far as I understand it (Not saying my understanding is right), bob
specifies both the authorization (which has multiple capabilities he
may not actually want to invoke), and the resource he wants to invoke,
and the problem is when bob specifies multiple authorization lists,
the resource he wants to invoke may be ambiguous between the two.

This relies on a "posix crapability" like model of "least privilege",
where to reduce the authority to some subset bob must reissue a new
certificate which subdivides the authority
before passing it to dave in order avoid giving dave his full
privileges by the certificate.

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

[William ML Leslie]

On Mon, 10 Aug 2026 at 04:51, Alan Karp <alan...@gmail.com> wrote:

On Sat, Aug 8, 2026 at 8:53 PM William ML Leslie <william.l...@gmail.com> wrote:

I see that Bob is not designating the resource with certificate capabilities, but with a resource name.  Can you do something with the UA to give him a better way to designate his certificates?  Maybe some petnames.

I am arguing that a certificate capability system that selects capabilities by name is flawed.  This example is the best I've come up with to make that point.  Your suggestion is one of the many possible workarounds.  For example, UCAN allows names, such as example.com/foo, but it also allows you to use the certificate's CID (essentially its hash).

It's a solid counterexample, easy to understand. +1.

--

William ML Leslie

So if you've thought that javascript cannot be used to write reliable or secure programs, I want to show you this counter example. - MarkM

[Alan Karp]

On Sun, Aug 9, 2026 at 5:59 PM Raoul Duke <rao...@gmail.com> wrote:

bob expresses what he wants by supplying the arguments in the right positions, based on the documentation? how is it any different than any other api invocation habits?

Bob invokes dave.service(example.com/foo, example.com/foo).  There are 3 capability certifications in the invocation.  One authorizes dave.service, and there is one for each of the arguments.  One of them grants query permission to the resource and the other update permission.  The problem is the system knowing which certificate to use for which argument when the same name is used for both.

but yeah 1 capability as both read & write seems like that can confuse things, i guess?

You can have one capability with both permissions, but in this example there are two.

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

[Alan Karp]

On Sun, Aug 9, 2026 at 6:45 PM Matt Rice <rat...@gmail.com> wrote:

 

As far as I understand it (Not saying my understanding is right), bob
specifies both the authorization (which has multiple capabilities he
may not actually want to invoke), and the resource he wants to invoke,
and the problem is when bob specifies multiple authorization lists,
the resource he wants to invoke may be ambiguous between the two.

Correct, except he provides a name for each argument, not an authorization list.  The name

This relies on a "posix crapability" like model of "least privilege",
where to reduce the authority to some subset bob must reissue a new
certificate which subdivides the authority
before passing it to dave in order avoid giving dave his full
privileges by the certificate.

Not in this case.  Dave needs both the permissions that Bob has to the resource, and the permissions are in different certificates.

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

[Matt Rice]

Right, I'm arguing a different thing, that for normal "least
authority" Bob starts from zero authority and adds in each authority
individually.
Certificates would sign each capability individually and bob would
need to pass multiple certificates to pass multiple authorities any
time
he wants to invoke multiple authorities.

In this system when using a certficiate which authorizies multiple
authorities bob must actively take steps to reduce the amount of
authority given through
a certificate by subdividing it.

That is to say, this isn't a critique of your multi-certificate
problem, but a critique of the way even a single-certificate works in
this system.

[Alan Karp]

You've nicely summarized an argument I've had with several groups.  Sometimes I win the argument; sometimes I don't.

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

[Alan Karp]

On Sun, Aug 9, 2026 at 8:01 PM Matt Rice <rat...@gmail.com> wrote:

Right, I'm arguing a different thing, that for normal "least
authority" Bob starts from zero authority and adds in each authority
individually.
Certificates would sign each capability individually and bob would
need to pass multiple certificates to pass multiple authorities any
time
he wants to invoke multiple authorities.

In this system when using a certficiate which authorizies multiple
authorities bob must actively take steps to reduce the amount of
authority given through
a certificate by subdividing it.

That is to say, this isn't a critique of your multi-certificate
problem, but a critique of the way even a single-certificate works in
this system.

There are two issues here, the certificate used for invocation and any used as arguments.  The invocation certificate must be for the specific resource being invoked and for the exact permission.  Any resource arguments must be delegations with the permissions the invoked resource will need.  I've been surprised at how much pushback I get.

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

[Raoul Duke]

how can dave be self respecting if he doesn't publish any docs explaining what the positional arguments do?

or are they not actually positional? in which case they'd be named/tagged, which is also the start of documentation. 

if people write poor apis then yes they are not good?

[Matt Rice]

To me the kicker is that Dave can document it, and Bob can read it,
and use it hundreds of times without issue.
But the one time where Bob's capabilities alias he could encounter the
problem...
This is exactly limited applicability that lead to the original
confused deputy problem description only being a problem with exactly
1
input, which makes it easy to overlook however obvious in hindsight.

> --
> 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/CAJ7XQb6Ly6D_VdaecjeZmFdwEG%2B6e%3DGBov%3DSk5r83F6xA_QGbQ%40mail.gmail.com.