- From: Nico Williams <nico@cryptonector.com>
- Date: Sun, 7 Jul 2013 19:07:35 -0500
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Carsten Bormann <cabo@tzi.org>, Web Payments CG <public-webpayments@w3.org>, ietf-http-wg@w3.org
On Thu, Apr 18, 2013 at 11:19 AM, Manu Sporny <msporny@digitalbazaar.com> wrote: >> (Or maybe it can simply be replaced by one of the more learned >> attempts under discussion, see >> http://www.ietf.org/proceedings/85/minutes/minutes-85-httpauth >> http://www.ietf.org/proceedings/86/minutes/minutes-86-httpauth for >> some links.) > > Thanks for the link. We've looked at a number of those before, or > variants of the approaches. Here's feedback on each: > [...] > > 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. State-less servers are also allowed for the REST auth approach. There's a state cookie (which would have to contain, effectively, state encrypted in a server-local key). In a state-less implementation there's no way to logout of a session persistently, but that's OK. I'm pleased that the RESTful approach to authentication is of interest to you. Sorry I missed this e-mail! Nico --
Received on Monday, 8 July 2013 00:08:03 UTC