Delegation manifesto draft

[Pierre Thierry]

Hi everyone,

as I may have already hinted in a previous call, I wanted to write a
Delegation Manifesto. Here is my first draft and I'd be happy to get
feedback on it. I'm especially uncertain on the last section on
guidelines.


* Delegation manifesto
** TL;DR
In everyday life outside IT, whenever someone has the
responsibility or the possibility of doing anything, they can
always tell someone else "do this in my place, will you?". They
might decide or need to supervise them closely, they might check
from afar or after the fact that things are done properly, or they
might trust them blindly. They might delegate for a myriad of
reasons, but delegation has always been a critical part of project
management.

Every IT system should make it easier to do what was done without
IT, not make it harder or impossible. Therefore:

**Every IT system should always include, at the core of its
authorization system, a delegation mechanism.**

** Rationale
Today's online services are becoming more and more ubiquitous and,
sometimes, mandatory. But the way they handle authorization suffer
one critical problem with several consequences.

The problem is that when a user wants to delegate actions on their
account, they are usually forced to share their credentials. The
first consequence is that they cannot really limit delegation. They
cannot limit the scope of their delegation, because their delegate
has access to their entire account. And they cannot limit the
conditions of the delegation, because their delegate knows their
credentials. When the delegation has a short duration, they
sometimes can change their credentials temporarily, but that's a
difficult operation for many users and some systems could prohibit
changing credentials back and forth, forcing the user to memorize
new credentials each time they want to delegate safely. The second
consequence is that because their delegate uses their credentials,
there may be absolutely no trace in the system that distinguishes
actions taken by the user from actions taken by their
delegate, which can have legal ramifications.

It can present as an accessibility issue: there are many situations
in life, some of them permanent, where a person won't be able to do
some online activities themselves. With almost all existing
systems, people are forced to divulge their credential with their
caretaker, even if they wouldn't trust them beyond doing the
activity in a supervised setting. This exposes them to a lot of
abuse, including being unable to use the system anymore because the
credentials have been modified without their knowledge. Because
their credentials are used, any abusive action taken inside the
system by their caretaker are impossible to distinguish from an
action taken by the proper user, and that will often make any
recourse vastly more difficult. It's an issue with compounding
issues.

It can also present as a professional issue: a clinic get issued a
single set of credentials for each doctor, but the doctors need the
nurses to enter acts and prescriptions into the system, or the
nurses also have credentials but not the proper authorization to do
everything the doctors need them to do. Despite strict regulations
like HIPAA, doctors end up sharing their credentials for the whole
clinic to be able to operate properly. The act of sharing them
might get them in trouble by itself and if anything happens while
someone uses their account, they'll be in even bigger trouble. And
if ever there is an inquiry into what happened to a patient, the
sharing of credentials would make it a lot harder to get a clear
picture of who did what. Here also, like in many other cases, it's
an issue with compounding issues.

** What a delegation mechanism should look like
Delegation should be easy and it should be safe. One way to achieve
those two properties is to use designation:

- designation of specific resources
- designation of the delegate


This means that delegation should not consist of

- the input of access rules, which can be wrong in ways the user
doesn't see
- granting access that's been asked by the delegate, which can lead
the user to not realize what is part of the delegation


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

[Alan Karp]

A good summary.

There's one important case that you didn't mention, delegating to software running on your behalf in order to enforce POLA.  Just being able to do that would dramatically reduce the damage that a virus could do.

Another case is microservices.  Today, microservices that need to act on your behalf impersonate you, giving them all your permissions.  As a result, it's impractical to outsource them.  The analogy is to the essay "I, Pencil" by Leonard Read.  In effect, each company must make its own pencils, losing the advantages of specialization.

--------------
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 on the web visit https://groups.google.com/d/msgid/friam/Zwvws2CiTIm9gMTk%40hellcat.

[Pierre Thierry]

Scribit Alan Karp dies 14/10/2024 hora 09:35:

> There's one important case that you didn't mention, delegating to software
> running on your behalf in order to enforce POLA. Just being able to do
> that would dramatically reduce the damage that a virus could do.

I intended this manifesto to be about delegation between humans, but
it is indeed the same problem, with the same consequences (lack of
control, lack of auditability, possibilities of abuse).

> Another case is microservices. Today, microservices that need to act on
> your behalf impersonate you, giving them all your permissions. As a
> result, it's impractical to outsource them.

This is more directly relevant to my original intent, but once you add
that, it makes more sense to also add the case of software running on
my machine.

I'll try to add both and see how they fit.