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

Late to the party but I have a follow up question.

Consider a canister that update http queries to http updates. How can we have 100% certainty that we went through consensus? The node that received the query could very well have intercepted the call and returned some locally-generated results without going for consensus. Is this understanding correct or am I missing something!?

1 Like

If the subnet signs it with is key, it has to go through consensus. These signed responses can either come from a update call OR a query call that has the static http response+signature cached
A query call canā€™t do that on is own, but the first time itā€™s called (assuming itā€™s static content), the request can be upgraded, then stored/cached for other query calls

To be clear a query call can return HTML on its own, but not signed. Also the boundary nodes validate the response bodies for signatures and reject them if invalid, unless you use the ā€˜rawā€™ version of the url

https://mops.one/certified-cache
Is a good library to use to do this query cached signed responses

Thanks. Iā€™d like to understand how http update calls are implemented. Is it correct that from the outside (client), http query and update calls are similar. When the http calls hits the IC, it is first handled by a single node. And only if it is an update calls more nodes will be involved for consensus.

Feel free to share a link to the docs as well (couldnā€™t find that info but I may not have looked at the right place).

The client handles them differently through the boundary nodes. With a query call, its just a call to one replica through the node, but the update calls are a call with read_state polling. But the result is essentially the same.
Im not sure on the specifics of how the boundary nodes handle calling multiple replicas but there is some documentation in the wiki

If the initial request returns upgrade = Option<true>, the system will ā€œupgradeā€ the query into a call, and will use the http_request_update method. You can use that method to do your work, calculate a certificate, and cache the response as well as the certificate. This is the pattern that I call a ā€œcertified cacheā€, and is the core of Mops ā€¢ Motoko Package Manager. Any CDK can follow this strategy to support certified queries

Cool! How can the certification be checked by the external party (the caller)?

Actually, this is in progress of development to make it easy to use. Small talk about this was here:

@dfinity/certificate-verification - npm or ic_certification - Rust