W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: [OAUTH-WG] OAuth and HTTP caching

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Tue, 22 Sep 2009 23:15:37 -0400
Message-ID: <a123a5d60909222015t14514fb9pcd5728b8ebed315c@mail.gmail.com>
To: John Panzer <jpanzer@google.com>
Cc: Eran Hammer-Lahav <eran@hueniverse.com>, "oauth@ietf.org" <oauth@ietf.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
HTTP is designed the way it is for a reason.

Every single piece of infrastructure that people are using on the Web
today was developed after the authenticate headers were designed. If
people have designed a scripting host in such a fashion that the
information does not make it through, that is clearly either a
deliberate decision on their part or the system is so clueless that
you probably don't want to use it for any security related application
in any case.


If you try to do a work around you may allow maybe a few legacy
applications to work that would otherwise not. But you will do so by
making OATH one of the obstacles that future designers have to work
around.


Part of the whole point of standards organizations is to help people
to know what parts of the specs they can depend on being constant and
which may change. That all changes if people start to make random
choices and second guess.

At the end of the day, this is a security spec. Every step we take
that adds complexity reduces the security we will deliver. Every extra
quotient of complexity is another opportunity for us to screw up or
for implementers.



On Mon, Sep 21, 2009 at 5:54 PM, John Panzer <jpanzer@google.com> wrote:
> On the server side, one of the concerns in the past has been security in
> shared hosting systems where e.g., basic auth data should be handled by a
> secure container (Apache) and not passed on in raw form to hosted CGI
> scripts.  So some of this comes back to what minimum level of hosting should
> be targeted by the specification -- and how much it should bend over
> backwards to deal with "challenged" environments.
>
> My $.02 is that we should follow the HTTP spec (Authorization: and
> WWW-Authenticate:) and take a minimum distance path to route around limited
> environments if necessary (X-Authorization: and X-WWW-Authenticate:, with
> exactly the same content, would be my proposal).
>
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @jpanzer
>
>
> On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>>
>> As currently written, OAuth use of the HTTP authentication headers is
>> optional at best.
>>
>> The reason for that was based on concerns that some platforms do not
>> provide access to the HTTP header in either the request or the reply.
>> However, this might have significant ramifications on caching and other
>> parts of HTTP where an indication of an authenticate interaction is needed.
>>
>> Before the OAuth WG spends any time on discussing the various methods of
>> sending authentication parameters, I would like to find out if using the
>> authentication headers is more of a requirement for such a protocol.
>>
>> EHL
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
Received on Wednesday, 23 September 2009 03:16:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:10 GMT