Delegating permissions to third parties

[vishakh]

Hello,

We are trying to figure out whether we can delegate permissions the way we want to. Generally speaking, this is what we want to accomplish:

1. Actor1 saves encrypted secrets on Nillion and gives full permissions to themselves and Actor2
2. Actor2 later gives execute permissions to Actor3 (and others) and later removes it
3. Actor3 runs a program against the secrets while they have permissions

In our case, Actor1 is the user, Actor2 is us and Actor3 is a third party we authorize to compute on user data.

From looking at the docs and examples, we see that (1) is indeed possible. However, for (2) it's unclear whether Actor2 can modify the permissions without resetting them in such a way that they Actor1 loses one or all permissions and other actors lose their existing compute permissions.

Is there a way to accomplish what we want? If not, Actor3 and others will have to request Actor2 to perform computations on their behalf. This centralizes our protocol more and moves the overall app more off-network.

To get a general sense of what we are trying to do, please look at https://github.com/Cryptonomic/MonadicDNA/blob/e1f71f4f7d28b5dae183a43f94b7f3bf4fa59453/services/nillion-interactor/E2E_Nillion_Test.ipynb.

Thanks!

[Davetbutler]

Hey @vishakh. I am pretty sure this is possible using the update_permissions function. You can see an example of this here. In this case Actor1 would have to give Actor2 "update permissions" permissions (if that makes sense).

It is a bit of a mind twister, but I hope this makes sense. Let me know how you get on.

[vishakh]

It's not clear to me that Actor2 would be able to use update_permissions without changing Actor1's permissions. It will end up giving itself default_for_user which was previously done by Actor1. Furthermore, there seems to be no way to enumerate the existing permissions all other actors have on the secret so Actor2 cannot replicate them verbatim.

[Davetbutler]

Hey. Sorry for the delay. I have looked into this a bit more, and yes, I think you are right. default_for_user effectively wipes all other permissions so every time you do that you are essentially changing the owner of the secret, which does not help in this case.

We are actually thinking through permissions right now from a product POV, so this is really helpful input.

In your case, Actor 1 and Actor 2 end up with essentially the same permissions. Is it important that Actor 1 can still remove Actor 2's full permissions? i.e. Actor 1 remains the "super owner" of the secret.

[vishakh]

Yes, absolutely.

Users of our app need to be in ultimate control of their data. They need to have at all times sufficient permissions to revoke compute and other permissions from all other parties.

We (Monadic) need to be able to dynamically add or remove compute permissions for third parties.

This allows a UX where users can visit a third party service, be redirected to Monadic where they authorize a third party to operate on their data and then be redirected back. Later on, users can look at a list of all authorizations on their dashboard and remove the third parties they are no longer comfortable with.

The same goes for institutions who store their data on Nillion via our platform and want to control which third parties can run analyses on their data.

[Davetbutler]

Thanks for the response. We are currently looking at iterating on our permissions system, and this input is really useful. We are certainly aiming to unlock such a use case. I'll keep you in the loop.