Agree on auth, roles and permissions

[valiafetisov]

Goal

Agree on the overall functionality related to auth

Context

Since the initial version of the authentication was already implemented in powerhouse-inc/switchboard#16 and powerhouse-inc/switchboard#28, it's time to make it production-ready and close all open questions.

Tasks

• [x] Prepare open questions
• [x] Propose an answer to each question
• [x] Ask for feedback
• [ ] Conclude by writing next steps

[valiafetisov]

1. Who is able to fetch data?
   • Proposal: In order to make requests, one have to register and send authorization token with every request
     • Reason: in order to prevent potential distributed denial-of-service attacks, we need to identify each request, this will also help us identify who is using the API
2. Who is able to register?
   • Proposal: registration is open for everyone, once account is created, the user can immediately make get requests
     • Reason: we anyway plan to make database dump publicly available, and make operations transparent
3. What external service will be used to validate registration (email, captcha, etc)? (we need that in order to protect from ddos attacks and potentially provide "password reset" functionality)
   • Proposal: users should be able to register using their email
     • Reason: Email is a decentralized protocol, although still commonly used and is suitable for non-technical users (ie analysts). later on we can also support Sign-In with Ethereum functionality interchangeably
4. Do we need to set origin restrictions for tokens?
   • Proposal: yes
     • Reason: since we expect that many requests will be coming from other frontends that publicly expose our tokens, this is essential to prevent token stealing
5. Do we need to distinguish between read and write tokens?
   • Proposal: Maybe in the long-term
     • Reason: The user who creates the token will give the token the same rights as the user itself (as in many other services)
6. How will the rights be distributed and by whom?
   • a) There will be a special role to edit all user roles
   • b) There will be a user document model with special operations to add or remove roles, different roles will allow editing of particular user roles and managing of particular roles
7. How will other frontends get authorised to do write operations? Will they implement their own login forms (and trust other websites to put their passwords in)? Or will we need to provide SSO-like functionality?
   • SSO-functionality is safer for the user, but maybe harder to integrate on other websites

[valiafetisov]

Reaction to Permissioned_Document_Processes.pdf:

For each state (External, Draft, and Final), there is a TO_{STATE} permission that can be assigned.

• This approach is hardly generic. For example, there can be a new requirement in the future to restrict Core Unit Administrators from changing Final to Draft, which would require adding 9(?) other new rights
• This level of granularity is still not sufficient to make permissions completely static. For example: it does not cover ownership of the document (or can Core Unit Administrator edit any Budget Statement in Draft state?). Therefore, the "ownership" check (or rather check that the document is attached to the same Core Unit as Core Unit Administrator) would still need to be written in code, inside document model (or its permission layer, up to you)
  • Or, if it's desired to make those checks static (computable without execution) you would need to adopt some existing generic approach to defining checks like ownership (e.g. json schema)

Based on the above, I would propose to:

• Define a list of roles that are static (eg CORE_UNIT_ADMINISTRATOR, CORE_UNIT_AUDITOR, etc)
  • Export the list from the document model
• Attach those "roles" to a user, store them in the database
• When editing the document, send user object with
  • List of attached roles
  • Complete user object (eg. which core units are attached to it)
• Do the actual check in the document model code

Based on the proposal, we need to agree on:

• [ ] Under which name/path the list of roles is exported from the document-model-libs
• [ ] Under which key the list of user roles is sent to the document model (eg roles)
• [ ] What format is used to send related information
• [ ] What to do when previously existing roles are removed (i.e. migrations)

[valiafetisov]

Reaction to Authentication_and_Message_Signing.pdf

Summary

• We should implement authentication via wallet as primary identity
  • Aiming to support multiply blockchains in the future, eg storing address as eth:0x...
  • The most common scenario: user owns a private key of the eth:0x... address
  • Less common scenario: smart contract address (e.g. multisig), but then the identity is transferrable, which should not be allowed
    • Accounts should be non-tranferrable
• We should leave feature possibility to add aliases (e.g. ENS domain names, sidechain addresses, etc)
• The "sign in" process is based on the user sining a message via their private key (to avoid fees)
• Account deactivation should be possible (aka "Burn Message")
  • Deactivation should be permanent "It must not be possible to undo a burn"
• Accounts can use "Delegate Identities" to execute actions on their behalf
  • Delegated identity is not just a token, but "private/public key pair"
    • Note: this contradicts previous proposal to use JWT tokens for session management
    • Note: we might want to use Web Authentication API to implement it, but it requires https, which might be problematic for the offline-first applications. I'm also not sure if it can create multiply key-chain pairs per client

Questions/Reactions

Typically, a delegated identity is tied to an application instance or an application session that needs to act (sign messages) on the user’s behalf

Literally signing all requests using deligated identity is possible, but will make API interactions much more complicated. Current tooling such as for example graphql playground does not support this type of authentication. In my opinion it's important to keep JWT tokens as a means of authentication to streamline adoption of the API.

I also see more harm than value in "rolling your own authentication" for the web. There is a standard for authenticating with wallets described in EIP-4361. It does work for the "primary identity", but it's not directly suitable for the "delegated identity" (one example reason: then, every request will need to be turned into two to include challange (nonce) to prevent replay attacks, which is a lot of overhead for someone wanting to implement API requests)

The Delegate Identity is then approved by the user by signing a transaction with their Primary Identity (this typically happens on Renown), and by submitting this transaction to the blockchain

I'm not sure why we need to do something on chain if it was suggested above in the document to use off-chain message singing to avoid transaction fees. Keeping signed message in our database (for the potential auditability) is effectively the same thing (for this particular use case) as submitting it on-chain.

Burn Message

Same here: this can be done via off-chain message that is then (stored in our database as a proof). Please elaborate on the need of the on-chain transaction here and how does it play together.

Timestamp Attestations

To validate that the message was indeed signed not earlier than x point of time, we can also include hash of the latest block. If the exact timestamp is required, then it's better to do on-chain transaction by the user or our service independentry from the user. I don't think using Twitter as attestation service is suitable for decentralised application.