An interesting capability use case

[Alan Karp]

I'm reviewing https://github.com/ngallo/dif-notes/blob/main/work-items/2025-11-25-did-based-trust-chain-concept.md, which presents a use case I don't think we've covered in our discussions.  It involves a break in the delegation chain.

Say that Alice sends a message via a broker, such as Kafka.  She doesn't know who will pick up the message but wants to delegate to whatever entity does.  She could delegate to the broker and have the broker delegate, but that's giving the broker permissions it doesn't need.

Have any of you implemented something like this use case?

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

[Mike Stay]

On Tue, Nov 25, 2025 at 11:19 AM Alan Karp <alan...@gmail.com> wrote:
>
> I'm reviewing https://github.com/ngallo/dif-notes/blob/main/work-items/2025-11-25-did-based-trust-chain-concept.md, which presents a use case I don't think we've covered in our discussions. It involves a break in the delegation chain.
>
> Say that Alice sends a message via a broker, such as Kafka. She doesn't know who will pick up the message but wants to delegate to whatever entity does. She could delegate to the broker and have the broker delegate, but that's giving the broker permissions it doesn't need.

If anyone can pick it up, it might be that the broker picks it up. So
in a sense she's already delegating to the broker.

I guess Alice could restrict that with some kind of rights
amplification pattern where she has delegated an unsealer to some set
of potential receivers not including the broker, and only these can
open her message to get the authority.

>
> Have any of you implemented something like this use case?
>
> --------------
> Alan Karp
>

> --
> You received this message because you are subscribed to the Google Groups "friam" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z2%3D_Hs99sMA57%3DXcy65wsGgNxhR3bxW__c%3Dx7BD_vyMfA%40mail.gmail.com.



--
Mike Stay - meta...@gmail.com
https://math.ucr.edu/~mike
https://reperiendi.wordpress.com

[Alan Karp]

On Tue, Nov 25, 2025 at 11:20 AM Mike Stay <meta...@gmail.com> wrote:

On Tue, Nov 25, 2025 at 11:19 AM Alan Karp <alan...@gmail.com> wrote:
> Say that Alice sends a message via a broker, such as Kafka.  She doesn't know who will pick up the message but wants to delegate to whatever entity does.  She could delegate to the broker and have the broker delegate, but that's giving the broker permissions it doesn't need.

If anyone can pick it up, it might be that the broker picks it up.  So
in a sense she's already delegating to the broker.

You only want legitimate targets to be able to use the capability in the message.  The broker isn't in that group. 

I guess Alice could restrict that with some kind of rights
amplification pattern where she has delegated an unsealer to some set
of potential receivers not including the broker, and only these can
open her message to get the authority.

I like that as a solution.  Another is to not include the capability in the message but supply an end point to ask for it.  One consideration is providing an audit trail.

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

[Tristan Slominski]

> Another is to not include the capability in the message but supply an end point to ask for it.

To me, this, and any other solution requiring bypassing the broker, feels like it defeats the point of having a message broker in the first place. If you're putting a Kafka broker between systems, you don't want them interacting directly.

--
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/CANpA1Z2Q-ReB38MVq8fvLAhA81CnWByZoNGq-1bigXR%2BCu3tHg%40mail.gmail.com.

[Alan Karp]

On Tue, Nov 25, 2025 at 2:26 PM Tristan Slominski <tristan....@gmail.com> wrote:

> Another is to not include the capability in the message but supply an end point to ask for it.

To me, this, and any other solution requiring bypassing the broker, feels like it defeats the point of having a message broker in the first place. If you're putting a Kafka broker between systems, you don't want them interacting directly.

 The nature of the messages is different.  You use a broker when you don't have a specific target.  You use direct messaging when you do.

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

[Dale Schumacher]

How do you manage the in-group of potentially-valid recipients? If, for example, all the valid recipients have a capability to a "claim service" that the broker does not have, then all the broker needs to communicate to the chosen recipient is a "claim number". The recipient submits the claim number to the claim service and gets back the capability for that interaction. I would consider this a form of "rights amplification".

A weaker, but similar, pattern is a one-time-use capability. If the broker, or any other intermediary, "uses" the capability, it becomes worthless, defeating the purpose of the broker. The intent is that the broker passes the one-time-use capability to the chosen recipient, and they use it to engage with the originator (perhaps supplying a transaction-specific endpoint-capability for further interaction). This pattern obviously has more risk, but does not require knowing the "legitimate" set in advance.

--

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/CANpA1Z1ezciR66BCT0F%3D-omRJ2iF1gG%3DG1qcfvaqYvQdA%2BqwzQ%40mail.gmail.com.

[Alan Karp]

On Wed, Nov 26, 2025 at 10:26 AM Dale Schumacher <dale.sc...@gmail.com> wrote:

How do you manage the in-group of potentially-valid recipients? If, for example, all the valid recipients have a capability to a "claim service" that the broker does not have, then all the broker needs to communicate to the chosen recipient is a "claim number". The recipient submits the claim number to the claim service and gets back the capability for that interaction. I would consider this a form of "rights amplification".

Isn't that the next level of detail of my "supply an end point to ask for it" suggestion?

Another form of rights combination (The term rights amplification confuses people.), useful when you know the set of authorized recipients ahead of time, is to encrypt the capability in the message.   The decryption key can then be encrypted with the public keys of the authorized recipients.  

The claim service is better when you only want a single recipient to get the capability.  The encryption approach is better when you don't care about that.
 

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

[Dale Schumacher]

On Wed, Nov 26, 2025 at 11:43 AM Alan Karp <alan...@gmail.com> wrote:

Isn't that the next level of detail of my "supply an end point to ask for it" suggestion?

Yes. That's my point! The requirement that you know the "legitimate" set in advance doesn't fit the "broker" use-case. That's why I suggested the alternative of a "one-time-use" capability (which you didn't quote).

The purpose of a broker, auctioneer, or escrow agent is to act as a "trusted third party", usually connecting strangers. They often have excess authority, but are trusted not to abuse it. If I already have a trust-relationship with a group of "legitimate" vendors, I don't need the broker.

[Jonathan S. Shapiro]

On Wed, Nov 26, 2025 at 11:25 AM Dale Schumacher <dale.sc...@gmail.com> wrote:

Yes. That's my point! The requirement that you know the "legitimate" set in advance doesn't fit the "broker" use-case. That's why I suggested the alternative of a "one-time-use" capability (which you didn't quote).

Just so I'm clear: by "one time use" you mean a capability that is revoked as soon as it is successfully invoked.

By "successfully", I mean that the invocation was delivered to the recipient. In Coyotos, this would not include an attempt to invoke that (say) incurred a page fault or some other exception that causes it to be retried.

Is this what you have in mind?

Jonathan

[Matt Rice]

That is how I interpreted it, in channel terminology at least in the
systems I'm familiar with (in both concurrent ML and rust these tend
to be termed
"one-shot" channels which I find clear terminology).

I suppose there is something interesting regarding implementation as
an sealer/unsealer pair.
One could implement this with a sealer/unsealer pair like the one
given in emily on page 2
(I don't know if these have a name, lambda sealers?)
http://www.skyhunter.com/marcs/emily.pdf

as a mutation within the `filledBox` on unseal, or wrapping the sealed
box in a revocation.

However I've written some implementations where this doesn't work,
particularly because they trademark (in the sense of morris) the
unsealer and the sealed box, (so the sealer returns a trademarked box,
and the makeSealerUnsealerPair function returns a trademarked
unsealer)
indicating that the filled box is not the box returned by the seal function.

For these one would either need a separate kind of sealer/unsealer
pair for one-shot, or perhaps some kind of optional 'on-unseal'
callback
which one can use to trigger the revocation, as an extension of the
typical mechanism.

Just observations, I'm not sure I have much of a point.

[Alan Karp]

On Wed, Nov 26, 2025 at 11:25 AM Dale Schumacher <dale.sc...@gmail.com> wrote:

The purpose of a broker, auctioneer, or escrow agent is to act as a "trusted third party", usually connecting strangers. They often have excess authority, but are trusted not to abuse it. If I already have a trust-relationship with a group of "legitimate" vendors, I don't need the broker.

I'm sorry.  I should have made it clear that I'm talking about a message broker, such as Kafkam, which is generally not trusted with application permissions.

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

[Alan Karp]

On Wed, Nov 26, 2025 at 1:44 PM Matt Rice <rat...@gmail.com> wrote:

I suppose there is something interesting regarding implementation as
an sealer/unsealer pair.

We're talking about a distributed system, so the sealer/unsealer can be encryption/decryption keys. 

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

[Dale Schumacher]

On Wed, Nov 26, 2025 at 1:14 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Just so I'm clear: by "one time use" you mean a capability that is revoked as soon as it is successfully invoked.

By "successfully", I mean that the invocation was delivered to the recipient. In Coyotos, this would not include an attempt to invoke that (say) incurred a page fault or some other exception that causes it to be retried.

Is this what you have in mind?

I believe the phrase "token exchange" is used for the one-time-use pattern I was suggesting. The granting system produces a capability that receives a message containing a client/customer capability. It replies with a capability that can be used for further interaction. If messaging is considered "reliable", the original grant can immediately invalidate itself (ignoring or failing on subsequent messages), as further communication occurs exclusively over the new capability. If messaging is not reliable, the original grant can remember the initial client/customer capability and repeat its reply if given the same request, ignoring or failing on any other request. In either case, the client/customer knows they are the only one given the new capability, and thus access to the secured services.