Proposal - zkAccess: Zero-knowledge access layer on top of Ceramic / ComposeDB

Grant/Project Name: zkAccess

Proposer’s contact info: Jose Aguinaga (

Grant Category: Apps

ELI5 Project Summary: An access manager where people can get a “ticket” to enter a particular location or venue, without revealing any information about where they got that “ticket”.

Project Description: The grant is to develop zkAccess, an application which leverages on ComposeDB and Zkp-ECDSA (by Cloudflare), where every individual stores a ECDSA P-256 public keypair in their own profile. These keypairs can be “merged” into a single composite representing an event, which then can be verified for gatekeepers to check. Owners of the “merged” keypairs can create ZkAttest proofs offline and share it to invitees or for personal use to have access to the event, w/o disclosing who they are or who invited them.

Architecture: The app relies in two main data models: a public key per user, and a mapping of multiple public keys per app. This allows querying multiple users from various applications assuming the application wants to grant access to these users. Within the app we have multiple roles: guests, looking to “access” a venue or system; hosts, individuals able to issue the “access”; venues, apps or places managing hosts and finally guards, which review the proofs/tickets issued by hosts and granted to guests.

Relevant links:

  • Website: jjperezaguinaga[dot]com
  • Twitter: twitter[dot]com/0xjjpa
  • Github: github[dot]com/0xjjpa
  • Previous projects the team has meaningfully contributed to: Onchecked (, conFIEL (
  • Comparable projects or peers: Sismo (sismo[dot]io/)

Ceramic Ecosystem Value Proposition:

  • Generate a database of public keys of individuals connected to DIDs to slowly make Ceramic the de factor auth layer for private applications.
  • Increase adoption of DID standards by leveraging cutting edge technologies (e.g. webauthn) to provide easy key management over existing solutions.
  • Bring awareness of the indexing and composable capabilities of the Ceramic network and provide an authentication layer within the decentralized ecosystem

In general we are looking to build the Auth0 of decentralized applications by bringing SSO-like access capabilities to DApps using Ceramic as the “auth” table. The added value is that we want to do it via two interesting technologies: webauthn which quickly allows people to use public-key cryptography to access apps, and zero-knowledge proofs, ensure the apps do not have any knowledge of the delegated access apps gives to third-party issuers. In this last example we can think of how Ticketmaster has data on all their artists events, instead of the artists being the sole owners of their audience reach and data.

Funding requested (DAI/USDC): [$15,000.00]
For this initial round I would like to get started with 15k for the PoC stage of the project.


  • Milestone #1: Architecture and Overview - [$3,000]
    • Architectural Diagram
    • Software Requirements
    • App Specification
  • Milestone #2: PoC- [$12,000]
    • Desktop-compatible web app connected to either 3IDConnect w/a local P256 key or PassKey w/Webauthn
    • Composite for both public keys and general members lists for apps
    • API able to grant access based on DID connectivity for read/write on admin side
    • Generation of zero-knowledge proofs based on existance of a P256 key within an app Composite “realm”
    • Verification of the proof by a third party by querying CompositeDB against a specific app “realm”

We have two follow up requests upon completing the first milestone, but we want to asses the adoption and feasibility before requesting further grants. In short, we rather want to get a PoC out ASAP (perhaps something to showcase for ETH Denver) before asking a more structured grant as next steps. The last grant would be the Alpha (shown below), which upon completing we would like to look for investment outside the Ceramic ecosystem.

I accept the 3Box Labs Grants terms and conditions: [Yes]
I understand that I will be required to provide additional KYC information to the 3Box Labs to receive this grant: [Yes]


Hi @jjperezaguinaga, thank you for your proposal! We will be in touch with an update once we have completed our initial review (1-2 weeks).

Congratulations @jjperezaguinaga , I’m delighted to inform you that your grant proposal has been accepted! :tada:

We would like to award you a Ceramic Builders Grant.

We will follow up shortly with more details via email.

1 Like

@0x_Sam Thanks for the update! Should we do our updates in this thread, or does it make sense to create a new one and take it from there.

From now on, all updates and tasks will be handled in GitHub - 0xjjpa/zkAccess: An auth and access layer on top of the Ceramic Network using zkECDSA and webauthn

1 Like

Hi @jjperezaguinaga, at the risk of duplicating some work from GitHub, it would be great if you also shared updates here in this thread. This will make it easier for all Ceramic community members to follow your & others grant progress. Thanks for your understanding!


1 Like

[ Update 01/07 - v0.0.1 - zkAccess + Webauthn Demo ]

Here’s my first update for zkAccess grant.

Source code:



From the original proposal for zkAccess, its architecture looks as follows

The critical parts are the first three components:

  1. The Ethereum key provider used to interact with Ceramic from a user perspective.
  2. The Passkey generated on the client side to be able to create zkAttest proofs
  3. The CompositeDB schema and model to register the public keys.

The part that I had the least confidence in making it work was 2, as I wasn’t sure whether a P-256 webauthn key could be used to create a zkAttest proofs. This was mainly due to the format used by webauthn keys (ASN.1 over a “raw” format). Thus, my first update was focused on making this happen, and I focused the last two weeks doing so.

The first days were a bit frustrating, as I was trying to recreate the webauthn workflow entirely with a Relay Party (RP). Sadly, the entire RPC with an RP involved is quite extensive, and there aren’t many server’s or code out there showcasing this. After a few days, I capitulated trying to make the server obtain the webauthn key and decided to take a few baby steps first.

After reading again the webauthn specs, I realized I could mimic the entire code client side. In other words, I could “fake” the RP signing data as I did not want to create access over via a server but instead via a zero-knowledge proof (i.e. zkAttest). Thus, I proceeded to replicate the workflow client side, and after a few days, I managed to do so. Hooray!

Once I “mastered” the passkey client side, the last part was to interact with zkAttest. This was a bit trickier since, of course, zkAttest was coded with crypto.subtle.generateKey in mind, and I knew the format would be different. Luckily someone already solved this in a different context, which helped me then create a successful zkAttest proof against a bunch of P-256 public keys. We made it!

I ended up putting a UI on top of it to showcase this. Here’s how it looks in two devices (iOS and Android). The Android device is a significantly old version, hence the zkAttest proof generation taking almost 30 seconds on its own.

iOS Demo

Android Demo

Next steps

With 2 out of the way, we are now ready to get back to the actual Ceramic part of the application. I’m still not 100% of the current way we are handling user interaction with Ceramic (see my comment on the Discord’s group), so I’ll jump right into the CompositeDB. A successful integration here would look as follows:

  • We create a specific schema able to store a Public Key using email as an ID
  • We can create a composite able to query a given Public Key given an email
  • We can then store multiple Public Keys in our demo (instead of mocked ones) and proceed to replicate the same valid proof mechanism with real Public Keys from other users, making the demo closer to the end product.



1 Like

[ Update 01/27 - v0.0.2 - zkAccess + CompositeDB ]

Here’s the second update for zkAccess grant.



As described in the past update, the second step was to store the users’ public keys in our ComposeDB. It wasn’t evident to me the difference between traditional “streams” and ComposeDB until I managed to take a deeper dive into the technology. After I managed to implement did-session into the demo, I then proceeded to interact with my local Ceramic node trying to understand their roles. I created a thread in Discord to discuss these.

In the meantime, I started to put together the idea of the first “implementation” of zkAccess:

In short, the goal would be to have a website where I’ll allow users to manage a DID via their Ethereum account and generate a webauthn credential to store it in ComposeDB. Then, they can request to create a zk-proof against a specific NFT collection (e.g. BAYC). A server would filter the public keys (mapped against an address) for only the owners of this NFT collection, and then the owner could create the proof.

Next steps

I’ve managed to verify 1 and 3 from the original post (i.e., write in Ceramic from an Ethereum account a zero-knowledge attestation data, and query these from ComposeDB). However, I struggled to integrate everything within the existing app. Thus, as a next step I’ll create the “actual” app using Create Ceramic App and import my zk libraries there. I’m hoping to have a fully functional demo by next update.


  • Time. I struggled to wrap my head around the new libraries and concepts, so I ended up putting together this thread for future developers - FAQ for common errors in ComposeDB + DIDs (Jan 23). I’ll have to speed up the demo since I’ll start from scratch with the Create Ceramic App template.
  • Production Deployment - I’ve yet to see how I’ll deploy to production ComposeDB, so that’s another concern (I mean, I can always ssh to a VM and just run the commands, but yeah, something more automatic would be great).