Re: Content security model

On Jul 26, 2012 3:03 AM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
> I have been thinking a lot about Web Services and how their security
> needs should be met in HTTP/2.0. I came up with some thoughts that
> might provoke discussion:
> 0) The killer application for HTTP/2.0 (if any) is going to be Web
> Services. Anyone supporting a Web server is going to have to support
> /1.1 for decades to come. A new Web Service can stipulate HTTP/2.0
> transport as a requirement.

Here's a crazy thought. Why don't we put the knives away for a moment and
consider whether the new version of http could line up a little closer with
soap, if not necessarily in syntax then perhaps at least a little in its
model? Currently the structure of a http message is approximately a method
and uri or status code, plus key/value store of headers that each have
additional per header syntax and data model, plus an optional body.
Ignoring the whole of soap for a moment if that were merely translatable to
an xml info set then you could pick up xml canonicalization, signatures,
and encryption for relatively little standards work. It might even be
possible to consider unifying soap and http at this protocol level so we no
longer need to wrap one in the other in order to cross between systems.

I know the soap and http cultures have some distance between them, and I
know that there are technical difficulties as well as dangers of polluting
nice pure architectural style, but it seems to me that to have a run up
towards a new major version as important as http with a rollout that will
take decades to complete that making peace between the political and
technical needs of a few warring factions sold not be too big an issue to
consider biting off.

Maybe I'm crazy and/or naive :)

> 3) HTTP security controls should only secure content. Signing headers
> is not only difficult, it is often counterproductive. If a Web service
> depends on information in a header there is probably something wrong.

I don't see a point in securing a request message unless it's recipient can
authenticate uri, headers and body as being unchanged from when they were
authentically written on behalf of the user with possible additional
annotations from intermediaries. I don't see the point in securing content
returned from a server unless you are also securing cache control
information that tells me it is still valid and is not done kind of replay
attack, and again various header information is relevant to want to secure.

> >From these I draw the following conclusions:
> * HTTP 2.0 should draw a distinction between routing headers and
> content meta-data
> * HTTP encryption and authentication are necessary independent of TLS
support

It seems to me we shouldn't need two solutions to any given problem. Soap's
tenancy to use custom methods, custom headers, and custom media types (ie
custom schemas) are not things we want or need on the Web, but I find it a
shame to be heading in different directions on basic important things like
signatures and encryption of messages. In the end http and soap at the
message structure level have but a hairl's difference between them. It
seems naively to me that I'd http were to take a step towards soap at that
basic message structure level that other standardisation problems might
become simpler to solve, and that the shared solution could facilitate an
unwrapping of soap messages to be able to be sent potentially as first
class citizens on the web... Although problems with WS-Addressing might be
the first hurdle to cross.

Benjamin