search

keyko-io / filecoin-verifier

Filecoin project issues
0 stars 0 forks source link

Document the verify client on-boarding flow #18

Closed aaitor closed 4 years ago

aaitor commented 4 years ago

Document the whole flow to verify a new client and allocate the requested datacap. This flow will include both onchain and offchain processes

Example: https://github.com/josepablofm78/TestFlows/issues/1

As a result of this issue we should have a documentation with the flow.

josepablofm78 commented 4 years ago

On boarding process for new clients

Introduction

The current Filecoin Registry application allows to the Verifiers to manually verify new clients and allocated datacap requested by this clients.

The governance process to verify new datacap requests and the transactions history of that is an off-chain process that currently is not being tracked.

In this document we are proposing the changes to apply in order to have a more open and democratic governance framework with the objectives of:

On Boarding flow

Registering a new Client on-boarding request via Github

The following flows allows to a user to request the on-boarding as Client. The steps are:

  1. The users goes to the Filecoin Verify Client Requests project on Github and request to open a new issue in a url like this: http://github.com/filecoin-project/verify-client-requests/issues/new
  2. Github will show a Template issue with a pre-configured set of information that a Client needs to provide. It includes:
    • Name / Organization / Alias
    • Public Profile of Organization
    • Proof of Requester's association with Organization
    • Datacap requested
    • Client Filecoin Address
    • Intented Use Case
    • Contact Information
    • Links to prior approvals
    • Geographical Location
  3. The user completes the information requested and click the "Submit new issue" button
  4. The issue is created in the project and the labels open & state:Request are associated to the issue.

Approving a Verifier on-boarding requested via Github

The flow proposed for verifying a new client is:

  1. The verifier goes to the home of the Registry application and in the top right menu toggle to the Verifier view
  2. The verifier clicks in the Github login button to authenticate into Github
  3. The verifier clicks in the new "Client On-boarding Requests" table
  4. The application fetchs all the Github issues associated with the project "Filecoin Verify Client Requests" with the label: open.
  5. The verifier can see in a table format all the requests sort by date. This will include the following information:
    • Name / Organization / Alias
    • Client Address
    • State of the request "Request", "Further info needed"
    • Date of when the request was sent
    • Datacap requested
    • Description of the request
    • A button for "Grant Request"
    • A button for ask "More information"
    • A button for "Deny Request"

Actions:

  1. If the verifier clicks the "Grant Request", this will send a signed message to verify the client getting from the Github issue description the Client Address & Datacap. If the transaction succeed the application will change the Github request to the state granted adding the label state:Granted and removing the label open. Additionally to this, a new comment to the issue will be added including the transactionId with the following format: Request granted: 0xTRANSACTION_ID
  2. If the verifer clicks the "More Information" button, a small input text field will appear allowing to the verifier to specify what information is missing. When the verifier clicks the Submit button this will replace the state:Request label for state:Further info needed. Additionally to this a new comment with the information given by the verifier will be added to the Github issue.
  3. If the verifier clicks the "Deny Request", a small input text field will appear allowing to the verifier to specify why the request is denied. This information optional. If the verifier clicks the Submit button this trigger the following actions in Github:
    • The issue state label will be changed to state:Denied
    • The label open will be removed
    • If the verifier added any reason, a new comment will be added with that reason
    • The Github issue will be closed

This flows is based in the initial authentication of Github from the verifier side. It means for each request sent to Github, the application will send the verifier credentials allowing to Github to authorize or not the request sent by the verifier.

josepablofm78 commented 4 years ago

NOTE: The previous flow only take into account the general or most common flow for developers and organizations. It must be completed with the rest of the possible use cases, like the redirection to verify.glif.io in case of small datacap requests