Token scoping

[dchoi27]

Issues related to how tokens are scoped (permissions, how users interact with multiple tokens, etc.).

[dchoi27]

@alanshaw know you had some thoughts related to token permissions, feel free to make a new issue and add to this epic!

[alanshaw]

Problem

At the moment, developers building web applications are likely to bundle a Web3.Storage token together with the app. This allows users to interact directly with the Web3.Storage service from their browser. However it has some issues:

• Token is openly available in the application source code. Anyone can take the token and use it to upload their own content.
• The token when used to list uploads does so on an account level so you see uploads that were created using other tokens.

The alternatives to bundling a token currently are:

1. Applications ask users to sign up at web3.storage and obtain a token for use. This is terrible UX.
2. Application developers create their own API and proxy uploads from their users. This is a lot of work and means that content is funneled through a centralized point that is maybe not as well prepared for the amount of traffic it may receive.

Proposal: Token Scoping and Token Management API

Developers simply have to implement an API in their app that creates "user" scoped tokens. It uses an "admin" scoped token to do this. The "user" token may be stored in local storage for use by the web app. It is a centralized component of the user's app, but avoids token bundling, asking the user for a token and allows uploads listings that are filtered to the token that performed the upload.

This feature has been requested by users in: #371

Scopes

Public permissions are implied.

1. Admin
   • Create user token
   • Delete user token
   • List user tokens
   • Upload
   • List all uploads
   • Delete any upload
2. User
   • Upload
   • List owned uploads (refs Allow listing files from a specific token rather than a whole account #300)
   • Delete owned upload
3. Legacy (existing tokens already created)
   • Upload
   • List all uploads
   • Delete owned upload

Work Involved

• The list uploads endpoint should fetch uploads belonging to a token if it has the "user" scope, else everything for the account
• The delete endpoint should allow deletion of any content from a token with "admin" scope
• The create token endpoint should...
  • Accept a scope param that allows magic.link tokens to create "admin" or "user" scoped tokens
  • Allow a token with "admin" scope to create a "user" scoped token
• The delete token endpoint should allow a token with "admin" scope to delete (revoke) a "user" scoped token
• The list tokens endpoint should allow a token with "admin" scope to list all "user" scoped tokens
• UI work for selecting scope of token to create from the website and showing scopes in token list

Alternative

Leverage magic.link's blockchain auth and allow authentication using metamask, allowing an account and token to be created on Web3.Storage entirely from the browser.

This flow requires users to install the metamask plugin which is a hurdle and may not be preferable to all dapp developers.

We should do this alternative also though!

[atopal]

My hunch is that the issue is having to run a back-end service at all. Browser only apps would still have to ship with the admin token or ask users to create a web3.storage account. That said, I'd say let's go for it, because the current practice is indeed problematic, even for those who want to run their own back-end as a service, and this proposals solves a problem for them.

[dchoi27]

How problematic is it for the developer to run a back-end service in-and-of-itself? Ideally they don't have to, but is most the value captured by allowing the user to directly send data to web3.storage rather than the back-end service touching the data? We should test this.

[mikeal]

Another alternative to consider is to allow our users to give us their magic link application token to use instead of ours so that we authenticate their users in out backend. Then they wouldn’t need a backend at all, and we can add the user data from the token to each upload.

This only works if they are a magic link user, which would be a good recommendation at hackathons but won’t help with a lot of our partners.

This might be a great step forward in making nft.storage a “client” of web3.storage.

[ryanwolhuter]

Hey everyone 👋 is anyone working on this currently? I would love to get involved with building the solution here.

[farahats9]

I have been wondering about this too, it would be awesome if I could make a token that allows adding files and not delete existing files.

[olizilla]

@farahats9 the good news is: that's how it works currently. We're not going to allow deleting via an API token until users are able to create scoped tokens, and tokens created before we supported scoping will never be able to delete. Tokens you create with web3.storage today can upload files and list all the uploads for an account.

[olizilla]

@ryanwolhuter great! no one is working on this right now, as we are in the middle of an epic refactor to switch out our db, see: #388 which is blocking other things that would need to save state to the db. Are you keen to work on the token scoping issue specifically or are you interested in hacking on web3.storage more generally?

[farahats9]

@olizilla thank you for the explanation, if the token cannot delete then its good enough for my use case. It would've been better if we can also control the "list" permission but for now its ok, I will encrypt the uploaded data anyways.

[ryanwolhuter]

@olizilla I am keen on hacking in the most general sense! My project Ferry is using web3.storage right now to great success (finalists in HackFS) and we're super invested in growth here. I have permission to dedicate some of my work hours to helping out on building Web3.Storage, if you'll have me. I'd love to chat you about how I can be most helpful.

[codewithpom]

Any updated on it ?

[dchoi27]

Hey, we are kicking off work on implementing UCAN-based auth in Web3.Storage in the coming weeks. (#261 (comment)) This should handle the whole uploads side of token scopes out of the box, and then things like delete tokens can follow after.

[orvn]

For the scoping of tokens (here and #300), note that the Pinning Services API table retrieves using a single user-generated token. So if tokens become scoped and the user has multiple tokens, not all pins will be visible.