Role (who’s doing it) | What | Input | Output | Modules | |
---|---|---|---|---|---|
1. Create credential type | Credential designer | Design a new credential type expressed in our DSL. | Credential type specification in DSL | ZK circuit | SDK, circuit generator |
2. Phase2 trusted setup for the type and circuit. Depending on the verification stack, this may be skipped | Credential designer + other parties (Galxe) | Phase2 setup for zk-related, specifically for babyzk stack’s proof system: Groth16 | ZK circuit | 1. proving key 2. verification key | The type designer needs to host a trusted setup ceremony for the circuit. Galxe identity protocol will provide an optional MPC node for participating the ceremony. |
3. Publish credential type | Credential designer | Type specification will be published on-chain, and a deterministic Type ID will be generated. For babyzk, verification key parameters must be updated to the verifier contract. | 1. proving key 2. verification key 3. Circuit artifacts like witness calculation WASM. 4. onchain verifier contract. | 1. Type ID. 2. add the verification key to the verifier. 3. proving key will be stored on decentralized storage. | contract: 1. Credential type registry. 2. Type-specific verifier contract. Storage: 1. decentralized permanent storage. |
Role (who’s doing it) | What | Input | Output | Modules | |
---|---|---|---|---|---|
4. Register as an issuer | Issuer | Register to become an issuer. | 1. metadata 2. public keys 3. proof of identities. | issuer ID | Issuer registry + pubkey manager for different verification stack |
5. Register a new credential context | Issuer | Add a new context on-chain. | 1. CredType ID. 2. Context string | context ID | contract: context registry Context ID: hash of context string cut to 160 bits, from LSB. |
6. Issue a new credential | Issuer ←→ owner | Sign a new credential to user. | 1. credential header 2. claim values. 3. user’s identity commitment 4. signature | a credential in JSON | SDK |
Role (who’s doing it) | What | Input | Outcome | Modules | |
---|---|---|---|---|---|
6.1 Credential revocation | issuer | Issuers can manage the ‘signatures’ they signed on credentials. | 1. expiration. 2. signature ID via SMT. 3. explicitly seal the credential. | Credential will be revoked, holder cannot generate proofs that satisfy the goal. | Issuer Registry |
Role (who’s doing it) | What | Input | Outcome | Modules | |
---|---|---|---|---|---|
7. zk-proof generation | owner | Credential holder can generate a proof against a set of conditions. | 1. credential. 2. conditions. 3. proving key. 4. external nullifier | 1. proof 2. public data | Galxe identity vault or any apps that have integrated identity protocol SDk. |
Role (who’s doing it) | What | Input | Outcome | Modules | |
---|---|---|---|---|---|
9. zk-based credential verification | verifier | Owners can submit a proof to verifier that some statements about them is true. | 1. proof.json 2. public.json | accept/reject | Stateful verifier, type registry, issuer registry |