Components

1. OpenID Provider(OP)

An entity that has implemented the OpenID Connect and OAuth 2.0 protocols, including Google, Apple, Meta, etc. A key feature of these providers is their ability to issue a signed JWT containing a set of claims to authenticate the end-user.

2. JSON Web Token(JWT)

A signed statement issued by OPs containing claims about the user. We use some of the claims parsed from JWT to derive the zKey address and verify users’ identities, including sub that uniquely identifies the user per provider, iss that identifies the provide, and aud that identifies the application.

3. User

An end user that owns the zKey address and performs transactions using existing OpenID credentials.

4. Frontend

The frontend application that supports zKey, responsible for storing the session private key, directing users to complete the OAuth login flow, creating and signing a zKey transaction.

Since there is no need to securely store or export the key pair, there is no requirement for an additional client or plugin. The frontend can be seamlessly integrated into any Dapp, significantly minimizing the effort required for users to utilize the Dapp.

5. Salt Service

Generates a unique salt and saves it securely. We currently utilize Google Cloud to back up the salt and might move to additional servers.

6. ZK Proving Service

Generates zero-knowledge proofs that attest to the validity of the JWT and salt without revealing the contents.

We are currently using zk-SNARKs to generate proofs, as they are more suitable for handling small proof sizes.

7. Contracts

Consists of a Wallet Contract and an Authentication Contract on Starknet.

The Wallet Contract sets up public key recovery by calling the Authentication Contract and executes transactions.

The Authentication Contract is a set of Cairo files exported from the circuit and deployed on Starknet. This contract will verify zero-knowledge proofs and authenticate transactions.