1) DECO's Three-party handshake
-How does it work?
When the Prover (Alice) logs in to a website, the session key they establish with the server is split on the client side between the Prover and the Verifier (Bob).

2) How is different from a traditional TLS key exchange?

Normally, the Client would randomly generate a private key (x), compute the corresponding public key (y) and send it to the Server.

3) In DECO it looks like this:
The Verifier first generates his own private key, computes the corresponding public key and sends it to the Prover.

The Prover follows the same steps, but what she sends to the Server is the product of her public key and the Verifier's public key.

4) The idea here is that the two parties generate a shared key for a TLS session and use it in a joint manner, securely. The protocol is such that Alice can't forge data from the server since she doesn't know the session key at a critical time.

5) What she can do is prove things about the data provided by the Server to Bob in zero-knowledge.

6) All of this (the area shaded in grey) is transparent to the Server. It has no idea that there's an interactive protocol happening on the back end. As far as it's concerned it's talking to an ordinary client.

7) A refined picture of DECO involves two steps.
First, the Prover logs into the target website while performing a three-way handshake with the Verifier.
Second, the Prover can now prove things about the data they get from the Server to the Verifier in zero-knowledge.

8) What DECO can't do is the following:
It can't have a user log into a website and unilaterally generate a trustworthy DECO proof that they can then put on chain.
It cannot be done directly. DECO requires to have the oracle network in the loop.

9) DECO is not the only protocol that will require #Chainlink's decentralized oracle network to unveil its full potential.