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

[jjperezaguinaga]

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

Here’s my first update for zkAccess grant.

Source code:

@jjperezaguinaga

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

Overview

• Managed to complete a webauthn workflow using native calls (i.e., navigator.credentials.create and navigator.credentials.get) to manage and sign w/a P-256 key successfully.
• Completed the creation of a zkAttest proof (GitHub - cloudflare/zkp-ecdsa: Proves knowledge of an ECDSA-P256 signature under one of many public keys that are stored in a list.) using a previously created webauthn key.
• Deployed a small demo to showcase how this work (best browsed on a mobile device with biometrics enabled) - https://zk-access.vercel.app/

Description

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

@jjperezaguinaga

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

zkAccess - iOS Demo

Android Demo

zkAccess - 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.

Blockers

None.