> For the complete documentation index, see [llms.txt](https://docs.zkey.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zkey.org/workflow.md). # 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.zkey.org/workflow.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.