UCAN-based authorized uploads with web3.storage

[dchoi27]

UPDATE: We'll be implementing UCAN-based authorization after implementing it in NFT.Storage (issue here: nftstorage/nft.storage#851)

---

We want tons of end user-facing apps to build on top of web3.storage, and for it to be easy for developers to build these apps following best-practice patterns that we recommend. At the moment, the primary approach is for users to store data with web3.storage via trusted centralized servers that the app developer manages, with these servers containing and managing keys that are used to store all user data.

As we get more user feedback and understand what developers are building on top of web3.storage, we should make it possible for alternative, more decentralized access patterns with web3.storage. Some potential examples include:

• Mechanism for assigning and managing web3.storage access keys for end users
• Wallet-based sign-in and management of end user storage on web3.storage
• Writeable gateway (that may or may not require authentication)

[dchoi27]

Requirement: Web3.Storage authenticates a user of an application

Options (non-mutually exclusive):

• Use wallet auth
• Use magic.link private key (developers would share their private key, and users would need to sign in to the application using magic.link)
• Developers provide an endpoint where folks can create a scoped user token

Some additional requirements on making this compatible with efforts around token scoping #314

[mikeal]

I think the base requirements here, which are shared with #314 are:

• Allow end-users to be authenticated against dotStorage
  • Tag incoming data with user information that is indexed and can be used in API’s for listing user CID’s
  • Enable backend-less development with dotStorage
    • Wallet auth gets this for users who have crypto wallets
    • Accepting the developer’s Magic Link token gets this for applications that already use Magic Link
    • While still a backend, Token scoping #314 gets us this with a minimal backend for users using any other authentication mechanism
  • Scope tokens to user specific interactions (don’t allow admin actions w/ only user authentication)

Until we do all 3 features we won’t hit all the users we want, so we need to make sure that we design the first one we decide to implement in such a way that it will be compatible with future methods:

• When we write records for uploaded data we need to use a flat tagging system rather than treating applications, developers or end-users as a hierarchy.
  • We may also want to implement a broader generic tagging system as part of this feature so that we can namespace and protect “user:” or other tag prefixes we want for the service
• When we scope the tokens we need to remember that this token may be used by us and other applications, so we probably can’t do “user” and “admin” because the permissions they get in our service and other services may not be identical. We probably need to do something like “w3s:user” if we can

[atopal]

Update:

• We are pretty clear that signed uploads are a way to let end users upload to web3.storage, but that means that the developer of the app has control over the data.
• We still need to decide how devs can create apps where end users can store with web3.storage without devs haivng control over the data

[Kirbyrawr]

Bumping this, my approach is as follows:

• Every user is in charge of their own API Key.
• Every user must follow the terms and service (decentralizing this part from the developer)
• The user will need to input a password to encrypt (AES) the token. In my case the token will be stored in the user Stellar Account using a DataEntry operation
• When the user wants to mint new NFT's (Talking in the case of nft.storage) the user will only need to login with their account (using the wallet) and input the password (in order to decrypt the token key retrieved from the blockchain), the app won't send the password to any server as the encrypt/decrypt ocurrs locally.

Here's a photo of a concept:

[dchoi27]

Update here - we are proceeding with implementing UCAN-based auth in NFT.Storage, which will allow NFT.Storage users to delegate uploads to others (like their users). This is being tracked here: nftstorage/nft.storage#851

We'll implement this solution in Web3.Storage as well. It's important to note that this will likely require Web3.Storage users to have their own backend to allocate and manage delegated UCANs at first, but UCANs are a pretty general solution that could allow for backendless apps to be created as well if the right service layer is living somewhere. More on UCANs here: https://fission.codes/blog/auth-without-backend/