The problem ZK HTTPS Oracle solves

Most of the oracle services out there focus on numerical or financial data. Their trust assumptions are built around the honest majority assumption most of the time. These two things could make them unsuitable for certain applications.

With ZK HTTPS Oracle you can attest almost any data source on the web and your trust assumptions rest on the security of the zk scheme, and the security of the certificate chain.

Example one: Take your existing identity data from your banking service (through Open Banking or Plaid) to create a zk proof of identity. This way you can reuse existing "web2" identity infrastructure without sending your data (selfie with a passport) to identity providers every time you sign up for a new financial service.

Example two: You can use zk-proofs of payment transactions (let's say, from Plaid) to settle peer-to-peer exchange of fiat and crypto. There are existing projects out there using zkemail to do that, but it would be neat if you could just hook into an API and fetch whatever data you need from Plaid instead of parsing emails from Venmo etc.

Challenges I ran into

The proof of concept doesn't work, and the root cause is with some Rust crates that I wanted to use.

In order to make the oracle work, I need to re-perform an SSL session inside the circuit (to zk-prove it). For that part, I'm using Risc0 zkVM. For the SSL part, I'm using

rustls

crate, which is the de-facto "Rust TLS crate". There are other crates but they are not maintained or have other issues I won't go into.

I wasn't able to use rustls because it uses C dependencies, and that's a big no-no when using crates in Risc0. Preferably, all our crates (and their dependencies) are pure Rust, no-std crates. In the case of rustls, the issue was with the ring which provides cryptographic primitives for the TLS session. There exists a ring fork that attempts to replace C dependencies with some generated code, but I wasn't able to make it work:
https://github.com/betrusted-io/ring-xous
https://www.bunniestudios.com/blog/?p=6521

I think there's also an issue with compiling this particular ring fork on riscv32. This fork is 0.16.20 version compatible, but the riscv compilation targets are only available since 0.17.x (https://github.com/briansmith/ring/issues/1765#issuecomment-1783195284).

So this is where things have hit the wall for me. One more thing I could try is to port the riscv32 target from ring to ring-xous, but ran out of time and grit.

On a side note, it's likely that this kind of scheme (zk-proving SSL session) is unsafe. Related resources:
https://arxiv.org/abs/1909.00938

Shout-out to Roy and Paul from Risc0 for sharing these!

Lastly, I had some issues with compiling various crates. I found this issue to be helpful: https://github.com/risc0/risc0/issues/443

And I also think implementing this would help me with some of my C/C++ dependencies: https://github.com/risc0/risc0/pull/205