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.

[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

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

[John Carlson]

More inspiration for Alan:

What I gather from this is permissions are about local frames of reference, and authority is about a universal frame of reference or an “invariant” frame of reference or every permission one can possibly use as a local frame of reference (ambient authority for example).

Of course, I am a graphics guy.   Chris Thorne puts this magnificently in his thesis.  

You the move the character within the world 

instead of moving the world around a character (he prefers the latter to retain local precision).

Another way to view this is subjective reality vs objective reality.

I would say permissions are about what you can do and authority is about viewing (or operating on) your permissions.  In an object-oriented world, you have what you can do with a reference/capability and what you can do with reflection and introspection.

Another idea is action versus manifestation.

Of course, there’s a man behind the curtain, always.   The curtain is merely Donald Hoffman’s desktop metaphor for senses and evolution (our senses evolve for fitness, not perfection).

I’m not really a capability guy, so this may all be fouled up.

Anyone is free to correct and I welcome it.

Use as you see fit, I don’t think any of it is mine.

John

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

[John Carlson]

So I’m going to bring up a possible new term, “meta-permission” or permission about permission.

Permission is what is allowed to read/write/update/insert/create/delete/execute/run what (without identity, but with some kind of actor, I guess).

Meta-permission is what is allowed to grant/revoke/delegate a permission or attenuating a capability.   Revoking or granting permissions on a capability to create a new capability.

Hmm!

John

[Alan Karp]

I like the term and will start using it.

--------------
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/CAGC3UEn6-gzpURTc2gNkhvLLvXp1Nk%2BFX7cH6hWgo0xzsQ6WXQ%40mail.gmail.com.

[Jonathan S. Shapiro]

It's mildly interesting where this notion makes sense and where it does not. In capability systems, authority is defined by reachability and authority updates are simple capability read and write operations. One can view those as meta-permissions, but they operate in all respects like base permissions.

In something like a ReBAC system, I suppose the closest thing to meta-permissions would be updates to relations. But there doesn't seem to be a clear dividing line that says which relations those are. Without studying the authorization model, one can't really say.

In systems where things are more obviously stratified, there is a clearer distinction between what is meta and what is not.

On the one hand, the last suggests that the distinction is useful. The first two prompt me to want to pause and figure out if there is some underlying principal we aren't thinking about.

Jonathan

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

[Alan Karp]

We don't often think of it this way, but permission to delegate is an operation on the capability rather than on the resource the capability designates.  That makes delegation a meta-permission.  Of course, that's a meta-permission that should always be granted on a capability you hold.  One way to think of it is that someone without the capability doesn't have the delegation meta-permission on it.

I've mainly run into meta-permissions when talking about revocation in certificate capability systems.  You need to know if the revoke request is authorized.  In many systems, only the direct delegator has permission to revoke the delegation, a form of implicit meta-permission.  UCAN allows you to create a revoke permission on a capability certificate that can be delegated and revoked itself.  That's an explicit form of meta-permission.

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

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QMj4Z9Nf7BbyfQasAqnsRccYy_-Bq%2BpCtyZbcuSob3L%3Dg%40mail.gmail.com.

[Raoul Duke]

If it is just eg a swiss number url, how do you prevent delegation?

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

[Alan Karp]

On Thu, Aug 13, 2026 at 6:43 PM Raoul Duke <rao...@gmail.com> wrote:

If it is just eg a swiss number url, how do you prevent delegation?

Let's make a distinction between sharing a capability and delegating it.  Delegation gives you separate revocability and responsibility tracking.  You can share a Swiss number (typically called an opaque token), but you can't delegate it without what's called token exchange.  The entity doing the exchange (usually called the Authorization Server) blocks delegation by refusing to do the exchange.

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

[David Nicol]

Cheap message signing and associating all long opaque codes with an access control list. Is that heresy here?

On Thu, Aug 13, 2026 at 8:43 PM Raoul Duke <rao...@gmail.com> wrote:

If it is just eg a swiss number url, how do you prevent delegation?

 

--

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

[Jonathan S. Shapiro]

On Thu, Aug 13, 2026 at 7:06 PM Alan Karp <alan...@gmail.com> wrote:

Let's make a distinction between sharing a capability and delegating it.  Delegation gives you separate revocability and responsibility tracking....

I think this is a useful distinction. In "traditional" capability systems, by which I mean the Dennis and Van Horn hardware-centric notion of capabilities, we would say copy rather than share, but I think those are two terms for the same thing. Delegation, in systems that supported it, took the form of some kind of transparent interposition objects. I don't recall at the moment whether CAP had such a concept, but many later systems do, including the KeyKOS family. The problem, broadly, being that the tail-chasing depth wants to be bounded and acyclic in such systems for a variety of reasons. I'm not clear whether the same concerns apply to systems built around swiss numbers. I'd count the KeyKOS family in that group, since philosophically that family can accurately be viewed as implementing a thin virtual machine layer over conventional hardware.

I agree that interposition gives you separate revocability tracking. I'm not sure whether responsibility tracking is accurate; it depends what we mean by "responsibility". If we mean something like logging for audit, mere interposition isn't good enough. We will soon find ourselves trying to invent an "invoked for" relation that crosses subsystem boundaries. Which can be very useful, but has proven damned hard to engineer well. Token exchange seems like a better model, but then the audit support needs to record both the exchanges (for later reconstruction) and the capability identity used to invoke the operation.

Neither critique nor endorsement. Just stray thoughts.

[Jonathan S. Shapiro]

On Thu, Aug 13, 2026 at 7:15 PM David Nicol <david...@gmail.com> wrote:

Cheap message signing and associating all long opaque codes with an access control list. Is that heresy here?

Certainly not! If it were heresy here, then surely it would be heresy everywhere. :-)

[Mark S. Miller]

  Cheers,
  --MarkM

On Thu, Aug 13, 2026 at 3:45 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

It's mildly interesting where this notion makes sense and where it does not. In capability systems, authority is defined by reachability and authority updates are simple capability read and write operations. One can view those as meta-permissions, but they operate in all respects like base permissions.

To emphasize Jonathan’s point with the std example:

    Alice says: bob.foo(carol)

Alice is both exercising her right to invoke Bob and permitting Bob to access Carol. Every exercise with object arguments is also an act of permitting.

This uniformity is central to the distinction Capability Myths Demolished makes between Capabilities as Rows vs Capabilities as Keys vs Object-capabilities (ocaps).

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QMj4Z9Nf7BbyfQasAqnsRccYy_-Bq%2BpCtyZbcuSob3L%3Dg%40mail.gmail.com.

[John Carlson]

I’m fully on board with meta-permissions being implemented with base permissions.   The important distinction is meta-permissions increase or decrease permission/authority, whereas base permissions don’t (unless it’s hidden below the top-level).  I might execute a program (base permission) that changes permissions (meta-permission), for example.

John 

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QMj4Z9Nf7BbyfQasAqnsRccYy_-Bq%2BpCtyZbcuSob3L%3Dg%40mail.gmail.com.

[Jonathan S. Shapiro]

On Thu, Aug 13, 2026 at 8:50 PM Mark S. Miller <eri...@gmail.com> wrote:

Perhaps because I have been wrapping my head around ReBAC this week, an addendum.

To emphasize Jonathan’s point with the std example:

    Alice says: bob.foo(carol)

Alice is both exercising her right to invoke Bob and permitting Bob to access Carol. Every exercise with object arguments is also an act of permitting.

This uniformity is central to the distinction Capability Myths Demolished makes between Capabilities as Rows vs Capabilities as Keys vs Object-capabilities (ocaps).

This seems about right. While one can describe ocaps as relations between a capability holder, the specific capability's permissions, and its target, not all such relations model ocaps. They fail in some common ways. The most common, I think, is that they miss fine-grain designation. This was (e.g.) an intentional simplification that Scott and Sam and I made in our respective models for the two confinement verifications, but this reflects that designation [surprisingly] isn't essential to confinement. Many approaches have arrived at what might be described as "weak" designation (set is designated, constituent capabilities are not) and seem to have done okay where relationships are "mostly static" - this is common in RBAC, ABAC, and ReBAC models.

Which already suggests a good analysis paper for someone to write.

 

In something like a ReBAC system, I suppose the closest thing to meta-permissions would be updates to relations. But there doesn't seem to be a clear dividing line that says which relations those are. Without studying the authorization model, one can't really say.

Addendum: in such systems, the authority to update one relation is often embodied in some other relation. For example, I was discussing discretionary relations with the SpiceDB folks earlier today (the goal being to limit fat-fingering; discretionary permissions are irrelevant to global security properties because they are discretionary). The answer, in brief, is that one relation describes the permissions that might be enabled but doesn't "connect" them, while a second describes how to connect them. But there is no capacity in any of the ReBAC modeling language to describe cloning a relation or copying a tuple from one relation to a second of like type subject to appropriate read and write permissions for permissions (if you will).

I actually started from the the Postgres role model (which is over-complicated), and one of the things I noticed almost immediately is that the owner of a group G can grant membership (therefore rights inheritance) to a member M without any concurrence by or permission to mutate M or even a strong designation of M. Roles are named by strings, the string has to be mentioned in the grant, and the naming string is globally unique, but the operation as defined violates confinement in a single step and invites confused deputy constructions. The only reason this is tolerable in Postgres is that the party issuing these grants (the client service) is trusted and the grant arrangements are mostly static.

Which seems to raise an interesting conundrum: how can a database say that it enforces integrity when an arbitrary client with sufficient authority can modify them, and do so in ways that uncontrollably expand authority?

SQL supports a limited class of compound relations whose safety seems uncertain, but Google Zanzibar and its derivatives support a much broader and less safe form of compound relations. I think an exploration of how to identify (e.g.) ReBAC models that amplify authority, or alternatively, a model specification language that does not, might be interesting. Viewed through a capability lens, ReBAC has obvious problems but simultaneously fails to exploit obvious opportunities.

Jonathan

[Jonathan S. Shapiro]

On Thu, Aug 13, 2026 at 9:15 PM John Carlson <yott...@gmail.com> wrote:

I’m fully on board with meta-permissions being implemented with base permissions.   The important distinction is meta-permissions increase or decrease permission/authority, whereas base permissions don’t (unless it’s hidden below the top-level).  I might execute a program (base permission) that changes permissions (meta-permission), for example.

That turns out not to be a particularly precise definition. There is an enormous definition between increasing permission and increasing authority. Authority in capability systems, by definition, is transitively reachable permission. Merely copying a permission from a (read-authorized) object [that is transitively reachable] to a (write-authorized) object [that is transitively reachable] can be said to [locally] increase permission but does not in any way increase authority available to the copying party or any other party able to observe the target object. It is thoroughly demonstrated that useful production systems can be constructed within this constraint, though certain security policies become much simpler if an attenuating read (a.k.a. weak read) operation is introduced.

I'd argue that such a system does not have meta permissions. The fact that it does not have meta-permissions appears fundamental to a bunch of security properties we care about. Most critically: isolation and confinement.

Having said that, it's certainly possible that we might devise other systems whose graph evolution does not increase authority.

Jonathan

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

[John Carlson]

Agreed, I squashed permission and authority together, even though I thought it unwise.  My apologies.

There’s exercising permission and changing permission.  A meta-permission is a permission that can be use to change permissions.   Alice might grant Bob the ability to introduce Carol to Doug.   So even if Bob knows Carol, he might not have a method to introduce Doug to Carol.  Adding that method is a meta-permission.

I don’t yet have a clear picture of authority, except a graph with absent arcs, and introduction (sharing) can be used to draw (extend authority) arcs between nodes (objects/actors).   Here’s what could be explained better:  When one extends authority in a system, more nodes are added to the reach of other nodes.  When one extends permission, more arc endpoints are added.   When one has partial permission, one has to collaborate and create a hypergraph.   This might be thought of as door that requires two or more keys to unlock.

I’ve pretty much wondered how a Granovetter diagram is bootstrapped without arcs.   How do Alice, Bob, and Carol initially get introduced?  My guess is there’s a system owner (perhaps Alice) who adds Bob and Carol to the system, so Alice is extending authority of the system.  Alice may revoke her permission to pass more permission to Bob and Carol, but this may create a memory leak.

So the question is, can Alice replace Bob with Carol?  Is that a meta-permission? Or replace Bob with Alice?  What happens if Alice replaces herself with Carol?

So one has a permission to add/remove nodes (adding/removing authority), and one has a permission to pass capabilities between nodes (extending authority).   If arcs become nodes (every method is also an object), then one achieves behavioral authority.  Maximal authority is a fully connected graph (ambient authority).

Authority is extended through introduction,   Permission is the ability to use a capability with a method.  Meta-permission is sharing, revoking or delegating existing permissions on an object:  Dropping or adding an introduced object to its internal state.

Again, I’m probably stumbling a bit with terminology.

John 

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QPYhUapEwMq-aNEpxhQ%2BmRO9FFir%3DvZDsY9BksCaXb9kQ%40mail.gmail.com.

[Matt Rice]

On Fri, Aug 14, 2026 at 2:20 AM John Carlson <yott...@gmail.com> wrote:
>
> Agreed, I squashed permission and authority together, even though I thought it unwise. My apologies.
>
> There’s exercising permission and changing permission. A meta-permission is a permission that can be use to change permissions. Alice might grant Bob the ability to introduce Carol to Doug. So even if Bob knows Carol, he might not have a method to introduce Doug to Carol. Adding that method is a meta-permission.
>
> I don’t yet have a clear picture of authority, except a graph with absent arcs, and introduction (sharing) can be used to draw (extend authority) arcs between nodes (objects/actors). Here’s what could be explained better: When one extends authority in a system, more nodes are added to the reach of other nodes. When one extends permission, more arc endpoints are added. When one has partial permission, one has to collaborate and create a hypergraph. This might be thought of as door that requires two or more keys to unlock.
>
> I’ve pretty much wondered how a Granovetter diagram is bootstrapped without arcs. How do Alice, Bob, and Carol initially get introduced? My guess is there’s a system owner (perhaps Alice) who adds Bob and Carol to the system, so Alice is extending authority of the system. Alice may revoke her permission to pass more permission to Bob and Carol, but this may create a memory leak.

I can only recommend Mark S. Miller's thesis section 9.2 Reference
graph dynamics
the entire section covers the 4 ways that connectivity comes to be,
more thoroughly than I want to attempt to relay over email.
https://papers.agoric.com/assets/pdf/papers/robust-composition.pdf

>
> So the question is, can Alice replace Bob with Carol? Is that a meta-permission? Or replace Bob with Alice? What happens if Alice replaces herself with Carol?
>
> So one has a permission to add/remove nodes (adding/removing authority), and one has a permission to pass capabilities between nodes (extending authority). If arcs become nodes (every method is also an object), then one achieves behavioral authority. Maximal authority is a fully connected graph (ambient authority).
>
> Authority is extended through introduction, Permission is the ability to use a capability with a method. Meta-permission is sharing, revoking or delegating existing permissions on an object: Dropping or adding an introduced object to its internal state.
>
> Again, I’m probably stumbling a bit with terminology.
>
> John
>
> On Fri, Aug 14, 2026 at 1:29 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:
>>
>> On Thu, Aug 13, 2026 at 9:15 PM John Carlson <yott...@gmail.com> wrote:
>>>
>>> I’m fully on board with meta-permissions being implemented with base permissions. The important distinction is meta-permissions increase or decrease permission/authority, whereas base permissions don’t (unless it’s hidden below the top-level). I might execute a program (base permission) that changes permissions (meta-permission), for example.
>>
>>
>> That turns out not to be a particularly precise definition. There is an enormous definition between increasing permission and increasing authority. Authority in capability systems, by definition, is transitively reachable permission. Merely copying a permission from a (read-authorized) object [that is transitively reachable] to a (write-authorized) object [that is transitively reachable] can be said to [locally] increase permission but does not in any way increase authority available to the copying party or any other party able to observe the target object. It is thoroughly demonstrated that useful production systems can be constructed within this constraint, though certain security policies become much simpler if an attenuating read (a.k.a. weak read) operation is introduced.
>>
>> I'd argue that such a system does not have meta permissions. The fact that it does not have meta-permissions appears fundamental to a bunch of security properties we care about. Most critically: isolation and confinement.
>>
>> Having said that, it's certainly possible that we might devise other systems whose graph evolution does not increase authority.
>>
>>
>> Jonathan
>>
>> --
>> 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/CAAP%3D3QPYhUapEwMq-aNEpxhQ%2BmRO9FFir%3DvZDsY9BksCaXb9kQ%40mail.gmail.com.
>
> --
> 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/CAGC3UEknnNR1OKTygwECVRAZciv6PP%3DNtqNhTZL55QFfQyf5PQ%40mail.gmail.com.

[John Carlson]

I’m just trying to understand authority, permission and meta-permission in terms of a graph.   Nodes and arcs, etc.   I have limited buffer space, but I did try to read section 9.2.

Authority seems to be a connected graph.

Permission seems to be an arc tail.

Capability seems to be an arc with a tail that flows across an arc from node to node and a head that refers to a node.

Meta-permission seems to be the mechanism (meta-graph?) for setting up nodes, arcs and arc heads+tails, the mechanism for creating authority.  That is, reference graph dynamics (section 9.2 of the link below).

Delegating capability means creating a new arc from an old arc with the new arc head still pointing at the old arc.   There’s extra linkage (node?) in the new arc such that it can be revoked by  the delegater, but the delegatee has a proxy to the target node and  at the head of the linkage.

Capabilities may be bundled into a new capability (potentially an arc with multiple heads), and later split apart (attenuation).

Behavior seems to be how the graph behaves over time.  The flow of capabilities between nodes, and how the authority changes.

What are events?   OnCreate, OnConnect, OnDisconnect, OnDestroy, OnUse?

Apologies for the splattergun approach, I’m creating a pattern in my mind.

John

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFqg%2B0ko51BeDypMsjJjex%3DT07EKjMsSShojYLg7MDN7gg%40mail.gmail.com.

[Mark S. Miller]

Please everyone stop saying that authority is the graph, or is reachability within the graph.

Authority is bounded by the graph (TA), specifically, by the transitive closure of the graph as an undirected graph. This is easy to reason about, but is so imprecise as to usually be useless.

Actual authority is further bounded by the actual activity of the objects within that graph (EA). This is intractable, but is what we care about.

Between the two is bounding authority by reasoning about the graph and a bound on all possible behaviors of the relevant objects in the graph (EA). This static analysis is hard but precise enough to be useful.

The arcs of the graph (considered as directed arcs) are the permissions, i.e., the actual capabilities.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UE%3DS436S214W6Ds-4xWC%3DapgCOHOa0rggbXe8PfW3_%2Bqqw%40mail.gmail.com.

[Mark S. Miller]

On Fri, Aug 14, 2026 at 7:44 AM Mark S. Miller <ma...@agoric.com> wrote:

Please everyone stop saying that authority is the graph, or is reachability within the graph.

Authority is bounded by the graph (TA), specifically, by the transitive closure of the graph as an undirected graph. This is easy to reason about, but is so imprecise as to usually be useless.

Actual authority is further bounded by the actual activity of the objects within that graph (EA). This is intractable, but is what we care about.

Between the two is bounding authority by reasoning about the graph and a bound on all possible behaviors of the relevant objects in the graph (EA). This static analysis is hard but precise enough to be useful.

That EA immediately above should be BA.

[Jonathan S. Shapiro]

On Fri, Aug 14, 2026 at 7:44 AM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

Authority is bounded by the graph (TA), specifically, by the transitive closure of the graph as an undirected graph. This is easy to reason about, but is so imprecise as to usually be useless.

Technically, it's a transitive semi-reflexive closure. There are places where the directionality matters. But your point that this is a [loose] upper bound is correct. I can't entirely agree with useless, since both of the substantive information flow policies that have been formally verified sit on this model (ours and the L4 isolation verification).

Actual authority is further bounded by the actual activity of the objects within that graph (EA). This is intractable, but is what we care about.

There is a useful middle position, distinguishing between the actions of trusted actors in the graph vs. untrusted actors. You know the trusted actor behavior by design, which often makes it tractable to reason about.

 

I can only recommend Mark S. Miller's thesis section 9.2 Reference

graph dynamics...

Oh heck yes. That guy is really smart!

Jonathan

[Mark S. Miller]

On Fri, Aug 14, 2026 at 1:12 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

On Fri, Aug 14, 2026 at 7:44 AM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

Authority is bounded by the graph (TA), specifically, by the transitive closure of the graph as an undirected graph. This is easy to reason about, but is so imprecise as to usually be useless.

Technically, it's a transitive semi-reflexive closure. There are places where the directionality matters.

For graph/reachability/toplogy only analysis (TA), what's an example where directionality matters?

 

But your point that this is a [loose] upper bound is correct. I can't entirely agree with useless, since both of the substantive information flow policies that have been formally verified sit on this model (ours and the L4 isolation verification).

Actual authority is further bounded by the actual activity of the objects within that graph (EA). This is intractable, but is what we care about.

There is a useful middle position, distinguishing between the actions of trusted actors in the graph vs. untrusted actors. You know the trusted actor behavior by design, which often makes it tractable to reason about.

 

I can only recommend Mark S. Miller's thesis section 9.2 Reference
graph dynamics...

Oh heck yes. That guy is really smart!

Jonathan

--

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/CAAP%3D3QN5mu6MjPd6iS%3DHVdP5s2D-qEX7-mjDJtm8sFoLVChwXQ%40mail.gmail.com.

[Alan Karp]

On Thu, Aug 13, 2026 at 7:22 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

I think this is a useful distinction. In "traditional" capability systems, by which I mean the Dennis and Van Horn hardware-centric notion of capabilities, we would say copy rather than share, but I think those are two terms for the same thing.

I agree.

 

Delegation, in systems that supported it, took the form of some kind of transparent interposition objects. I don't recall at the moment whether CAP had such a concept, but many later systems do, including the KeyKOS family. The problem, broadly, being that the tail-chasing depth wants to be bounded and acyclic in such systems for a variety of reasons. I'm not clear whether the same concerns apply to systems built around swiss numbers. I'd count the KeyKOS family in that group, since philosophically that family can accurately be viewed as implementing a thin virtual machine layer over conventional hardware.

Delegation is different in object reference as capability (ORAC), opaque token as capability (OTAC), and certificates as capabilities (CC).  With ORAC you delegate by passing the object reference as an argument and use a caretaker to attenuate.  With OTAC, you delegate by exchanging your token for a different one that you then share/copy.  With CC, you create a new certificate representing the delegated permissions.

I agree that interposition gives you separate revocability tracking. I'm not sure whether responsibility tracking is accurate; it depends what we mean by "responsibility". If we mean something like logging for audit, mere interposition isn't good enough. We will soon find ourselves trying to invent an "invoked for" relation that crosses subsystem boundaries. Which can be very useful, but has proven damned hard to engineer well. Token exchange seems like a better model, but then the audit support needs to record both the exchanges (for later reconstruction) and the capability identity used to invoke the operation.

Horton is how you track responsibility in an ORAC system.  With OTAC, the party requesting the token exchange is responsible for keeping track of who it gave the new token to.  With CC, the certificate can contain sufficient information to assign responsibility.

Neither critique nor endorsement. Just stray thoughts.

But good ones.

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

[Alan Karp]

On Fri, Aug 14, 2026 at 2:20 AM John Carlson <yott...@gmail.com> wrote:

I’ve pretty much wondered how a Granovetter diagram is bootstrapped without arcs.   How do Alice, Bob, and Carol initially get introduced? 

Out of band.  You can't bootstrap someone into a graph without using an external mechanism.

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

[Alan Karp]

On Fri, Aug 14, 2026 at 3:58 AM John Carlson <yott...@gmail.com> wrote:

I’m just trying to understand authority, permission and meta-permission in terms of a graph.   Nodes and arcs, etc.   I have limited buffer space, but I did try to read section 9.2.

I don't think there's any such thing as a meta-permission in an object reference as capability system (ORAC).  You get the effect of meta-permissions out of permissions and behavior.  The caretaker is invoked with a permission; its behavior then uses its own permission.  Revoking with a caretaker is just changing its state, which doesn't sound very meta to me.

Things are very different with UCAN capability certificates (CC).  You can create a CC granting revoke permission on another CC.  That CC can revoked and its permission delegated.  To me, that's meta.

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