Workflow
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 randomnessrandom1
, an expiry timeexp
, and computes the nonce vianonce=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 getssub
,iss
,aud
. Thejwt
serves as a certificate forpub_k
, confirming that the owner ofpri_k
is indeed the user identified by thesub
issued by the OP.
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)
. Thezkaddr
will be compatible with all types of wallets and blockchains.The frontend computes the wallet address
waddr = H(zkaddr)
.
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 passesiss
,sub
,aud
,nonce
that can be parsed fromjwt
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
andaud
are converted toascii(iss)
andascii(aud)
as it's the only format the circuit can handle.
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 computeswaddr
fromzkaddr
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 withpri_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 newpub_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.
Last updated