How Does Jomo Privately Prove My Data on Another Website
Last updated
Last updated
First we will need to clarify a few terms and the different parties getting involved in the Proof.
They all mean the same thing, which is the device the user is holding and using to complete the flow. It has the highest data priviledges and only the user themselves get access to it.
This is the backend server of the website you are connecting to. Think of Coinbase if you are proving your crypto trading activities, or Tesla if you are proving your ownership over a car.
This is a server that Jomo hosts, which plays a crucial part in the proof. It sits on the side when the frontend talks with the application server and notarizes that the communication did happen. However it does not see the unencrypted raw transcripts but instead only receives encrypted data blobs. Thus it knows nothing about what's being transmitted.
This is another server that Jomo hosts, which receives the substring proofs generated by the frontend and checks its validity, upon success, it generates an attestation about whatever data that was disclosed to it.
Some of the Jomo flows are initiated by an application or website which is requesting user's data from the application server, and the end of these Jomo flows would be users sharing selectively disclosed information and a proof of validity to the requester, who can then validate the proof with Jomo.
Below is an abstracted description on what happens between the different parties when a proof is made.
In contrast to the normal TLS session that gets established whenever the browser talks with a server. Jomo's Notary Frontend sets up a 3 party TLS connection, among the browser, application server, and the Jomo Notary Server.
In this setting, Jomo Notary Server participated in the key exchange flows of the TLS session and thus is able to validate data that's being transferred, however it doesn't get the entire key, and thus is unable to read any unencrypted transcript.
After the TLS session is completed, Jomo frontend generates a zk proof to the Notary server about the TLS session. The notary validates the proof and issues a Notarization with signature over the merkle commitment of the transmitted bytes.
With the merkle commitments, the Frontend can selectively present certain sections of the bytes transferred, and prove to the Verifier that those bytes were actually transmitted.
After validating the proof, the Verifier then writes the data into a private EAS attestation.
On top of it the frontend prover can then choose to make a proof against the data in the attestation, to further hide or limit the information being shared to the Requester.
Jomo uses PSE's TLSNotary as the backbones of our proofs. You can read more on TLSNotary at here.
