Http_request and http_request_update certification

My understanding right now is that if a developer chooses to expose canister functionality through http_request and http_request_update, that they essentially forgo all certification.

It would be great if some kind of certification information could be returned in response headers so that http clients could verify http requests if developers choose not to use the agent.

If certification is really important, then a REST-based paradigm is going to require an easy way to do this, and http response headers seem the obvious way to do this.

1 Like

There is a header to set for certification. There is a v1 and v2. https://internetcomputer.org/docs/current/references/http-gateway-protocol-spec#response-verification-outline

The reason rest based services are such an issue is that they are typically unbounded in variability and there is no way to certify all possible responses. We need to consider atomic level certifications such that each item in a json response can provide its certificate. This will explode data sizes though as each data atom will have a merkle witness.

2 Likes

When I was doing the farcaster frame in Motoko it seemed like http_request query calls you could add a cert header, if you ran in through http_request_update first, then cached it. And the http_request_update should run through consensus and create it for you, but I have only played with it a little bit

Query call response:

let response : HttpResponse = {
    status_code : Nat16 = 200;
    headers = [("content-type", "text/html"), cache.certificationHeader(req.url)];
    body = body;
    streaming_strategy = null;
    upgrade = null;
};

Code:

1 Like