# Polygon ID PoC

Create a Proof of Concept with Polygon ID communicating parts: _Issuers_, _User Service_ & _Verifiers_.

The _User Service_ should be a standalone application and able to download its _Verifiable Credentials (VCs)_ from the Issuer and verify its identity with the Verifier.

The goal of the PoC is to create a very simple ecosystem composed by services that Polygon ID has available, namely _Identity Server (Issuer)_, _wallet-SDK (to build the User Service)_ and _verifier-SDK (to build the Verifier)_.

The objective is that the _User Service_ will authenticate itself against the Verifier, after downloading its VCs from the Identity Server. The VCs would be setup locally during the deployment of the _User Service_ or it would be downloaded during startup, if not yet downloaded previously, and stored in some sort of vault (e.g. AWS Secrets Manager).

The flow would be more or less the one drawn in the following diagram:

- The **User** in the diagram represents an Organization that deployed **Nightfall Client** on its premise in order to consume services from **Nightfall Service**
- The services **Nightfall Verifier**, **Nightfall Issuer** and **Nightfall Service** are provided by **Polygon**
- **Authentication/Authorization** verification on **Nightfall Service** side would be transparent. For doing that, some changes are required in **Nightfall Service** which can be achieved by using a middleware that verifies if the request is authenticated, then, if not, redirects the request to **Nightfall Verifier** so that it can handle the authentication. After authenticating the User Service, a token is generated, one can use [JWT](https://jwt.io/), which grants access to **Nightfall Service**
- The authentication token would have additional attributes for relating it with the authenticated User Service's VC and its **Nightfall Address** would be one of these attributes, which would be used when performing operations on **Nightfall Service**

## PoC spec + acceptance criteria

### Background

Nightfall is an Eth L2 (an optimistic rollup with privacy).
It consists on a number of smart contracts deployed on L1, plus a number of off-chain services.
Transactions available: deposit, transfer and withdrawal. Deposit and withdrawal operations are partially private since there's always a L1 trace. Transfers are fully private when performed off-chain. Nightfall also has a number of native transactions which happen exclusively on L2.
Relevant network participants: **Users** send transactions to the network through a service called "Client" (it can service an individual or a group of trusted participants). **Proposers** capture these transactions and assemble L2 blocks (via a different service called Optimist - each proposer runs their own optimist).

### Long term vision (for information)

We want to work with countries to create networks of trust. We imagine a scenario where Governments become identity issuers for individuals and businesses (after KYC/KYB). This identification step will be the gateway to further services: in the case of individuals an example could be CBDC payments.
Governments will also be able to appoint children entities as issuers.
All issued certificates can expired/be revoked.
For money/goods transactions - we'd like to use certificates as a means to whitelisting (/blacklisting) transactors. Transactions can happen in L1 and L2 (Nightfall is a L2 with addresses of its own).
We also envision further use cases, like using credentials for accepting/banning blockchain nodes.

### Starting point

We want to provide networking and supply chain abilities for companies that sign up.
We will deploy a private network for each of them (L1 + L2). This company will have to go through KYC/KYB.
Later, company will be able to add users to the network + invite organisations. Example of organisations hierarchy:

**Torus**
- Company signing up to Torus (network owner, can invite children level 1)
- Children level 1 (can invite children level 2)
- Children level 2

Right now Torus will be responsible for deploying all infrastructure + verifying identities.
We were thinking to only verify businesses for now (ie assume that all users added to a company are trusted participants).
Since current use case is for businesses (not individual participants), we envision companies adding a number of L1 accounts to be whitelisted (how to manage L2 accounts is unknown) - if bad behaviour was ever detected, we could potentially sanction the individual, the account, and even the organisation.

### PoC

A) A user goes through KYC and obtains a verifiable credential. Proposers can only accept transactions from verified users (Client servers to transmit credentials).
B) A business goes through KYB and obtains a verifiable credential that lives in the Client server. Proposers can only accept transactions from verified Clients.
C) A user goes through KYC and obtains a verifiable credential. Client servers only accept transactions from verified users.

A or B or C