# Workflow

1. **Get JWT**

In the process of zKey, the OP is utilized as a certificate authority by embedding data into the nonce during the OpenID authentication process.

* The frontend generates a session key pair `(pri_k, pub_k)`, a randomness `random1`, an expiry time `exp`, and computes the nonce via `nonce=H(pub_k, random1, exp)`.
* User goes through OP’s login flow and passes in the nonce.
* Upon successful authentication, the frontend gets a JWT, denoted as `jwt` , from the OP.
* The frontend parses `jwt` and gets `sub`, `iss`,`aud`. The `jwt` serves as a certificate for `pub_k`, confirming that the owner of `pri_k` is indeed the user identified by the `sub` issued by the OP.

2. **Get Salt & Address**

zKey addresses can be generated from any unique and stable identifier provided by the OP to ensure that each user has a distinct address. However, this approach presents a privacy issue: the same identifier might be returned when users log in to different apps, potentially exposing the link between their on-chain addresses and their Web2 identities. To address this problem, a salt is introduced, which unlinks the user’s OP-issued identifier from their on-chain address.

* The frontend generates a `salt` and saves it in the salt backup service.
* The frontend computes the zKey address `zkaddr = H(sub, aud, iss, salt)` . The `zkaddr` will be compatible with all types of wallets and blockchains.
* The frontend computes the wallet address `waddr = H(zkaddr)` .

3. **Get ZKP**

Now we can use the salt and the JWT to compute a zero-knowledge proof and demonstrate the association between `pub_k` and `waddr` .

We utilize a ZKP service to generate the proof, as the computation might be challenging on users' local devices. This service operates within NVIDIA's Hopper trusted computing environment, ensuring no sensitive information is leaked. The average generation time is approximately 2 seconds.

* The frontend passes `jwt`, `OP_k`(OP’s public key), `salt`, `pub_k`, `random1` to the ZKP Service to generate a proof. The frontend also passes `iss`, `sub`, `aud`, `nonce`that can be parsed from `jwt` to help the ZKP Service verify all the inputs.
* The ZKP Service returns a proof and public signals including `assic(iss)`, `assic(aud)`, `exp`, `zkaddr`, `pub_k`. Additionally, `iss` and `aud` are converted to `ascii(iss)` and `ascii(aud)` as it's the only format the circuit can handle.

4. **Submit Transaction**

Since zKey is built on Starknet, which natively supports smart contract wallets, the `pub_k` can be embedded into the wallet, eliminating the need to verify the ZKP for every transaction.

* `waddr` will be deployed initially to create the corresponding Wallet Contract, with a temporary public key and no private key. This step is solely for establishing the wallet on-chain, as the function does not support proof verification during the initial wallet deployment.
* After the initial deployment of `waddr`, the frontend submits a proof and public signals to the Wallet Contract. The Wallet Contract computes `waddr` from `zkaddr` and in the public signals to ensure the proof is sent to the correct Wallet Contract. Once verified, it calls the Authentication Contract to validate the proof and signals. Upon successful verification, `pub_k` is written into the contract, and the user only needs to sign with `pri_k` for future transactions.
* When users need to reset the session keys(this occurs in scenarios such as when they lose their keys), the same process applies, and the old `pub_k` will be overwritten with the new `pub_k`. As long as they retain the OP's account and the salt, they can retrieve the same address and reset their key pair at any time.