- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Sun, 14 May 2000 05:24:43 -0400
- To: "Anders W. Tell" <anderst@toolsmiths.se>
- Cc: Henrik Frystyk Nielsen <frystyk@microsoft.com>, dick@8760.com, Dave Winer <dave@userland.com>, "Wesley M. Felter" <wesf@cs.utexas.edu>, Edd Dumbill <edd@usefulinc.com>, xml-dist-app@w3.org
On Sat, May 13, 2000 at 09:58:44PM +0200, Anders W. Tell wrote: > Henrik Frystyk Nielsen wrote: > > > SOAP doesn't define *a* security policy because we expect that there is > > need for multiple policies and even capability for negotiating which one > > to use depending on the context (commerce, medical etc.) but that is not > > for the base SOAP to do. > > You mentions that SOAP defines [no] "security policy" but what is SOAPs relation > to > the much larger concept of Security Architecture which have far reaching > consequences regarding RPC/Messaging in general ? It is easy to imaging a mapping of digital signatures into standardized (conventionalized) SOAP headers. SOAP provides all the boundries and identifiers you need to test a checksum over a range of XML. A widely adopted header and schema would provide interoperable security (allowing generic auth agents to provide security for an opaque payload). I beleive that SOAP has the appropriate scope in not natively addressing security/authentication. As far as I know, the most famously vulnerable RPC mechanism has beens Sun's RPC, not because it was hard to implement security within RPC, but because the security functionality was added when there was already a considerable multi-platform codebase. Retrofitting this code provided many tedious security holes in critical protocols like NFS which were originally writtne for a network of well-meaning geeks. The lesson: I suspect the healthiest lesson is not to say "we need authentication in the serialization layer", but instead "we need to work out a good security model/API before deploying any critical code." If you write an SOAP-based stock broker program and run it over SSL for lack of a good auth module, you'd better think hard when retrofitting it with the finally standardized SOAP-DSIG module. Chances are that strapping in an auth module and complicating the application interaction will expose some vulnerabilities. (Encryption is a harder problem, but I think the work there comes in defining the interaction between the decrypter and the parser.) -- -eric (eric@w3.org)
Received on Sunday, 14 May 2000 05:25:05 UTC