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, noncethat 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.