[
Lists Home |
Date Index |
Thread Index
]
Miles Sabin wrote:
>
>...
>
> I'm afraid that doesn't wash.
>
> The law isn't arbitrarily and unreasonably frustrating the ambitions of
> RESTians ... the law is mandating good security practices.
I disagree. These sort of security practices are not uncommon but
neither are they typical. If they were typical, Web-based e-commerce
could not exist. Sensitive data is handled in the DMZ every second of
every day. Are you going to say that Amazon handles its customer's data
irresponsibly because it uses HTTPS?
> ... If REST/HTTP
> isn't up to the job, then so much the worse for REST/HTTP.
REST/HTTP is up to the job. He could do the decryption in the DMZ
(except for that law--oops). Alternately, the back-end system could
support HTTPS instead of whatever proprietary protocol it supports, or
could be wrappered to support HTTPS. The web-facing machine could proxy
the encrypted sockets.
Otherwise, if the Web mapping system doesn't know what data it is
dealing with, it can't do any translation on it. You make it sound like
this is some kind of cop-out but it strikes me as a sort of inescapable
principle of the universe. Would you complain of BabelFish that it
doesn't translate encrypted data properly?
Imagine if Rich asked: "I want to use XSLT to translate some sensitive
XML documents but XSLT implementations are too large to audit and
compile into my secure application so I'd like them to do the validation
on the encrypted data." A reasonable person would say: "You have to
choose:
1. Bite the bullet and audit or trust the XSLT implementation.
2. Give up compatibility with that standard and do it some other way."
There is not an option: 3. "Hand the encrypted information to the XSLT
and expect it to do something useful."
> 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?
I feel like I'm repeating myself: The whole point of REST is the
intermediation (though it doesn't have to be done by a separate piece of
software know as an "HTTP Server"). Either you want it or you don't.
Rich's customers don't. The same goes for all standards. SOAP/XSLT/XML
Schema intermediaries will also not be able to do anything useful with
encrypted data. That's pretty much the nature of encryption.
--
Come discuss XML and REST web services at:
Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
|
