Web Keys and HTTP Signatures

My name is Manu Sporny. I'm the current Chair of the W3C RDFa WG, JSON
for Linking Data (JSON-LD) CG, and Web Payments CG. I am also an editor
of various W3C specs and member of the HTML WG and RDF WG.

There is a relatively new spec at W3C called Web Keys[1] that now
supports HTTP Signatures[2]. It is being worked on as a part of the Web
Payments[3] work. Specifically, the PaySwarm[4] specifications use Web
Keys and HTTP request signatures.

We'd like to coordinate with the IETF on this work to make sure we have
all parties interested in solving this problem involved in the work. We
would also like more eyes doing security audits[5] on the protocol.

For a high-level introduction to Web Keys, see the Mozilla Hacks article:

https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/

For a high-level introduction to the Web Payments work, look here:

http://blog.meritora.com/launch/

One of the first questions that came up in the IETF HTTP WG thread[5] on
the matter is why none of the other HTTP authentication schemes were
acceptable to the Web Payments group at W3C. Here is a quick run-down of
the reasoning:

HTTP Origin-Bound Authentication (HOBA)
http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt

We had considered signatures in the URL in the second approach to the
problem in the Web Keys spec. We eventually rejected the solution
because of limitations in the URL length in some browsers and because we
wanted the semantics of the HTTP headers to be able to be a part of the
digital signature. We also didn't want large signed messages being
dumped to the webserver logs (the request line is typically included).
So, while HOBA does solve the problem, it doesn't solve it in a way that
is acceptable to us.

HTTP Mutual Authentication
http://tools.ietf.org/html/draft-oiwa-http-mutualauth-12

Overkill for our purposes and requires multiple bounces back and forth
between the client and the server. Key exchange isn't required since
that's taken care of by the Web Keys PKI framework. We don't intend the
Web Keys HTTP signature protocol to be session-based, as a session-based
value can be built on top of HTTP signatures pretty easily.

HTTP Multilegged Auth
http://tools.ietf.org/id/draft-montenegro-httpbis-multilegged-auth-01.txt

Seems like overkill for our needs and is fairly specific to HTTP 2.0. We
wanted something that could work for HTTP 1.0. Multi-legged
authentication is something that we're not interested in solving using
HTTP Signatures. Putting state into the protocol is something we'd like
to avoid if possible.

HTTP Salted Challenge Response
http://tools.ietf.org/html/draft-melnikov-httpbis-scram-auth-00

Uses HMACs, doesn't use public key crypto, which is a requirement for
Web Keys and the Web Payments work.

HTTP REST Auth
http://tools.ietf.org/id/draft-williams-http-rest-auth-03.txt

This was the solution that seemed to be most interesting to the Web Keys
and Web Payments work. However, it requires quite a bit of state to be
remembered by the server (the Session URIs). Keeping the state of a
"session" around isn't desirable. We didn't want there to be a concept
of logging in and logging out of a website w/ the HTTP Signature stuff.
We'd rather that sessions are built on top of HTTP Signatures via a HTTP
header or cookie. Again, if we had to pick a back-up solution, HTTP REST
Auth seems like it might work for us, but we'd rather not use if we
don't have to.

I'll stop here and wait for feedback from the groups that are involved.
I am in contact with Stephen Farrell and a few other folks at IETF about
where best to coordinate the work.

-- manu

[1] https://payswarm.com/specs/source/web-keys/
[2]
https://github.com/joyent/node-http-signature/blob/master/http_signing.md
[3] http://www.w3.org/community/webpayments/
[4] https://payswarm.com/
[5] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0145.html

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Thursday, 18 April 2013 21:27:34 UTC