[
Lists Home |
Date Index |
Thread Index
]
Why isn't it a RESTful solution to have the client encrypt the data (using
an applet on the original page, or some Javascript or something else) and
POST the encrypted data (encoded in base64 if necessary) to the HTTP server?
Only the backend program (running inside the firewall perhaps on a different
machine) would know how to decrypt the POSTed data. It could still return a
URL representing the resulting resource, etc. I think this handles both the
wire security and web server security issues. There is then some kind of
key exchange issue, presumably with some standard solution, as long as there
is one which does not require the program which eventually decrypts the data
to call back to the encrypting program. It should be clear that I'm
speculating, not speaking from authoritative knowledge, here!
Jeff
----- Original Message -----
From: "Miles Sabin" <miles@milessabin.com>
To: <xml-dev@lists.xml.org>
Sent: Wednesday, July 03, 2002 4:27 PM
Subject: Re: [xml-dev] ANN: Building Web Services the REST Way
...
> The law isn't arbitrarily and unreasonably frustrating the ambitions of
> RESTians ... the law is mandating good security practices. If REST/HTTP
> isn't up to the job, then so much the worse for REST/HTTP.
>
> But as I said, I don't believe this is a problem with REST per se.
> Rather then blaming legislators or accusing security practicioners of
> advocating proprietary protocols, why not try and show how RESTful
> principles can be applied end-to-end in this kind of scenario without
> having to trust an intermediary HTTP server?
...
|
