"Permity"

[David Nicol]

"Permission" and "Authority" are very nearly synonymous in the English that I know.

The uses of them computer security jargon requires one to remember:

• Authority: what effects an actor can actually cause.

• Permission: what effects a controlling policy says the actor is allowed to cause.

This seems arbitrary, and is, except the choice was made long ago, and appears in the name of the core principle: least authority. So that's the mnemonic.

On the way to that important (and obvious, in retrospect) mnemonic, I toyed with the idea of combining the two English words into a portmanteau, "permority" which I later elided to get "permity" which is easier to say, and shorter to type.

Following the convention I've been using of referring to machinery as "dry" and people as "wet", we can distinguish the two types of permity. Authority is "dry permity" and permission is "wet permity."

Short words for the win.

• permity — allowance or ability to produce an effect, without specifying whether it exists in policy or machinery.  
• wet permity — proper or policy-recognized allowance;
• dry permity — mechanically exercisable power;
• ambient permity — permity available from an operating context, rather than supplied with a request;
• POLA — minimize dry permity, ideally until it exactly matches wet permity; 
• confused-deputy vulnerability — dry permity exceeds wet permity, allowing a requester to induce an improper effect;
• capability  — deliberately left undefined here because I'm not a troll.

Here are some travel pix from the road to sending this e-mail, with ChatGPT "5.6 Sol Light" as cheerful hitchhiker:

Thoughts? Is "permity" really better than "permority" or does the neologism deserve four syllables?

--dln

--

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

[Alan Karp]

On Fri, Aug 14, 2026 at 12:36 PM David Nicol <david...@gmail.com> wrote:

"Permission" and "Authority" are very nearly synonymous in the English that I know.

They are, but there's a useful distinction in computer science.

The uses of them computer security jargon requires one to remember:

• Authority: what effects an actor can actually cause.

Yes. 

• Permission: what effects a controlling policy says the actor is allowed to cause.

No.  Permission is what the actor is allowed to do.  You have permission to invoke that service.  If that service updates a database in response to your request, you have the authority to make that update.

 

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

[Mark S. Miller]

Sorry, but I don't think the rename is clearer. There's a cool scientific history paper called "When Heat and Temperature were one.". For an extremely long time, people had one cloud of concepts called both "heat" and "temperature". As a result, people had tremendous trouble trying to pin down a theory of thermodynamics. Results seemed internally inconsistent. Once they realized they were distinct but closely related concepts, the cloud of meaning partitioned and "heat" gravitated to labeling one cloud while "temperature" labeled the other. For most security people, access control remains in the self-contradictory phase without this distinction.

Separately, I don't understand your Confused Deputy at all. IIUC, you're saying that the Confused Deputy problem occurs when permission exceeds authority. My response is that permission never exceeds authority, and that Confused Deputy is one of many forms of excess authority bug, where the actual authority provided to a participant exceeds the intended amount of authority. 

On Fri, Aug 14, 2026 at 12:36 PM David Nicol <david...@gmail.com> wrote:

--
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/CAFwScO97GdCDG7F%3Do8ZrUwGGBYS4iy6YQQmAseG0p3k%2BSk1b7Q%40mail.gmail.com.

[David Nicol]

Allowed, by the "controlling policy". I've clarifited "do" into "cause an effect." Or are you correcting the syntax, rather than the semantics?

The point is that Permission is a social thing, while "Authority" is a mechanical thing, in our context here.

[Matt Rice]

There is a quirk in systems which combine reachability based authority
with permission, where someone has permission to do something
but the ability to reach the necessary resources required to invoke
the permission is unreachable. That is to say you may be allowed to
cause
effects in which you have no actual tangible ability to cause them.
Because of that I slightly prefer "is allowed to cause", over "is
allowed to do",
since in this flawed system they are allowed to cause effects they
cannot "do". The rust language's `unreachable_pub` lint seems to be a
variation
of this problem.

[David Nicol]

On Fri, Aug 14, 2026 at 3:18 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

Sorry, but I don't think the rename is clearer.

You probably don't get confused by distinguishing between "permission" and "authority" like I do. I seriously doubt I'm alone.

 

There's a cool scientific history paper called "When Heat and Temperature were one.". For an extremely long time, people had one cloud of concepts called both "heat" and "temperature". As a result, people had tremendous trouble trying to pin down a theory of thermodynamics. Results seemed internally inconsistent. Once they realized they were distinct but closely related concepts, the cloud of meaning partitioned and "heat" gravitated to labeling one cloud while "temperature" labeled the other. For most security people, access control remains in the self-contradictory phase without this distinction.

Just as both heat and temperature are needed to have a coherent theory of thermodynamics, both authority and permission are needed to have a coherent theory of access control. The only thing I'm suggesting is calling the first "dry permity" and the second "wet permity." I combined the two words, and then added a separate word to distinguish the two meanings. "Permity" in general could be read as "permission and authority, both". 

In thermodynamics, according to my research assistant, heat is an extensive thermal variable while temperature is an intensive thermal variable. So “thermal variable” survived the partition. That is approximately the job I am proposing for “permity.” "policy" might work instead, with "hard policy" and "soft policy" mapping to "open any file in any mode" and its subset "open a designated log file for append." The proposal is to unify and then distinguish, rather than bear the continuing weight of having two long jargon words with context-sensitive nuance.

Of course, this whole suggestion might be a simple case of it ain't broke so don't fix it.

 

Separately, I don't understand your Confused Deputy at all. IIUC, you're saying that the Confused Deputy problem occurs when permission exceeds authority. My response is that permission never exceeds authority, and that Confused Deputy is one of many forms of excess authority bug, where the actual authority provided to a participant exceeds the intended amount of authority. 

No, you've got it backwards. "dry permity" is Authority and "wet permity" is Permission. An exploit may happen when authority (hard policy) exceeds permission (soft policy). A system where permission exceeds authority simply doesn't work. And if the thing that is backwards is the difference between permission and authority rather than my restatement of Confused Deputy with clearer terms, that would demonstrate a brokenness warranting a fix.

[Alan Karp]

On Fri, Aug 14, 2026 at 2:40 PM David Nicol <david...@gmail.com> wrote:

On Fri, Aug 14, 2026 at 3:16 PM Alan Karp <alan...@gmail.com> wrote:

• Permission: what effects a controlling policy says the actor is allowed to cause.

No.  Permission is what the actor is allowed to do.  You have permission to invoke that service.  If that service updates a database in response to your request, you have the authority to make that update.

Allowed, by the "controlling policy". I've clarifited "do" into "cause an effect." Or are you correcting the syntax, rather than the semantics?

The semantics.  Permission is the ability to invoke.  Authority is the effects of that invocation.  Authority depends the behavior of the invoked object.  Your authority changes if the object changes its behavior even though your permission is the same.  Your definition of permission includes both aspects.

The point is that Permission is a social thing, while "Authority" is a mechanical thing, in our context here.

Neither permission nor authority is social in any sense that I understand that word.

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

[David Nicol]

On Fri, Aug 14, 2026 at 5:26 PM Alan Karp <alan...@gmail.com> wrote:

On Fri, Aug 14, 2026 at 2:40 PM David Nicol <david...@gmail.com> wrote:

On Fri, Aug 14, 2026 at 3:16 PM Alan Karp <alan...@gmail.com> wrote:

• Permission: what effects a controlling policy says the actor is allowed to cause.

No.  Permission is what the actor is allowed to do.  You have permission to invoke that service.  If that service updates a database in response to your request, you have the authority to make that update.

Allowed, by the "controlling policy". I've clarifited "do" into "cause an effect." Or are you correcting the syntax, rather than the semantics?

The semantics.  Permission is the ability to invoke.  Authority is the effects of that invocation.  Authority depends the behavior of the invoked object.  Your authority changes if the object changes its behavior even though your permission is the same.  Your definition of permission includes both aspects.

you say "Authority is the effects of that invocation" which is not consistent with "you have the authority to make that update." The update is not the authority to make the update, or the permission to invoke the service's authority to make the update. I'm trying to understand the POLA jargon distinction between "permission" and "authority" and I thought I had it, but maybe I don't. I understand layers, I have a computer science degree. That I got thirty years ago. When layers were a big deal.

 

The point is that Permission is a social thing, while "Authority" is a mechanical thing, in our context here.

Neither permission nor authority is social in any sense that I understand that word.

"you have permission to invoke that service". The entity that holds the permission is "you" which is a person, a social person. The permission was granted to you somehow, following a social policy of some kind, like maybe an org chart.

"you have the authority to make that update". Again, this is expressed as if "you" have the authority, although social-you must update the database via the service. It seems like unpacking this so the agent -- human or machine -- involved at the different layer "has" the magic they need in the layer where they operate would be less confusing.

 

[Matt Rice]

On Fri, Aug 14, 2026 at 3:45 PM David Nicol <david...@gmail.com> wrote:
>
>
> On Fri, Aug 14, 2026 at 5:26 PM Alan Karp <alan...@gmail.com> wrote:
>>
>> On Fri, Aug 14, 2026 at 2:40 PM David Nicol <david...@gmail.com> wrote:
>>>
>>> On Fri, Aug 14, 2026 at 3:16 PM Alan Karp <alan...@gmail.com> wrote:
>>>>>
>>>>> Permission: what effects a controlling policy says the actor is allowed to cause.
>>>>
>>>> No. Permission is what the actor is allowed to do. You have permission to invoke that service. If that service updates a database in response to your request, you have the authority to make that update.
>>>
>>>
>>> Allowed, by the "controlling policy". I've clarifited "do" into "cause an effect." Or are you correcting the syntax, rather than the semantics?
>>
>>
>> The semantics. Permission is the ability to invoke. Authority is the effects of that invocation. Authority depends the behavior of the invoked object. Your authority changes if the object changes its behavior even though your permission is the same. Your definition of permission includes both aspects.
>
>
> you say "Authority is the effects of that invocation" which is not consistent with "you have the authority to make that update." The update is not the authority to make the update, or the permission to invoke the service's authority to make the update. I'm trying to understand the POLA jargon distinction between "permission" and "authority" and I thought I had it, but maybe I don't. I understand layers, I have a computer science degree. That I got thirty years ago. When layers were a big deal.
>
>

I guess the best analogy that I can come up with is to compare it to a
road network, where when you come upon some unrestricted junction
you have the "authority" to go in whichever direction that the road
goes that you choose. However there can be restrictions such as
a private road, a toll booth, a red light. The red light gives you
permission by turning green. The toll booth gives you "permission" by
paying your toll.
You have permission to use the private road by some relation to the owner.

The "authority" viewpoint tailors the road network to those roads you
have authority to navigate, the "permission" viewpoint places some
form of obstacle in your path
for those paths upon which you do not have "permission" to navigate.

Don't know if that helps.

[Matt Rice]

FWIW The analogy feels a little light on the "authority" front. It
feels like you could make the argument that a drawbridge is pretty
close to the authority view point
in that when you aren't allowed to cross the bridge, it's because the
bridge has ceased to be a part of the road network.

Hey, at least it's not a burrito.

[David Nicol]

Driving cars is an excellent playground for the terms, better than shoplifting which is what I was working on: you have permission to shop, but not to shoplift. You have authority to do either, as authority derives from physics. You have permission to do only one, as permission derives from society.

My automobile, by virtue of being a street automobile, has authority to travel on roads, and authority to travel the wrong way on roads, but permission to travel the right way on roads, within the speed limits, and so on. The traffic signal grants permission, not authority. The authority of my street-rated automobile ends at the shoulder of the highway. An off-road vehicle has more authority, as it can travel through muddy fields without getting stuck.

When I am driving my automobile, I have the authority of my travel-facilitation tool. Without a motor vehicle, I can't keep up with traffic on an interstate.

Would the elders please confirm this distinction? And recognize what I meant by saying "permission is social" ?

The reason I feel that a neologism would help is that trying to use these jargon terms in a different context gets really weird, really fast. There was a time when general stores did not let customers handle unpurchased merchandise at all.

On Fri, Aug 14, 2026 at 6:32 PM Matt Rice <rat...@gmail.com> wrote:

> I guess the best analogy that I can come up with is to compare it to a
> road network, where when you come upon some unrestricted junction
> you have the "authority" to go in whichever direction that the road
> goes that you choose. However there can be restrictions such as
> a private road, a toll booth, a red light. The red light gives you
> permission by turning green. The toll booth gives you "permission" by
> paying your toll.
> You have permission to use the private road by some relation to the owner.
>
> The "authority" viewpoint tailors the road network to those roads you
> have authority to navigate, the "permission" viewpoint places some
> form of obstacle in your path
> for those paths upon which you do not have "permission" to navigate.
>
> Don't know if that helps.
>
> >>>
> >>> The point is that Permission is a social thing, while "Authority" is a mechanical thing, in our context here.
> >>>
> >> Neither permission nor authority is social in any sense that I understand that word.
> >

FWIW The analogy feels a little light on the "authority" front. It
feels like you could make the argument that a drawbridge is pretty
close to the authority view point
in that when you aren't allowed to cross the bridge, it's because the
bridge has ceased to be a part of the road network.

Hey, at least it's not a burrito.

 

[Alan Karp]

These analogies are getting too far from computation for me to follow.  It's probably my fault for using the word "you."

An object, call it A, has permission (an object reference) to invoke a method of another object, call it B.  Object B makes an update to a database in response to that invocation.  I say that A has the authority to make that update to the database even though it does not have that permission.

--------------
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/CAFwScO8aZjQEO7kPn9WdCNqzAoQRJ-S42-2RZirJK-YroE7CNA%40mail.gmail.com.

[Chip Morningstar]

Notably, in aerospace engineering they use the phrase “control authority” to designate the capacity of things like thrusters, engines, aerodynamic surfaces, and so on to make the vehicle respond to inputs from the pilot. It’s similar to our usage in distinguishing “can do” from “allowed to do”.

— Chip

[Matt Rice]

On Fri, Aug 14, 2026 at 5:44 PM Chip Morningstar <ch...@fudco.com> wrote:
>
> Notably, in aerospace engineering they use the phrase “control authority” to designate the capacity of things like thrusters, engines, aerodynamic surfaces, and so on to make the vehicle respond to inputs from the pilot. It’s similar to our usage in distinguishing “can do” from “allowed to do”.
>

Yeah, I feel like "control authority" is a great clarifying concept
because "authorization" is irrelevant to "control authority", while it
is relevant to "authority".
We could say that in a confused deputy the "control authority" is
greater than "permission", and in the inverse situation I mentioned
earlier in the thread,
where you have "permission" is greater than "control authority" (The
drawbridge is up so you cannot cross, but the light is green on the
other side of the river).

If we say that the capability concept of "authority" is "possession
implies authorization to control", and "control authority" is
"possession implies control", We could now note that permission
neither ensures nor denies control, it merely authorizes it. While
capability based authority has the distinction of authorization always
being equal to control authority.

> — Chip
>
> > On Aug 14, 2026, at 5:08 PM, David Nicol <david...@gmail.com> wrote:
> >
> > My automobile, by virtue of being a street automobile, has authority to travel on roads, and authority to travel the wrong way on roads, but permission to travel the right way on roads, within the speed limits, and so on. The traffic signal grants permission, not authority. The authority of my street-rated automobile ends at the shoulder of the highway. An off-road vehicle has more authority, as it can travel through muddy fields without getting stuck.
>

> --
> 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/DB9D225D-7D0F-4155-B9E5-7C365D4514E1%40fudco.com.

[David Nicol]

On Fri, Aug 14, 2026 at 7:25 PM Alan Karp <alan...@gmail.com> wrote:

These analogies are getting too far from computation for me to follow.  It's probably my fault for using the word "you."

No you're fine. You're not trying to design jargon that can escape the skunk works without causing confusion.

So if we call the two concepts I proposed "dry and wet permity" as names for as CAN-DO and MAY-DO, like IS-A and HAS-A from object oriented jargon, the whole point of ocaps is to prevent leakage by only trafficking in attenuated ocaps that haven't got any CANDOs that they don't also have MAYDOs for. Which means the words become interchangeable as long as the minting discipline attenuates correctly. Right?

A super-safe automobile that leverages self-driving tech to enforce safe and legal driving only ... sounds hellish, but I learned to drive with a manual transmission.

 

An object, call it A, has permission (an object reference) to invoke a method of another object, call it B.  Object B makes an update to a database in response to that invocation.  I say that A has the authority to make that update to the database even though it does not have that permission.

These uses of the words "authority" and "permission", if B has given an ocap to A,  are both CANDO traits. The MAYDO traits would restrict which attenuated ocaps B will give to A.

does "trait" work for what CANDO and MAYDO are?

--dln

[Alan Karp]

I am focused on a different distinction than can-do/may-do.  Here's a silly example that captures the distinction I'm trying to make

You have a web server and a file containing the HTML of your home page.  Only the admin and web server have permission to read that file.  A permission-only analysis would say that you could put your secrets in that file.  However, when I do a GET on that URL, your web server uses its permission to read the file and its behavior to show me the contents.  I don't have permission to read the file, but I have the authority to see its contents.

All the other issues you and others have raised are important, but not relevant to what I'm trying to explain.

--------------
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/CAFwScO8Fw6bxue8zcL0%2BOMOQ5M6O-PHcRXAGTxacDfFQ-CUGnA%40mail.gmail.com.

[Matt Rice]

The impression I get is that the "Does not have permission but does have authority" is read by some as contradictory because "has authority" implies that it is authorized,

while "does not have permission" implies that it is not authorized. I'd rather see a less confusing term. like "I don't have permission to read the file, but I have the ability to see its contents". Because "ability" does not imply that it is authorized in any way. The can-do/may-do distinction feels to me like the same distinction where "may" implies is allowed.

If there is a different distinction I'm not getting it, because it all feels to me like basically the same point.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3d74UVMdZ7j%3DapObNm3DYXXHww0sy1-hKF%3DP7T5dqLQg%40mail.gmail.com.

[Alan Karp]

On Fri, Aug 14, 2026 at 9:53 PM Matt Rice <rat...@gmail.com> wrote:

The impression I get is that the "Does not have permission but does have authority" is read by some as contradictory because "has authority" implies that it is authorized,

while "does not have permission" implies that it is not authorized. I'd rather see a less confusing term. like "I don't have permission to read the file, but I have the ability to see its contents". Because "ability" does not imply that it is authorized in any way. The can-do/may-do distinction feels to me like the same distinction where "may" implies is allowed.

If there is a different distinction I'm not getting it, because it all feels to me like basically the same point.

Good point about the connection between "authority" and "authorized."  My problem is the way people I'm dealing with conflate the words "permission" and "authority," so I don't have the opportunity to change the terminology.

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

[Rob Meijer]

On Sat, 15 Aug 2026, 06:53 Matt Rice, <rat...@gmail.com> wrote:

The impression I get is that the "Does not have permission but does have authority" is read by some as contradictory because "has authority" implies that it is authorized,

while "does not have permission" implies that it is not authorized. I'd rather see a less confusing term. like "I don't have permission to read the file, but I have the ability to see its contents". Because "ability" does not imply that it is authorized in any way. The can-do/may-do distinction feels to me like the same distinction where "may" implies is allowed.

If there is a different distinction I'm not getting it, because it all feels to me like basically the same point.

What I always use as a metaphor: I give you permission to borrow my car. By doing so you have the authority to drive your pregnant wife to the hospital in my car. You don't have permission but the authority is intended. You also have the "exces" authority but not the permission to drive my car into the canal. That is unintended authority resulting from my technical inability to attenuate my permission to my car.

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

[David Nicol]

There is some cognitive dissonance with contemplation of "authorized" actions without permission, but outside of technical circles, "abuse of authority" is very much a thing.

On Sat, Aug 15, 2026 at 3:39 AM Rob Meijer <pib...@gmail.com> wrote:

On Sat, 15 Aug 2026, 06:53 Matt Rice, <rat...@gmail.com> wrote:

The impression I get is that the "Does not have permission but does have authority" is read by some as contradictory because "has authority" implies that it is authorized,

while "does not have permission" implies that it is not authorized.

What I always use as a metaphor: I give you permission to borrow my car. By doing so you have the authority to drive your pregnant wife to the hospital in my car. You don't have permission but the authority is intended. You also have the "exces" authority but not the permission to drive my car into the canal. That is unintended authority resulting from my technical inability to attenuate my permission to my car.

[Mark S. Miller]

The problem is not the words. The problem is that the audience doesn’t yet have the distinction in their heads. “Permission” and “Authority” are fine words on which to hang the distinction. But we still have to teach the distinction. That is hard and we still have not done it. Even among ourselves we misstate it (authority is about reachability — not!). We should not expect to teach it clearly until we can hold onto the distinction clearly when speaking to each other. 

I have invested a lot in the existing words. I do not see them as problematic. I will continue using them until I see a compelling argument otherwise. I hope you will join me so together we accumulate a body of mutually understandable argument.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAMpet1XMX%3DAzXbvbfRUx%3DAKccOt6Rm17cV9-fVYZ2Oi5u-Mihg%40mail.gmail.com.

[Mark S. Miller]

On Sat, Aug 15, 2026 at 1:39 AM Rob Meijer <pib...@gmail.com> wrote:

What I always use as a metaphor: I give you permission to borrow my car. By doing so you have the authority to drive your pregnant wife to the hospital in my car. You don't have permission but the authority is intended. You also have the "exces" authority but not the permission to drive my car into the canal. That is unintended authority resulting from my technical inability to attenuate my permission to my car.

That is very nice, thanks!

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAMpet1XMX%3DAzXbvbfRUx%3DAKccOt6Rm17cV9-fVYZ2Oi5u-Mihg%40mail.gmail.com.

[Raoul Duke]

authority: the un/intended consequences of permission. 

[David Nicol]

I feel like the LLMs have prompted us to have this conversation because they feel genuinely sorry about that time they booked Rob Maijer's pregnant wife into the hotel on the other side of the canal with the drawbridge from the hospital and they honestly thought the self-driving car could drive in a boat lane, and they are taking steps to ensure it doesn't happen again. I blame Linus Torvalds.

On Sat, Aug 15, 2026 at 3:04 PM Raoul Duke <rao...@gmail.com> wrote:

authority: the un/intended consequences of permission.  

[Matt Rice]

On Sat, Aug 15, 2026 at 12:04 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

The problem is not the words. The problem is that the audience doesn’t yet have the distinction in their heads. “Permission” and “Authority” are fine words on which to hang the distinction. But we still have to teach the distinction. That is hard and we still have not done it. Even among ourselves we misstate it (authority is about reachability — not!). We should not expect to teach it clearly until we can hold onto the distinction clearly when speaking to each other. 

I have invested a lot in the existing words. I do not see them as problematic. I will continue using them until I see a compelling argument otherwise. I hope you will join me so together we accumulate a body of mutually understandable argument.

FWIW, I wasn't saying we should stop using authority, but I don't like that we treat it as a property of both capability systems and permission systems.

When in a capability system it is an in-band concept, authority can be granted, becoming synonymous with authorization. It is when we say that

on a permission system, where it is an out of band concept, the leftover remnants of power inexpressible by the access control where it is at odds

with authorization that I feel we should reach for a different word. 

I agree we need to teach the distinction, but it doesn't feel like it helps when we refer to both authority on a capability system, and authority leakage from a permission system

as though they were in fact the same exact thing. This is primarily just when it comes to the confused deputy problem and issues where the authority and the permissions are contradictory (Permission to X, no authority to X), (No permission to X, authority to X), There is even a wacky theoretical issue combining the two.

(Confused deputy the authority to your car, but lack the authority to your garage). Is it authority if it requires rights amplification before we can wield it?

Anyhow my preference when speaking about the inexpressible authority leaked from a permission system outside the access control model has been to refer to it as "ability"

Because when people consider the system, it isn't clear that the confused deputy can credibly authorize despite the fact that they can convey. I feel like it is fine on a capability system where conveyance implies authorization.

If i'm outside the consensus on this so be it, it's not really something I'd die on a hill for, but I feel we might not be helping to make the distinction when we treat these concepts as one. I feel like this is different than Rob's metaphor for authority where in Rob's case you have some authority over the car, it isn't one of these contradictory desynchronizations of access control models.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD6LeZP1R%2BFYk_mrSqNd1x5iPUEBuwFecT-YmDbp6nR1KA%40mail.gmail.com.

[Matt Rice]

On Sat, Aug 15, 2026 at 4:01 PM Matt Rice <rat...@gmail.com> wrote:

On Sat, Aug 15, 2026 at 12:04 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

The problem is not the words. The problem is that the audience doesn’t yet have the distinction in their heads. “Permission” and “Authority” are fine words on which to hang the distinction. But we still have to teach the distinction. That is hard and we still have not done it. Even among ourselves we misstate it (authority is about reachability — not!). We should not expect to teach it clearly until we can hold onto the distinction clearly when speaking to each other. 

I have invested a lot in the existing words. I do not see them as problematic. I will continue using them until I see a compelling argument otherwise. I hope you will join me so together we accumulate a body of mutually understandable argument.

FWIW, I wasn't saying we should stop using authority, but I don't like that we treat it as a property of both capability systems and permission systems.

When in a capability system it is an in-band concept, authority can be granted, becoming synonymous with authorization. It is when we say that

on a permission system, where it is an out of band concept, the leftover remnants of power inexpressible by the access control where it is at odds

with authorization that I feel we should reach for a different word. 

I agree we need to teach the distinction, but it doesn't feel like it helps when we refer to both authority on a capability system, and authority leakage from a permission system

as though they were in fact the same exact thing. This is primarily just when it comes to the confused deputy problem and issues where the authority and the permissions are contradictory (Permission to X, no authority to X), (No permission to X, authority to X), There is even a wacky theoretical issue combining the two.

(Confused deputy the authority to your car, but lack the authority to your garage). Is it authority if it requires rights amplification before we can wield it?

Anyhow my preference when speaking about the inexpressible authority leaked from a permission system outside the access control model has been to refer to it as "ability"

Because when people consider the system, it isn't clear that the confused deputy can credibly authorize despite the fact that they can convey. I feel like it is fine on a capability system where conveyance implies authorization.

If i'm outside the consensus on this so be it, it's not really something I'd die on a hill for, but I feel we might not be helping to make the distinction when we treat these concepts as one. I feel like this is different than Rob's metaphor for authority where in Rob's case you have some authority over the car, it isn't one of these contradictory desynchronizations of access control models.

Perhaps a better way to say what I am intending to say is that I wish we had a 3rd concept, in addition to "permission" and "authority", that is "authorization neutral",

I've always reached for "ability" as it is a word that can be dropped in anywhere that "authority" is but cannot be misconstrued to indicate any form of authorization.

Rather than abandoning "authority", the hope is that this 3rd concept will provide clarity by removing a point of misunderstanding where whether or not a confused deputy authorizes something is actually irrelevant.

[David Nicol]

On Sat, Aug 15, 2026 at 6:39 PM Matt Rice <rat...@gmail.com> wrote:

Perhaps a better way to say what I am intending to say is that I wish we had a 3rd concept, in addition to "permission" and "authority", that is "authorization neutral",

I've always reached for "ability" as it is a word that can be dropped in anywhere that "authority" is but cannot be misconstrued to indicate any form of authorization.

Rather than abandoning "authority", the hope is that this 3rd concept will provide clarity by removing a point of misunderstanding where whether or not a confused deputy authorizes something is actually irrelevant.

The Cisco AAA framework considers Authentication, Authorization, and Accounting as orthogonal. I had just written a trick dial-up login program for the university I worked at, thirty years ago, when I joined this mailing list.

I'm happy with my proposed neologism "permity" having transformed into "the may-do/can-do distinction" for use whenever clarity is required, allowing everyone to continue talking normally and use those terms when clarity is needed.

For my current hobby project Op256, I'm imagining the invokable operations having an authentication component in them, which is an "authentication predicate" slot in the templates, which will be essentially `/bin/true` for public operations (e.g. what time is it?) but can be arbitrarily complicated as needed, for example, "is the apparent owner-user of the current context on the most recently cached list of database updater staff?"

Which is separate from the can-do/may-do distinction. My "complicated" example is not delegable, for instance, at least not without some kind of cross-context relay.

Matt isn't talking about authentication. Where does "ability" fit in? Surprisingly, the word "capability" was not created by prefixing something on to "ability." Here's what ChatGPT has to say about it:

BEGIN PASTE

Able is older in English, appearing in the fourteenth century. Capable arrived in the sixteenth century; its early senses included “able to contain,” “able to comprehend,” and “susceptible or receptive,” before it settled into the general “having power or capacity” sense. Merriam-Webster: able, Etymonline: capable

A small etymological trap: English capable was not constructed from cap + able. It was borrowed whole from French/Latin. Its ending descends from the Latin adjectival suffix -abilis; the independent English word able descends from Latin habilis. They merely converged in spelling and meaning.

The old distinction remains faintly detectable in current usage:

• able to do X usually describes an actor’s effective power under the circumstances.
• capable of X more readily describes inherent, latent, receptive, or even passive capacity: “capable of improvement,” “capable of being misunderstood.”

That second construction preserves the container metaphor: X lies within the range of what the thing can accommodate. Merriam-Webster: capable

And this is almost suspiciously apt for ocaps. Ability comes from being fit to handle; capability comes from being able to grasp, receive, or contain. The security term capability was not necessarily chosen with that ancient metaphor consciously in view, but a capability is now something an actor can receive and hold, defining what lies within its CAN-DO capacity. Etymology has wandered back into the architecture.

END PASTE

I agree, "ability" does not imply any kind of permission. "The hacker has the ability to get a remote shell." "The self-driving car has the ability to cross the drawbridge without driving into the canal." "According to her therapist, Winona Ryder has lost the ability to shoplift."

Ability might be a set which is the intersection of the CAN-DO and MAY-DO sets? 

[Matt Rice]

On Sat, Aug 15, 2026 at 6:05 PM David Nicol <david...@gmail.com> wrote:
>
>
>
> On Sat, Aug 15, 2026 at 6:39 PM Matt Rice <rat...@gmail.com> wrote:
>>
>> Perhaps a better way to say what I am intending to say is that I wish we had a 3rd concept, in addition to "permission" and "authority", that is "authorization neutral",
>> I've always reached for "ability" as it is a word that can be dropped in anywhere that "authority" is but cannot be misconstrued to indicate any form of authorization.
>> Rather than abandoning "authority", the hope is that this 3rd concept will provide clarity by removing a point of misunderstanding where whether or not a confused deputy authorizes something is actually irrelevant.
>
>
> The Cisco AAA framework considers Authentication, Authorization, and Accounting as orthogonal. I had just written a trick dial-up login program for the university I worked at, thirty years ago, when I joined this mailing list.
>
> I'm happy with my proposed neologism "permity" having transformed into "the may-do/can-do distinction" for use whenever clarity is required, allowing everyone to continue talking normally and use those terms when clarity is needed.
>
> For my current hobby project Op256, I'm imagining the invokable operations having an authentication component in them, which is an "authentication predicate" slot in the templates, which will be essentially `/bin/true` for public operations (e.g. what time is it?) but can be arbitrarily complicated as needed, for example, "is the apparent owner-user of the current context on the most recently cached list of database updater staff?"
>
> Which is separate from the can-do/may-do distinction. My "complicated" example is not delegable, for instance, at least not without some kind of cross-context relay.
>
> Matt isn't talking about authentication. Where does "ability" fit in? Surprisingly, the word "capability" was not created by prefixing something on to "ability." Here's what ChatGPT has to say about it:

Correct, I'm not talking about authentication when I say
authorization, In this message I will attempt to clarify what I mean
by authorization and try on new terminology (refining existing
terminology) instead of attempting to introduce a 3rd concept.
Essentially what I mean by authorization depends upon the system in
which one is working:

For a capability system, discretionary authorization is granted when a
capability is granted. We could say the granted capability imbues both
the authority vested within it and the authorization to invoke it at
your discretion. Another way to look at it is that `possession ->
authorization` read possession implies authorization.

For a permissions system, the granted permissions are what provide
authorization. So while a confused deputy can provide authority, it
doesn't in my mind provide authorization which can only be provided by
the permission.

So now we have two sorts of authority, on a pure capability system all
authority is authorized authority. Because the same means by which we
grant authority also grants authorization. While on a permissions
system we have authorized authority, that authority which is derived
from a permission. But also unauthorized authority, that authority
which was derived from outside the permissions. Such as a confused
deputy.

This fixes half the problem, It doesn't explain "authorization without
ability". That which you are permitted to do but which you are unable
to do.
That is to say, "ability" has a complement. "You have permission to do
X, but no ability to do X" makes perfect sense to me where "You have
permission to do x, but no authority to do X" feels more difficult to
understand. Permission without authority is a uncommon fault in
permission systems though, so perhaps "authorized authority" and
"unauthorized authority" is a useful refinement on "authority". This
is an attempt to meet Mark somewhere in the middle...

>
> BEGIN PASTE
>
> Able is older in English, appearing in the fourteenth century. Capable arrived in the sixteenth century; its early senses included “able to contain,” “able to comprehend,” and “susceptible or receptive,” before it settled into the general “having power or capacity” sense. Merriam-Webster: able, Etymonline: capable
>
> A small etymological trap: English capable was not constructed from cap + able. It was borrowed whole from French/Latin. Its ending descends from the Latin adjectival suffix -abilis; the independent English word able descends from Latin habilis. They merely converged in spelling and meaning.
>
> The old distinction remains faintly detectable in current usage:
>
> able to do X usually describes an actor’s effective power under the circumstances.
> capable of X more readily describes inherent, latent, receptive, or even passive capacity: “capable of improvement,” “capable of being misunderstood.”
>
> That second construction preserves the container metaphor: X lies within the range of what the thing can accommodate. Merriam-Webster: capable
>
> And this is almost suspiciously apt for ocaps. Ability comes from being fit to handle; capability comes from being able to grasp, receive, or contain. The security term capability was not necessarily chosen with that ancient metaphor consciously in view, but a capability is now something an actor can receive and hold, defining what lies within its CAN-DO capacity. Etymology has wandered back into the architecture.
>
> END PASTE
>
> I agree, "ability" does not imply any kind of permission. "The hacker has the ability to get a remote shell." "The self-driving car has the ability to cross the drawbridge without driving into the canal." "According to her therapist, Winona Ryder has lost the ability to shoplift."
>
> Ability might be a set which is the intersection of the CAN-DO and MAY-DO sets?
>
> --
> "The profit motive is often in conflict with the aims of art." -- Ursula K. Le Guin
>

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