A thought on principals

[Jonathan S. Shapiro]

Alan made a comment on LinkedIn today about recording principal ID for audit purposes, which prompted a thought that I'm fairly sure has come up before.

When someone authenticates in a capability-based system, there exists somewhere a "bag" of capabilities that are reachable by virtue of having authenticated. The total authority of that user is a transitive semi-reflexive closure of capabilities wieldable (directly or indirectly) from that bag. This total authority changes dynamically as capabilities are added (e.g. by second party grants) or dropped.

If we view the system this way, then there is a sense in which that initial bag is the principal, and we could have a principal id for audit purposes simply by labeling this bag and ensuring that each user has an independent bag (which we want in any case).

This addresses the "what is a principal" question, but intentionally does not attempt to address the "and how do we stop them from sharing authority in ways we don't want".

What am I missing here? Is this just a brain fart?

Jonathan

[Ben Laurie]

The point of audit trails is to, y'know, audit - if I want to know WTF that $1M went and who did it, telling me "it was this bag of caps" is not really helping my audit.

--
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%3D3QN1c52%3DcvPZFDkN_0mB%3D1cOGgVXOzUNbzCeTKYBGcQvEA%40mail.gmail.com.

[Matt Rice]

I think in shap's message the important thing for auditing is not "it
was this bag of caps", but the unique label assigned to each bag of
caps,
independent of each user. e.g. the "and we could have a principal id

for audit purposes simply by labeling this bag and ensuring that each

user has an independent bag" part
In theory that could give auditors more information than just a
principle, because it combines both the principal, and a subset of the
principles capabilities contained in the bag
or somethingesque.

> To view this discussion visit https://groups.google.com/d/msgid/friam/CABrd9SQ-E%3DCeeB-pCNZeqRSW8Mx0LF8Z17oi3OYN8uY5GvZ_bA%40mail.gmail.com.

[Alan Karp]

On Thu, Sep 18, 2025 at 1:01 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Alan made a comment on LinkedIn today about recording principal ID for audit purposes, which prompted a thought that I'm fairly sure has come up before.

Actually, all you need is an identifier meaningful to the delegator, but that's more detail than appropriate for that discussion.

When someone authenticates in a capability-based system, there exists somewhere a "bag" of capabilities that are reachable by virtue of having authenticated. The total authority of that user is a transitive semi-reflexive closure of capabilities wieldable (directly or indirectly) from that bag. This total authority changes dynamically as capabilities are added (e.g. by second party grants) or dropped.

That bag is your powerbox.  Note that the user's total authority also depends on changes in the behavior of the invoked objects.

If we view the system this way, then there is a sense in which that initial bag is the principal, and we could have a principal id for audit purposes simply by labeling this bag and ensuring that each user has an independent bag (which we want in any case).

The principal is responsible for that initial bag, but the bag isn't the principal if authentication credentials can be shared.  In other words, you can't know who did it; you can only know who to hold responsible for it being done.

This addresses the "what is a principal" question, but intentionally does not attempt to address the "and how do we stop them from sharing authority in ways we don't want".

Because you can't.  If you block delegation, people share credentials.  The best you can do is warn them that a delegation violates policy, which is what we did with Voluntary Oblivious Compliance. 

What am I missing here? Is this just a brain fart?

These are important questions.   

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

[Ben Laurie]

OK, I misunderstood the original intent.

But Alan gets to the point: ultimately, some computer does a thing and we can't definitely know who made it do that thing.

This is not what auditors want to hear, which is kinda the problem. :-)

--

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/CANpA1Z0xOZ-8hXZ%3DeqF_stP66eQesP6%2B9u9w_d%3DHJ7tJ3HyuOQ%40mail.gmail.com.

[Alan Karp]

On Thu, Sep 18, 2025 at 1:40 PM 'Ben Laurie' via friam <fr...@googlegroups.com> wrote:

OK, I misunderstood the original intent.

But Alan gets to the point: ultimately, some computer does a thing and we can't definitely know who made it do that thing.

This is not what auditors want to hear, which is kinda the problem. :-)

The auditors just want someone to blame.  That's you if you shared your credentials.

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

[Raoul Duke]

a flip side from the auditor viewpoint is:

i don't want to be blamed for something done with credentials stolen from me. 

[Raoul Duke]

so let them delegate but only after they logged in to their powerbox using RBAC. 

if there's enough important things in the wallet, i won't take the shortcut of handing over the whole thing vs. logging in and sharing the necessary subset. 

[Alan Karp]

On Thu, Sep 18, 2025 at 2:14 PM Raoul Duke <rao...@gmail.com> wrote:

a flip side from the auditor viewpoint is:

i don't want to be blamed for something done with credentials stolen from me. 

Shouldn't you if it's because you clicked on that phishing link? 

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

[Raoul Duke]

There's a lot of complexity therein. (And that is why i believe digital contracts are worse than human contracts. Too much nuance is lost and disallowed by the former.) I am sure even some hardened security pentester professionals have effed up on this kind of thing. There are SO many factors involved in why blaming the user is not in my mind 100% humane or even logical. It ain't just phishing, and even phishing can be a complex issue re: blame. Especially with AI entering the chat.

At least for non-corporate Regular Joe Schmoe user cases.

--

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/CANpA1Z20fHBm8uR%2B%3D%3DtNHUs%2BF8S-cxQGcG8Xt49gS5bp6EQv8A%40mail.gmail.com.

[Mark S. Miller]

Horton? 

https://www.youtube.com/watch?v=NAfjEnu6R2g&list=PLzDw4TTug5O0ywHrOz4VevVTYr6Kj_KtW&index=25

To view this discussion visit https://groups.google.com/d/msgid/friam/CAJ7XQb6zM6b48_3Zk8%3DKFg8pmooScNvNtFG%3DuR7Qh%3D0Hcamc0Q%40mail.gmail.com.

[Raoul Duke]

as long as i have a piece of paper and a pencil with which to write down what my password was, i'm good. 

[Alan Karp]

Horton was designed for a system with object references as capabilities.  Assigning responsibility is more direct if you're using certificates as capabilities. 

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

To view this discussion visit https://groups.google.com/d/msgid/friam/CAK-_AD5rXghz%3DjJxnDfKE2vP8Ff%3Di1F8o8h0Xe69rEPQePc-bg%40mail.gmail.com.

[Mark S. Miller]

On Thu, Sep 18, 2025 at 3:45 PM Alan Karp <alan...@gmail.com> wrote:

Horton was designed for a system with object references as capabilities.  Assigning responsibility is more direct if you're using certificates as capabilities. 

Horton layers on top of any ocap system. If the ocap system is built from certificates, Horton still works with all of its pleasant properties, including three-way responsibility for misbehavior. If you go under the ocap level of abstraction and assign responsibilities based on other information in the certs, you are probably breaking the sound responsibility assignment logic of Horton.

So give me an example with a different outcome than Horton that is not clearly worse.

 

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

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Thu, Sep 18, 2025 at 4:05 PM Mark S. Miller <eri...@gmail.com> wrote:

On Thu, Sep 18, 2025 at 3:45 PM Alan Karp <alan...@gmail.com> wrote:

Horton was designed for a system with object references as capabilities.  Assigning responsibility is more direct if you're using certificates as capabilities. 

Horton layers on top of any ocap system. If the ocap system is built from certificates, Horton still works with all of its pleasant properties, including three-way responsibility for misbehavior.

Sorry, that was too obscure.

1. Callee might misbehave.

2. Caller might misbehave. I believe this is the only one most people think about.

3. Introducer held responsible by caller for callee misbehavior, or vice versa.

This is obviously recursive through introduction chains. And intermingled since introduction itself involves a caller and callee.

--

  Cheers,
  --MarkM

[Alan Karp]

Each certificate capability should include an identifier of the delegate that is meaningful to the delegator.  Each certificate should be issued to a public key unique to that certificate that the delegate can use as an identifier of the delegator.

Say that Alice creates Carol.  Alice creates a root certificate that carries an identifier she recognizes as denoting herself.  When she delegates to Bob, she includes in that certificate an identifier that she associates with him and her root certificate as proof of the right to delegate.  Bob does the same when he delegates to Dave.  When Dave invokes Carol, a verifier controlled by Alice walks the delegation chain.  If Dave does something bad, Alice knows to hold Bob responsible.  It's then up to Bob to hold Dave responsible.  If Carol does something bad, Dave informs Bob who informs Alice.  In this last case, the required information is encoded as the public key the certificate is issued to.

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

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

[Mark S. Miller]

This is certainly close to the Horton logic, if not identical. I don't have the bandwidth right now to look for differences. Especially security non-equivalences. Do any of you know of any? What about things you're suspicious of, to help focus other efforts? Thanks.

To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z3xeF2owPE1KY4jr6THPt2cv%3DJMaAuJYXg%2B7O5tiSTRrA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

One difference is auditability.  Of the three things in your list,

1. Callee might misbehave.

2. Caller might misbehave. I believe this is the only one most people think about.

3. Introducer held responsible by caller for callee misbehavior, or vice versa.

The information for the first two is in the certificate.  In addition, there is little risk if the certificate is exposed.  

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

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

[Mark S. Miller]

By "auditability", do you mean "non-repudiation"? Good point. Horton only has non-repudiation if the underlying ocap system does, at least for Horton messages. So I think non-repudiation is orthogonal to Horton. The question then becomes: 

Is your system security-equivalent to Horton running on a certificate-based ocap system supporting non-repudiation? I don't know, but I don't immediately see any inequivalence.

[Alan Karp]

I think auditability and non-repudiation are different.  Non-repudiation is usually between two parties, e.g., Alice can prove to a judge that Bob is responsible for some action.  Audit is usually carried out by a third party that monitors many interacting parties and may not provide non-reputation.  For example, the audit may show an interaction occurred but not the details for privacy reasons.

Certificate capabilities were not invented by me (See SPKI.), but they and Horton have similar goals.  It wouldn't surprise me if they turn out to be equivalent.

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

On Mon, Sep 22, 2025 at 1:26 PM 'Mark S. Miller' via friam <fr...@googlegroups.com> wrote:

By "auditability", do you mean "non-repudiation"? Good point. Horton only has non-repudiation if the underlying ocap system does, at least for Horton messages. So I think non-repudiation is orthogonal to Horton. The question then becomes: 

Is your system security-equivalent to Horton running on a certificate-based ocap system supporting non-repudiation? I don't know, but I don't immediately see any inequivalence.

--
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/CAK-_AD728FWJoXPdqtrM4F7nxLe%2BO%2B%3DGTwjAfkpys_rv_k3LYw%40mail.gmail.com.

[Mark S. Miller]

If the auditor is willing to believe each party's repudiatable records, then Horton already supports auditing.

To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z103KWdxhT9U55eKrqJ%3Dsn0qfj5TQ%2BmhLjQtdLBhACCAQ%40mail.gmail.com.

--

  Cheers,
  --MarkM