6 ms·
Having yet another HTTP Authentication and Signature scheme really isn't adding value to the world. It's too bad this couldn't model the Keystone token authent
by pquerna 15y ago
Having yet another HTTP Authentication and Signature scheme really isn't adding value to the world.
It's too bad this couldn't model the Keystone token authentication API that OpenStack is doing:
http://keystone.openstack.org/ http://keystone.openstack.org/
Or say, heck, don't like OpenStack, even just using OAuth2 would be fine:
http://datatracker.ietf.org/wg/oauth/charter/ http://datatracker.ietf.org/wg/oauth/charter/
It sounds cool, using SSH keys as your API signature, but really it isn't solving a problem that hasn't already been solved.
- kennu 15y agoHow do your alternative examples solve the problem of using a single key (ssh key) to authenticate both using an ssh client and http(s)?
- mcavage 15y agoWe didn't want token-based auth (i.e, Oauth2 or openstack), nor did we want shared-secret based auth (i.e., hmac). We specifically wanted to offer authentication with public-key crypto, and as the blog post points out, the usability of client-auth SSL sucks. So when you say it's not solving a problem that hasn't already been solved, if you're talking about "the ability to sign a request" in the most generic sense, sure, it's already been solved N times. Generally speaking though, in most of those schemes key management is an afterthought, and we didn't want it to be an afterthought. It's been solved by SSH, and that's what we wanted to leverage.; the point was not to reinvent the wheel, the point was to leverage an existing security mechanism.