Isn't that ACME?

Two related ideas, different jobs

ACME, the protocol behind Let's Encrypt, is designed to establish and renew TLS certificates. HashBack assumes both sides already have working HTTPS and uses that secure connection to authenticate API callers.

Hashbert says: "ACME helps put the lock on the door. HashBack checks which caller is holding the right, freshly made proof. Both jobs matter, but they are not the same job. Also, I strongly recommend the lock."

HashBack needs TLS first

HashBack relies on TLS to reassure the server that the verification hash came from the HTTPS site the client controls. Without valid HTTPS on both sides, the protocol cannot provide its intended identity check.

In that sense, ACME helped make HashBack practical: widespread, automated TLS gives HashBack a trustworthy channel to build on.

Hashbert says: "No HTTPS, no HashBack. Please establish the secure tunnel before inviting me to inspect the proof. I am brainy, but I cannot negotiate with an unsecured puddle."

What HashBack adds for APIs

Once TLS is already in place, HashBack provides general-purpose caller authentication without requiring a long-lived password, token, or private key to be stored by the client service.

• The client publishes a fresh verification hash on its own HTTPS site.
• The server retrieves that hash in a separate HTTPS transaction.
• The server repeats the calculation and accepts the request only when the values match.

That exchange can be completed in two transactions: the API request and the server's callback to the client's verification URL.

Hashbert says:"HashBack is just like ACME, only fewer coyotes are maimed."