Question about a capability pattern

[Alan Karp]

It is not unusual in an enterprise to have a chain of delegations that include people who may change jobs at any time.  For example, VP Alice delegates to department manager Bob who delegates to some worker bees.  You'll want to revoke Bob's capabilities if he leaves the company, but you'll also have to revoke all delegations that Bob made in case some were to a sock puppet.  However, that can disrupt operations of the department.

A proposed way around that is to delegate Bob's permissions to a proxy and give Bob a capability to the proxy.  When Bob leaves, revoke his access to the proxy.  Problem solved! Or is it?  While he's still the manager, Bob must be able to tell the proxy to delegate to members of the department.  What is to prevent some of those delegations being to a sock puppet?  Perhaps I misunderstood the proposal.

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

[Matt Rice]

On Mon, Dec 26, 2022 at 7:08 PM Alan Karp <alan...@gmail.com> wrote:
>
> It is not unusual in an enterprise to have a chain of delegations that include people who may change jobs at any time. For example, VP Alice delegates to department manager Bob who delegates to some worker bees. You'll want to revoke Bob's capabilities if he leaves the company, but you'll also have to revoke all delegations that Bob made in case some were to a sock puppet. However, that can disrupt operations of the department.
>
> A proposed way around that is to delegate Bob's permissions to a proxy and give Bob a capability to the proxy. When Bob leaves, revoke his access to the proxy. Problem solved! Or is it? While he's still the manager, Bob must be able to tell the proxy to delegate to members of the department. What is to prevent some of those delegations being to a sock puppet? Perhaps I misunderstood the proposal.
>

There is a somewhat different scenario where Alice/Bob are friends,
and members of a group, Alice has delegated some capability which can
be used by her friends & the group,
when Alice leaves the group, she wishes to revoke access to this
capability, to the group. Bob could have obtained the capability
through the group, and may need to switch some capabilities
from using capabilities available to the group with capabilities
available to Alice's friends. Usually Alice can give a capability to
her friends that translates a revoked group capability into a friend
equivalent one (for lack of a better term revocation withdrawl).
As for how this applies to your scenario, It seems really dependant
upon Past-bob's ability to manipulate the worker bee roster, if you
can't grant a new Post-Bob capability which did not exist in the Bob
era to a group you're certain excludes Bob you'd seem to have lost the
war.

At least, that is my not too deeply thought out initial impressions of
the situation...

[Raoul Duke]

one thing i wonder about is how the long term ui ux of all this works. i feel like it would at least potentially lead to users drowning in caps. and inevitably thered be more than one cap system if the way "sso" has been actually done in the real world at fang level companies is any indication. 

[Bakul Shah]

Wouldn’t a role based system handle this? The capabilities Bob has access to are a function of the role(s) he plays in the enterprise. If Bob leaves, others will typically have to take over his roles. So in a sense it is Bob who is the proxy for the roles he plays! Similarly anything he delegates in his role would be not to individuals but the roles they play. Now if a sockpuppet is given a legit role, that is a hiring issue! Typically assigning a role would be a different capability. This level of indirection can also allow others to fill in a role temporarily if Bob is not available or too busy.

Note that a role disappearing or morphing into other roles would be a much more deliberate decision and can be decoupled from people leaving.

On Dec 26, 2022, at 11:08 AM, Alan Karp <alan...@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 on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z33OAeb-JB1b6NUgOrD4402UxYjzX3rmHFebWaQeyA19g%40mail.gmail.com.

[Pierre Thierry]

Scribit Alan Karp dies 26/12/2022 hora 11:08:

> What is to prevent some of those delegations being to a sock puppet?

And if we simply revoke all delegations made by Bob, it means every
"worker bee" in his former service now needs to reacquire
capabilities.

If they can do that easily, what would prevent the sock puppet to do
the same?.

So isn't the real question more about how to prevent Bob from creating
a sock puppet?

If there is a service that can authenticate genuine agents of the
system and extract their capabilities from Bob's membrane, you can
disable his membrane when he leaves the service/company.

So whenever Bob wants to delegate a capability, he just creates a
caretaker object that he gives access to a third party, like Zebra
Copy (or hist sock puppet). By default, the caretaker is inside Bob's
membrane. If Bob leaves the service, his membrane is revoked and Zebra
doesn't have access anymore (and neither does the sock puppet).

But if the legal department verifies that Zebra Copy is a genuine
company that provides services, it gets its own membrane and all
caretakers are migrated there. Ideally, the revocation capabilities to
those caretakers should remain in a manager shell for the service
after Bob's access as a manager is disabled, for the next manager to
get. (or for other managers to use even while Bob is still there)

As the sock puppet won't get verified by HR or legal, it won't get its
own membrane.

Tentatively,
Pierre Thierry
--
pie...@nothos.net
OpenPGP 0xD9D50D8A