- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 22 Jul 2003 16:42:56 -0400
- To: "Ian B. Jacobs" <ij@w3.org>
- Cc: www-tag@w3.org
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