Permissions

[criadoperez]

Introduction

This board will be used to discuss our improvement of the existing access-control system of the GAIA Storage System.
Right now the current access-control system is defined as such:

"Access control in a gaia storage hub is performed on a per-address basis. Writes to URLs /store/

/ are only allowed if the writer can demonstrate that they control that address. This is achieved via an authentication token, which is a message signed by the private-key associated with that address. The message itself is a challenge-text, returned via the /hub_info/ endpoint.".

We want to extend the system in a way, that the following actions will be possible:
- User A can grant User B access to specific files, and revoke access
- User C can upload data on behalf of User A, but cannot read them

At the moment we are at the early early stages of this proposition, therefore we are still figuring technical issues out and brainstorming different approaches

Find our current progress / idea under:
https://www.notion.so/toggglegaia/Access-Control-2a9967a9d506445ebe1706e37deb707d

[jcnelson]

Hi, I'm Jude. I was wondering if it might be possible to add the ability to revoke a specific address's authentication token and association token? Right now, we can revoke everything via /revoke-all, but that's pretty coarse-grained.

The use-case I'm imagining is one that would allow us to create an "inbox" abstraction in applications. To do this, Alice gives Bob permission to write a single index file that contains URLs to files he wants to "send" Alice. Alice does this by creating Bob a Gaia authentication token signed by her, with an association token with Bob's public key, with a single putFile scope. Then, Bob can post data to this scope's path to inform Alice when he has new data available for her to consume.

But what if Alice wants to revoke Bob's ability to post new data? Right now, she has to revoke everything via /revoke-all. But maybe this could be done on a per-address basis so she doesn't invalidate any other authentication tokens she has given out?

[bjorger]

Our approach is user based.
Alice does not have to give a specific token to Bob, for Bob to access the files of alice. If Alice wants to grant Bob access, Alice simply "whitelists" Bob.

right now we are still in a concept phase, where we elaborate different approaches. More informations will come in the next weeks :)

[jcnelson]

If Alice wants to grant Bob access, Alice simply "whitelists" Bob.

Please keep in mind that there's a layer or two of indirection here that make such an implementation very difficult.

First, a Gaia principal corresponds to an application public/private key pair, which itself is a hardened child key of the key pair that owns the user's BNS name. If Alice wanted to whitelist Bob, then Alice would need to somehow learn all of Bob's application public key addresses. While this is possible that the Gaia hub could maintain a reverse index that maps all existing application public keys to their BNS names, doing so would be very expensive. Moreover, the list of a BNS name owner's application public keys is stored off-chain in a Gaia hub of the user's choosing, which makes it hard to maintain a consistent index. For example, a slow, buggy, or unresponsive hub (or backend storage provider) could refuse to serve this indexing service a profile at all. Worse yet, it could serve different versions of the same profile. This would manifest for Bob as his writes to Alice's hub getting NACK'ed in unpredictable ways.

Second, applications are not obliged to use the application public key. This means that a naive indexing scheme isn't even guaranteed to work correctly if Bob is using such an application -- Alice's hub would somehow need to figure out exactly which public key from Bob to use to authorize him in order to express the policy "Bob can write to Alice's hub."

The advantage of the current authentication token system is that neither of these problems need to be addressed. Specifically, there is no need to link Bob's application public key to his BNS name in the current system. If Alice's authenticator app could be prompted by the application to ask Alice if she wants to create a Gaia authentication token for Bob with the given limited permissions, then the token itself contains all of the state needed to authenticate Bob's writes (and moreover, this system is easily extended by adding more scopes and domains).

[jcnelson]

I've been digging into this more.

Right now, there's no way for Alice to create Bob an authentication token that will let him write to only a specific set of files. Specifically, the scopes field belongs to the "outer" authentication token, which Bob needs to sign with his private key (Alice needs to sign the association token to link Bob's public key to her BNS name's public key, whose address is whitelisted). But, this could easily be added: all you need to do is add a scopes field to the association token as well, and check both tokens' scopes when authenticating a write. Then, Alice sets the scopes for Bob when she creates him an association token, and Bob's app can impose additional constraints on itself when it uses it to generate the authentication token.

[dantrevino]

Is there an easy way to extend this to allow group access to files?

[wileyj]

easy? yes. scalable - i don't think so right now without an extra service running alongside gaia.
the easiest way i can think of to grant group access would be create a namespace with all the BNS ids that should be in a group - then using @jcnelson comment, you could allow anyone in a namespace access to a file.

[wileyj]

ping @dantrevino and @aulneau