OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] ANN: Building Web Services the REST Way

[ Lists Home | Date Index | Thread Index ]

Paul Prescod wrote,
> Miles Sabin wrote:
> > 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 reading habits and credit card details were as sensitive as medical 
records then Amazon would be. But they're not.

> 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.

Hmm ... that's either avoiding the question (decrypt in the DMZ) or 
refusing to acknowledge the practical problems of auditing an HTTP 
server (backend supports HTTPS/proxying).

> 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?

No, but I would trust it with my credit card details either, never mind 
my medical records.

> 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."

Not a good analogy. XSLT transformations can be done offline where all 
inputs and outputs can be tightly controlled. Offline HTTP servers are 
... ahem ... not terribly useful.

> I feel like I'm repeating myself: The whole point of REST is the
> intermediation

This is news to me. I thought that resource modelling was the whole 
point? And if it isn't already obvious, the issue here is that the way 
that resource modelling is realized in HTTP(S) leaks information.




News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS