The old pardigm that security is implemented at the network layer by network engineers is no longer relevant thanks to the disappearing security perimeter. HTTP tunneling has rendered the DMZ model ineffective - firewalls are of course useful but for protocol containment and packet elision - but not security. What's needed are syntactic XML firewalls and semantic XML IDS systems. The former passes/rejects XML's based on DTD - the latter rejects/alerts based on a knowledge of business process. This requires a different type of architecture than the currently pervasive client/server systems.

Security as a process leaves network-centric security departments floundering to understand let alone meet business requirements for FC application security architecture.

Yes But!

All the XML security strategies seem to do is shift the burden from the network to ... the network data format language?! The notion that one can do security at the XML layer is based on so many tortuous presumptions that one wouldn't know where to begin...

How much semantic content can one put into these generic tools? How many IDSs and DTDs ever get completed? Are we saying that we can only use an XML protocol if we can also buy a semantically qualified XML firewall appliance for it?

End-to-end security seems to be a given. I've not found any silver bullet that chambers my security gun.

And, XML itself doesn't seem to change the security equation any more than presenting a label to concentrate attention on, for cataloguing purposes. If anything, it makes security much harder, as building security into XML protocols becomes rapidly more complex; as seen in digsig and crypto efforts...

(Please, someone, anyone, tell me how to put a digsig on my XML-X packets... :-)