Re: 9 July 2003 draft of "URIs, Addressability, and the use of HTTP GET and POST" available

Congratulations, I think this draft is much improved.  The section on Web 
Services looks fine to me (speaking for myself and not officially for the 
XMLP WG).

There is one area where I have a significant concern, and that's in the 
section on "sensitive data" [1], where it says:

        "The choice for how to protect sensitive 
         data is generally orthogonal to the choice 
         of GET or POST. For either GET or POST, 
         if you wish to protect sensitive data, 
         use SSL rather than plain HTTP."

With respect, I disagree with the first statement and I think the second 
is only sometimes true. 

SSL is an example of connection level security.   Often it is an 
appropriate model and can indeed be used with GET.  I have no problem with 
encouraging its use in such cases.  On the other hand, there are many, 
many scenarios in which connection level security, or the particular 
flavor provided by SSL, are not what you need.  Maybe I need to 
authenticate all the way into some particular application, perhaps because 
some of the software or data queues within my server site are not trusted 
(or for other reasons).  Perhaps I need to present credentials other than 
those supported by SSL, HTTPS, etc.?  Saying "use SSL if you need to 
protect sensitive data" is really an oversimplification.

I think these cases are somewhat like the case of "large parameters", 
which as you say is not directly supported by HTTP.  I think that when 
doing an otherwise safe retrieval it may still be necessary for me to use 
POST if I require application-level security.   Among the ways to do this, 
but surely not the only way, is to use SOAP headers to carry the 
credentials or other information needed by the security infrastructure.

Finally, I note that there are common scenarios in which the "obligation" 
incurred by referencing data is security-related.  An audit trail is the 
most common example.  If I want to get a stock quote anonymously, then GET 
is the right way to do it.  If the stock quote server needs to take note 
of everyone who has accessed a stock quote, then I think the right answer 
is POST.  This last case is covered by your draft, since I am indeed 
incurring an obligation, but it might be worth discussing explicitly in 
section [1].

<original>
The choice for how to protect sensitive data is generally orthogonal to 
the choice of GET or POST. For either GET or POST, if you wish to protect 
sensitive data, use SSL rather than plain HTTP.</original>
<suggestion>
SSL can be used to protect information carried by either GET or POST 
operations.  In situations where use of SSL or other connection level 
security is inappropriate,  POST may be used to carry credentials or other 
information needed to authenticate an otherwise safe retrieval.  Note too 
that access to an audited resource typically incurs an obligation, I.e. to 
have the access logged, and thus must be performed using POST.
</suggestion>

Thank you!

Noah

[1] http://www.w3.org/2001/tag/doc/whenToUseGet-20030709#sensitive

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Tuesday, 22 July 2003 16:45:28 UTC