Permission/authority

[Alan Karp]

I find the distinction useful, but many of the people I talk to aren't aware of the difference.  Most of them quickly adopt the concept once I explain it to them.

I'm drafting a LinkedIn post to explain it, but I don't know who to attribute the concept to.

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

[Jonathan S. Shapiro]

I've been catching up on AuthZ things over the last week, refreshing on ABAC and getting my head around ReBAC.

The capability notion of authority is about reachability. Many non-capability notions of authority are about set unions - though ReBAC can express things that don't ground out in that way. And of course it's all ambient, or at best very weakly designated (in the sense that maybe I can designate a role that is a set of un-designatable authorities).

I wonder how much that difference in view is connected to people not distinguishing authority from permission.

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

[Alan Karp]

On Wed, Aug 12, 2026 at 10:09 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

I've been catching up on AuthZ things over the last week, refreshing on ABAC and getting my head around ReBAC.

The capability notion of authority is about reachability. Many non-capability notions of authority are about set unions - though ReBAC can express things that don't ground out in that way. And of course it's all ambient, or at best very weakly designated (in the sense that maybe I can designate a role that is a set of un-designatable authorities).

I wonder how much that difference in view is connected to people not distinguishing authority from permission.

The impression I get from talking to these folks is not at all.  They seem to be stuck at a different place in the stack, namely that everything starts with authentication.

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

[Raoul Duke]

don't most folks need authn for accounting?

ocap is a lot of sweater thread to unravel...

[Mark S. Miller]

A friend of mine invited me to write a follow up paper to Capability Myths Demolished. But in discussing the paper, he repeatedly said that Boebert was right and that my counter-argument was wrong. I think we spent many hours arguing without progress. Both of us thinking "This person is so smart, and we have such a common view of capability security. How can he not understand my argument? And how can he make an argument that is so obviously wrong?" I spend a sleepless night turning the conversation over in my head, trying to figure out what I was missing. That's when the distinction between permission and authority jumped out at me. If you read Boebert thinking he's talking about what we now call "permission", then he's obviously right and my counter-argument makes no sense. But if you read thinking in terms of what we now call "authority", then it is the other way around. Of course, a sound and meaningful security guarantee can only be about authority.

The paper I finally submitted to his conference was "Paradigm Regained: Abstraction Mechanisms for Access Control". This paper became the core of Part II "Access Control" of my thesis (attached). The two important additions of Part II over the paper: A much deeper investigation into abstraction levels in section 8.1: "Permission is relative to a frame of reference. Authority is invariant.", and the cross linked hierarchy in figure 8.1 of (Permission <= Authority) x (Current <= Eventual <= Behavior-based bound <= Topology-based bound)

In our paper "Permission and Authority Revisited: towards a formalization" (also attached) Sophia fixed a mistake in my original formulation and also visualized the relationship better as 

although she renames my "Topology-based bound" (T) and Maximal (M), which I still do not think is an improvement.

On Wed, Aug 12, 2026 at 8:55 AM Alan Karp <alan...@gmail.com> wrote:

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

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Wed, Aug 12, 2026 at 10:09 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

I've been catching up on AuthZ things over the last week, refreshing on ABAC and getting my head around ReBAC.

The capability notion of authority is about reachability.

I would not say it is *about reachability". Authority is about what effects an actor/subject can cause, either directly by exercising permissions, or indirectly through the permitted actions of other objects. In a pure ocap system, authority is bounded by reachability/topology, so the topological bound on reasoning about authority is TA in my thesis and MA in Sophia's paper. TA is sound but often too imprecise to be useful. Taking the possible behaviors of the intermediate objects into account (in addition to TA) is BA, which is (by definition?) the most precise bound on authority that we can soundly reason about statically.

Taking it apart, in the "indirectly through the permitted actions of other objects", TA is about a bound on what other objects may become reachable. BA is what permitted actions those other objects might actually engage in.

 

Many non-capability notions of authority are about set unions - though ReBAC can express things that don't ground out in that way. And of course it's all ambient, or at best very weakly designated (in the sense that maybe I can designate a role that is a set of un-designatable authorities).

I wonder how much that difference in view is connected to people not distinguishing authority from permission.

In my experience, a lot.

 

On Wed, Aug 12, 2026 at 8:55 AM Alan Karp <alan...@gmail.com> wrote:

I find the distinction useful, but many of the people I talk to aren't aware of the difference.  Most of them quickly adopt the concept once I explain it to them.

I'm drafting a LinkedIn post to explain it, but I don't know who to attribute the concept to.

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

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z31gQ8GypSBohSprLMGYjjzmCJ9Rjcp7vE%2BhCzyVFKqLw%40mail.gmail.com.

--

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/CAAP%3D3QNwg6fowOhFHbCeedNP2ie16dGTjd0ROFh-%2BU4Gt_Rf0g%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Mark S. Miller]

I agree that is the high order bit. But once you get them past that, their next impediment hangs on confusing permission and authority.

 

--------------
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/CANpA1Z1Mk5BAgy6Y1i6yWXFx1TVnU8-uWxt8CzHmhoqgZzv%3DVA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Wed, Aug 12, 2026 at 10:54 AM Raoul Duke <rao...@gmail.com> wrote:

don't most folks need authn for accounting?

ocap is a lot of sweater thread to unravel...

Horton for responsibility tracking https://www.youtube.com/watch?v=NAfjEnu6R2g . Yes, Horton does introduce back in a form of identity-based access control, but only reactively to repair damage in an emergency. The accountability of Horton without revocation, still introduces identity but not as a form of access control.

 

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

--

  Cheers,
  --MarkM

[Alan Karp]

On Wed, Aug 12, 2026 at 1:15 PM Mark S. Miller <eri...@gmail.com> wrote:

Horton for responsibility tracking https://www.youtube.com/watch?v=NAfjEnu6R2g . Yes, Horton does introduce back in a form of identity-based access control, but only reactively to repair damage in an emergency. The accountability of Horton without revocation, still introduces identity but not as a form of access control.

 

Authentication is necessary to assign responsibility.  Using it as input to an access decision is a mistake.

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

[Mark S. Miller]

> Using it as input to an access decision is a mistake.

Uh, Alan, you are a co-author of the Horton paper. If you think using identity (Horton's "responsible party") only for reactive revocation for damage control is a mistake, what would you do instead? Or do you not think it is a problem worth addressing?

Also your SCoopFS does do this. IMO SCoopFS is a special case of Horton.

--

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/CANpA1Z2W6dzhDJf8%2BxkHuSob63XfMM65OZDQbji%2Bz-8_pX3s1w%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Matt Rice]

On Wed, Aug 12, 2026 at 2:05 PM Mark S. Miller <eri...@gmail.com> wrote:
>
> > Using it as input to an access decision is a mistake.
>
> Uh, Alan, you are a co-author of the Horton paper. If you think using identity (Horton's "responsible party") only for reactive revocation for damage control is a mistake, what would you do instead? Or do you not think it is a problem worth addressing?
>
> Also your SCoopFS does do this. IMO SCoopFS is a special case of Horton.
>

The way I would interpret Alan's statement is that if permission is
using identity as proof of authority,
horton is using identity as evidence/justification for revocation.
Identity isn't used to decide whether an invocation is authorized, so
it's not treating identity as proof of authority.

>
>
> On Wed, Aug 12, 2026 at 1:57 PM Alan Karp <alan...@gmail.com> wrote:
>>
>> On Wed, Aug 12, 2026 at 1:15 PM Mark S. Miller <eri...@gmail.com> wrote:
>>>
>>>
>>> Horton for responsibility tracking https://www.youtube.com/watch?v=NAfjEnu6R2g . Yes, Horton does introduce back in a form of identity-based access control, but only reactively to repair damage in an emergency. The accountability of Horton without revocation, still introduces identity but not as a form of access control.
>>>
>>
>> Authentication is necessary to assign responsibility. Using it as input to an access decision is a mistake.
>>
>> --------------
>> 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/CANpA1Z2W6dzhDJf8%2BxkHuSob63XfMM65OZDQbji%2Bz-8_pX3s1w%40mail.gmail.com.
>
>
>
> --
> Cheers,
> --MarkM
>
> --
> 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/CAK5yZYgbHA6b9T1TAjx%2BP%2BjRFk1ta%3DatnqKrN3AzYYiAwfobcg%40mail.gmail.com.

[Mark S. Miller]

On Wed, Aug 12, 2026 at 2:08 PM Matt Rice <rat...@gmail.com> wrote:

On Wed, Aug 12, 2026 at 2:05 PM Mark S. Miller <eri...@gmail.com> wrote:
>
> > Using it as input to an access decision is a mistake.
>
> Uh, Alan, you are a co-author of the Horton paper. If you think using identity (Horton's "responsible party") only for reactive revocation for damage control is a mistake, what would you do instead? Or do you not think it is a problem worth addressing?
>
> Also your SCoopFS does do this. IMO SCoopFS is a special case of Horton.
>

The way I would interpret Alan's statement is that if permission is
using identity as proof of authority,
horton is using identity as evidence/justification for revocation.
Identity isn't used to decide whether an invocation is authorized, so
it's not treating identity as proof of authority.

That makes sense to me. Alan, do you agree?

--

  Cheers,
  --MarkM

[Matt Rice]

I suppose one of the interesting things about this presentation is that it doesn't rely on identity, I think identity is the stereotypical permission

people typically think of. But I suppose there could be other problematic sources of permission. I've seen proximity based permission,

which has problems as a coarse ambient property.

The example I would give would be the home, as typically a private space except when entertaining. To which one might imagine a physical security key

as the physical analog of a capability.

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/CAK5yZYgzh84aJERqrzh7po%2Bjw4XYr%2Bzs1z2g1OR2Jp8TJXoPpw%40mail.gmail.com.

[Alan Karp]

On Wed, Aug 12, 2026 at 2:05 PM Mark S. Miller <eri...@gmail.com> wrote:

> Using it as input to an access decision is a mistake.

Uh, Alan, you are a co-author of the Horton paper. If you think using identity (Horton's "responsible party") only for reactive revocation for damage control is a mistake, what would you do instead? Or do you not think it is a problem worth addressing?

Also your SCoopFS does do this. IMO SCoopFS is a special case of Horton.

The fact that a capability is revoked is input to the access decision, but the reason for the revocation, here bad behavior associated with an identity, is not.

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

[Mark S. Miller]

That sounds good to me. And it sounds aligned with Matt's earlier point. So I can stop feeling guilty about the use of identity in Horton, thanks!

 

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

[Matt Rice]

On Wed, Aug 12, 2026 at 6:42 PM 'Mark S. Miller' via friam
<fr...@googlegroups.com> wrote:
>
>
>
> On Wed, Aug 12, 2026 at 5:41 PM Alan Karp <alan...@gmail.com> wrote:
>>
>> On Wed, Aug 12, 2026 at 2:05 PM Mark S. Miller <eri...@gmail.com> wrote:
>>>
>>> > Using it as input to an access decision is a mistake.
>>>
>>> Uh, Alan, you are a co-author of the Horton paper. If you think using identity (Horton's "responsible party") only for reactive revocation for damage control is a mistake, what would you do instead? Or do you not think it is a problem worth addressing?
>>>
>>> Also your SCoopFS does do this. IMO SCoopFS is a special case of Horton.
>>>
>> The fact that a capability is revoked is input to the access decision, but the reason for the revocation, here bad behavior associated with an identity, is not.
>
>
> That sounds good to me. And it sounds aligned with Matt's earlier point. So I can stop feeling guilty about the use of identity in Horton, thanks!
>

Yes, I would only quibble about whether the term "decision" is clear,
over some other term like "modification", "action", or "operation"
none of which feels like it properly hits the target, but no semantic
concerns.

[Alan Karp]

On Wed, Aug 12, 2026 at 7:09 PM Matt Rice <rat...@gmail.com> wrote:

Yes, I would only quibble about whether the term "decision" is clear,
over some other term like "modification", "action", or "operation"
none of which feels like it properly hits the target, but no semantic
concerns.

Fair enough for object references as capabilities systems, but there is an actual decision for certificate and opaque capabilities.

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

[Jonathan S. Shapiro]

Very late in his career, I had an opportunity to discuss the permission/authority distinction with Earl. From that discussion, I can confirm that his terminology did not maintain a clear distinction between permission and authority. That was pretty common among contemporaneous papers. Earl clearly understood the distinction, but it didn't fit the lexicon established in his mind, and he had a hard time maintaining the distinction. He passed away just a few years later.

By the time of our conversation, Earl had become very focused on the idea that inattention to security was a consequence of the "crap in a hurry" (his term) mentality. Allowing for some term rotation, I agree that this is a major contributor, but his viewpoint ignored the implications of software NRE and the resulting financial imperatives from a capital/investment point of view. It is largely untrue that people create crap in a hurry in ignorance - due diligence weeds those people out. It is rather true that the due diligence survivors do so because concerns about runway and cumulative financial debt (by analogy to technical debt) leave them little choice.

That is not to say that Earl was wrong, but rather to say that the "in a hurry" was (and remains) compellingly and competitively motivated, and "crap" was an inevitable consequence. Being a year later to launch than a broadly competent competitor with a better solution is a non-starter.

LLMs may have changed this.

Even if we ignore agentic coding, the leverage offered by current LLM technology shortens runways from multiple years to multiple months in the hands of experienced practitioners knowledgeable enough about their domain[s] to specify objectives effectively. Not very long ago, building an OIDC IdP broker was hard because of the level of interacting detail involved. As recently as last year (2025), the context windows available in Pro or Enterprise models were insufficient to improve matters substantially. Today, using the Pro or Enterprise models, the effort iss divided sharply into bad builds reflecting a human need to learn the requirements followed by a good version produced in single digit hours. This year, starting from a seven-year-stale but detailed understanding of the OIDC and OAuth2 specifications, it took me a single month. Not because of retained LLM context but because of my ability to build (in my head) and state the right objectives for the final attempt. And, to some extent, my personal learning curve in recognizing when to have [in my case] Codex start over from scratch. In 2019, the same objective took more time than Buttonsmith could afford. Working with/against a high-end LLM let me constructively refine and challenge my own understanding of the problem.

I have expected that this would reduce the competitive [dis]advantage from years to months, and there is slow evidence that in the hands of domain experts this is true. The obvious consequence would be that the comparative software NRE costs would no longer be the dominating factor in either cost or success. Software NRE is no longer a moat, and the same can be said of most historical moats.

I've spent the last several months crafting an upstart entrant into a market with established (but fragmented) players. Given another month I'll achieve functional parity with a cleaner framework based on personal experience as a victim customer. That gets the project to functional parity, which is enough to start selling. The next step is strategic use of ML and LLMs, which lowers operating costs in a profoundly disruptive way in this space.

My point, I suppose, is to illustrate the problem of moat disruption and to indicate how low the bar is to disruption. I'm a fairly consistent reader of Sammy Abdullah's Medium posts on SaaS, but I'm inclined to believe that the SaaS investment fad is coming to an end. Market share if sticky is defensible; SaaS intrinsically and software per se are no longer sticky.

Jonathan

[William ML Leslie]

Et tu, Brute! :D

--

William ML Leslie

Never interrupt the enemy when they're pivoting to AI.