Subject: Re: Web Keys and HTTP Signatures

From: Nico Williams <[email-masked]>
Date: Sun, 7 Jul 2013 19:07:35 -0500

On Thu, Apr 18, 2013 at 11:19 AM, Manu Sporny <[email-masked]> 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
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 7 Jul 2013 19:21:57 -0500

In the IETF Websec WG we call the use of MACs to bind requests (and
responses) to sessions: "session continuation".

There have been... many specific proposals and even deployed
protocols, like yours.

We really do need a standard method for session continuation.

Session continuation is predicated on having a session key already
exchanged, possibly by an authentication mechanism.  We'd like to
separate the two things: session continuation on the one hand, and key
exchange (and authentication) on the other.

If your protocol is mature enough it might well be the one we should
adopt.  I urge you to subscribe to [email-masked] and help us :)

Nico
--