TL;DR for @maidsafe people Please watch the video at the end about capability based authorization and delegation (and about the abysmal state of the authorization and access schemes currently in use everywhere). I’m shamelessly begging you guys to consider going down this direction about authorization because this alone would put the Safe Network decades ahead of all the others. There’s no need to repeat the failures of the past.
I’ve brought it up before but I can’t stop myself from bringing it up again. Why not just use something tried and tested, like capability based authentication? Rolling authentication schemes from scratch is almost as bad as rolling your own encryption.
After verifying the permissions through a GUI similar to what we’re shown when we install an app on a phone, the authenticator would just create a restricted derivative of the certificate it already has: restrict it by folder, add a time limit, remove write access, etc. (The authenticator’s certificate may already be a restricted version of the master key, for example when I don’t want my relatively insecure phone to access my more sensitive data.) The new certificate is then handed over to the app. At this point, the authenticator’s job is finished.
There’s no need to keep track of the certificates and there’s no need to store them on the network because they are standalone just like your passport in real life. Apps would just attach the relevant certificate to each request and anybody (vaults, sections, whomever concerned) could verify if the request is valid.
You may have noticed that there’s no talking about “fixed set of permissions” or similarly insecure, unreliable, and inflexible blasphemies. The root cert for an account (which may be just the document owner’s private key) has all access, and each derivative certificates may have a number of caveats attached to restrict its scope.
Please also note that we already solved the question of not just authorization but also delegation (something ACLs, for example, can’t do at all).
Capabilities fall right into place here as well. Authentication (identity) is irrelevant for capabilities because we don’t have to care who you are as long as you can show us a certificate that gives access to perform the operation on the thing. So, each drive’s being a new “account” is not confusing because an account is little more than a private key that encodes ownership.
An implementation for the the above are Macaroons, with a Rust library, and I have written about them before here: Bearer credentials with caveats for distributed authorization
A talk about them from the 2017 Rust Bay Area Meetup:
Slides for the talk: