search

passportxyz / passport

Passport allows users to prove their identity through a secure, decentralized UI
Other
943 stars 451 forks source link

Implementation of Clique for Passport's Web2 OAuth Stamps Verification #1389

Open erichfi opened 1 year ago

erichfi commented 1 year ago

Describe the spike This research aims to explore the feasibility, implications, and estimated scope of work required to integrate Clique's identity oracle solutions into Passport's identity verification system. The focus is specifically on improving the security and privacy of the verification process for Web2 OAuth stamps through the use of Clique's cryptographically secure environment.

Why is this needed While Passport's current identity verification system is robust, there is an opportunity to further enhance the security and privacy of the process, particularly when verifying user attributes on Web2 platforms. Implementing Clique's solutions could provide a heightened level of certainty that user data remains absolutely private during verification. Understanding the technical and strategic scope of implementing such a solution is critical for effective project planning, resource allocation, and risk mitigation.

Deliverable By the end of this spike, we should have clear answers to the following questions:

  1. What would the technical integration process involve?
  2. What are the security implications of integrating Clique's solution, particularly with respect to the handling of Auth tokens and private credentials in a cryptographically secure environment?
  3. What modifications would be necessary to our current infrastructure to support Clique's TEE-based and MPC-based approaches?
  4. How would the integration of Clique's Provenance SDK and Identity SDK impact the overall performance and user experience of Passport's identity verification system?
  5. How could Clique's oracle nodes (Pythia) enhance the security and privacy of the verification process for Web2 OAuth stamps?
  6. What are the estimated costs, resources needed, and timeline for the integration, including potential roadblocks and mitigation strategies?
  7. How would the integration align with our current roadmap and strategic goals?

The deliverable will be a comprehensive report that provides answers to these questions, estimates the scope of work, and outlines a preliminary implementation roadmap, if feasible. This report should inform decision-making regarding the potential integration of Clique into Passport's verification process.

kvnyu24 commented 1 year ago

Responses below for each of the raised points:

  1. First, Gitcoin needs to implement custom DataConnectors, which are interfaces that allow integration with arbitrary API calls, private credential handling, and callback logic, for each of the OAuth platforms that it wants to support. This should be very simple with our Rust-based SDK. Alternatively, Clique can also do the implementation and create public PRs for Gitcoin to review.
    The next step is to build the binary and run the oracle node. There are two options available: Gitcoin can build its oracle binary (Sibyl) from source (we have most of the core logic handling the TLS session, keypairs and other security-enhancement techniques abstracted out into a rebuild), and run it on its own server (e.g. rent an SGX server from Azure), or use the oracles that we provide that are run on Azure servers purchased by us.
  2. In either the case of Gitcoin running the oracles or Clique running the oracles, the oracle provider wouldn't be able to see user OAuth plaintext throughout the session. Users would encrypt their token with a keypair exposed by the enclave in frontend and send the ciphertext to the enclave, which then establishes the TLS session to verify the OAuth. If any additional data is to be pulled (e.g. for GitHub OAuth to pull some developer profiling data), the enclave can force a commitment on the data and enable users to generate zero-knowledge proofs about the data in their frontend with integrity. Overall, each session is guaranteed to have end-to-end privacy and execution correctness even with a malicious oracle runner (e.g. Gitcoin trying to abuse its administrative privileges).
  3. The core logic of the OAuth verification process doesn't have to change -- but it needs to be re-written in Rust with the DataConnector extension. Clique is willing to do the code migration here if necessary. The logic around concurrent processes (if there is any) might need further adaptations to better fit the enclave architecture.
  4. From the user side, the UI/UX should be exactly the same. The performance overhead will at most be a negligible 2-3 seconds for the TEE-based approach, but we can also benchmark it in test environment before pushing it to production.
  5. During the entire process of OAuth verification, no additional third-party outside of the user and the platform itself can see the user OAuth token. In the meantime, the verification process is guaranteed with integrity.
  6. The integration process should be very simple without the need for much development resource dedication from the Gitcoin side. There could be roadblocks around deployment to Gitcoin's own servers, but Clique is willing to offer full support there. There will be no fee charge required if the nodes are run by Gitcoin directly (if Clique runs the nodes then there will be a small fee based on computational usage). We are happy to push for the timeline ASAP and are confident to get a testing version out in two weeks to a month. Further benchmarking and production build will likely take another month.
  7. This integration provides better security and privacy for the users while greatly minimizing the trust that's involved in the OAuth process. In the longer term, it also enables better decentralization (i.e. everyone can run these TEE oracle nodes themselves to handle a part of the auth load).