W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

Re: HTTP sasl draft in last call

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 10 May 2004 09:41:56 -0700
Message-Id: <F35ED503-A2A0-11D8-8F35-000A95B2BB72@osafoundation.org>
Cc: "Nystrom, Magnus" <magnus@rsasecurity.com>, Ted Hardie <hardie@qualcomm.com>, Joe Orton <joe@manyfish.co.uk>, Webdav WG <w3c-dist-auth@w3c.org>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>

On May 7, 2004, at 8:06 AM, Alexey Melnikov wrote:

> Nystrom, Magnus wrote:
>> Lisa,
>> Thanks again for your review.
>> The reason for introduction of 235/236 status codes is that they 
>> allow for
>> a clean introduction of a SASL security layer. With 200 alone, one 
>> must
>> ask when the SASL security layer actually goes into effect. Clearly 
>> not
>> all headers can be included in it, since for example there could be a
>> final WWW-Authenticate header from the server which is needed for the
>> client to calculate session keys etc. OTOH, any body clearly must be
>> protected by them. So, after some discussion, and while realizing 
>> that the
>> 235/236 will require an extra roundtrip, we felt the advantages 
>> outweighed
>> the disadvantages.
>> Of course, I would be grateful for any suggestions on how to solve 
>> this
>> problem without the introduction of new status codes.
> I agree with everything that Magnus said. I am wondering if this 
> explanation should be part of the document itself?

Unfortunately, I think the architecture that "necessitates" adding 
235/236 requires a rethink.  It's very un-HTTP and ill-defined to 
create a security layer in this way.  We could try to have some 
discussions about how to solve this differently - Roy suggested one 
approach, and there are obvious variations.

Received on Monday, 10 May 2004 12:42:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:31 UTC