(This document is not part of the ChiFS protocol specification. It describes a possible future extension of ChiFS. See the protocol overview for context.)
With the current model, each Share is public and is sharing all of its files with anyone who might be interested in them. A Share announces itself to one or more Hubs, but those Hubs are not necessarily the only ones indexing that particular Share. In fact, it would be relatively trivial for a Hub to fully clone another Hub: Just grab a list of all Shares from the Hub and index those. A Share has no way to restrict which Hubs are allowed to index it and/or who is allowed to download from it.
Reasons for wanting to restrict access to Hubs and Shares could be:
- A Share only has limited bandwidth and wants that bandwidth to be used by people that they know or people who benefit the most from the shared files.
- A minority group or fandom wishes to share files amongst themselves without attracting outside attention. E.g. Furries, Bronies, etc.
- The shared files may contain sensitive information that should not leak outside of a small community. E.g. security research, whistleblowers.
I consider this out of scope for the early stages of ChiFS, but support for private communities can be considered if there's demand for it. Here's a rough idea of how this could work.
Precondition: Users have a way to register and authenticate to a Hub. Plain old user/password authentication would suffice for this model, but stronger schemes could also be supported.
The Hub generates a public/private key pair and makes sure that the public key is available to all Shares indexed by the Hub. Users that wish to download a file from a Share first obtain a token signed by the Hub's private key, which they can then use to authenticate themselves to a Share. The Share can verify the validity of the User's token by checking it against the public key of the Hub.
A User's token should be short-lived, anywhere between 5 minutes and 24 hours should suffice, depending on the Hub's policies. A short expiration time ensures that Users will have to regularly re-authenticate themselves to the Hub and limits the amount of time that a user can access Shares after their authorization has been revoked. Short-lived tokens also avoid the need to implement systems like CRL or OCSP.
Tokens could be restricted in various ways:
- A general token to allow a user to download anything from any Share. This is just a verification that the user is registered with the Hub and is authorized to download things.
- A token to only download from a particular Share; This way the Hub can restrict users to only access particular Shares.
- A token to only download a single file. For extra fine-grained access control.