Having yet another HTTP Authentication and Signature scheme really isn't adding value to the world.<p>It's too bad this couldn't model the Keystone token authentication API that OpenStack is doing:<p><a href="http://keystone.openstack.org/" rel="nofollow">http://keystone.openstack.org/</a><p>Or say, heck, don't like OpenStack, even just using OAuth2 would be fine:<p><a href="http://datatracker.ietf.org/wg/oauth/charter/" rel="nofollow">http://datatracker.ietf.org/wg/oauth/charter/</a><p>It sounds cool, using SSH keys as your API signature, but really it isn't solving a problem that hasn't already been solved.
A better write-up can be found on GitHub: <a href="https://github.com/joyent/node-http-signature/blob/master/http_signing.md" rel="nofollow">https://github.com/joyent/node-http-signature/blob/master/ht...</a><p>Frankly, the blog post leaves a lot of questions and is short on links to answers. It would be easy to walk away from the post thinking Joyent's HTTP Signatures to be incompetently designed. It was almost enough to have me quip, "More like HTTPS Signatures," because the design in the blog post is only sensible over TLS. However, having found the above link, I see that it is the defaults that assume TLS, but that you can specify the signature contain all headers and the request line. This makes it possible to sign requests over HTTP.<p>I'd rather the defaults be reasonable for insecure transports (i.e., all headers + 'request-line'), since the TLS case is easily handled with just 'headers="date"'. If that's not to happen, I'd hope that implementations actively prevent the use of the defaults over insecure transports. Unfortunately, Joyent's reference implementation doesn't seem to do this.
I really like the idea of using SSH keys: one less password to manage, and it avoids sharing a secret with your provider.<p>With hash-based signature schemes, you know that your secret has to be stored in cleartext, which is why you can't choose your own signing token on any clouds.<p>As a solution for technical users, SSH-keys seem like a great idea: they're battle-tested, avoid a shared secret, are no less convenient than using long system-generated tokens, and have a much richer ecosystem (e.g. ssh-agent, password protection, the possibility to store it on hardware devices etc)
As far as I can tell the signature applies only to the date header. Which means that if an attacker can intercept a signed request they can swap in any request of their own without having to change the signature at all. And the server will interpret it as a legitimate signed request.