HTTP Verification
Communication between a client and a server are done via HTTP requests and responses, respectively.
Web Proofs require knowing that the client, who is trying to initiate a proof, sent an HTTP request that passes all the intended checks. We do not want to allow for the client to send a faulty message and get back data that could then be used to “trick” the value extraction portion of a Web Proof.
For example, a Web Proof may want the request to be a GET from a server that has an /api endpoint that serves application/json. HTTP verfication will enforce that the request a user sends satisfies these three constraints we just imposed - GET, /api endpoint, application/json.
Without this verification feature, it is possible that a different endpoint such as /test could be used in the request, where data returned is not considered valid! Or, a user could try to instead POST or use application/xml instead. These unexpected behaviors could lead to invalid Web Proofs or worse, valid but ‘not real’ Web Proofs. The HTTP Prover circuits prevent that.
On the receiving end, we also want to know that the response was validated. In this case, certain headers may be locked, as we demonstrated in the client request example above. The circuit may also constrain that the status response was OK. Most importantly, the body of this response will contain data that the user is making attestations about, which is likely in the form of JSON content.
HTTP response extraction will then lock what is needed and then extract out the JSON body so this can then be parsed later on by the JSON prover.