When I was younger, I found out the hard way that I was allergic to certain medications - I got three shots and went into shock. It left me deeply afraid of needles. To this day, doctors need to give me something to bite on when they give me a shot. Dentists, well, let's just say they need to count their fingers.

But we're not going to talk about my insecurities. Instead, we're going to look at a topic that is on most Web services developers' minds. Security is the most vital topic in the Web services space today, so much so that two competing standards have been proposed and are in the process of being implemented by various vendors.

Security Assertion Markup Language (SAML) is a token-passing system that uses XML to describe security assertions and permissions. It was developed recently and turned over to OASIS, which ratified it as an open standard.

OASIS has also produced the Web Services Security (WSS) standard as an alternative approach to SAML. WSS uses XML, but the format of information and the intent of the specification differ somewhat from SAML. Neither specification is a complete analog of the other - there are differences that make neither a complete subset of the other.

What's really important is that Web services products begin supporting one or both of these standards. The ability to secure Web services is one of the key factors that will drive them from the world of trial implementations into a deep deployment model.

Security means different things to different people. Some are concerned with encryption of data over the wire, so that no outside party can snoop on communications between two computers. Some are concerned with the ability to restrict functionality based on user identify, which perforce requires the ability to validate identity, and then to restrict access based on it in some fashion. Still others are concerned about securing Web services using standard tools for the security definition, such as LDAP.

Whatever the issue, one concept is vitally important - the mechanism for Web services security should not be a new, proprietary mechanism. For security of Web services, the protocols and mechanisms need to fit into the overall security architecture of the company hosting the service. The last thing any company needs is a new security paradigm - companies spend enough time and money defining their policies now, without Web services requiring a different tack.

The good news is that the standards pretty much take this into account. The bad news is that products that implement the basic Web services protocols (SOAP, XML, WSDL, UDDI) do not in general provide any type of security (in the form of SAML or WSS) implementation, and typically have no plans to do so. So it looks like Web services will fragment to a certain extent into a group of core service providers and a group of niche players who will focus on topics like security, management, and monitoring. Which isn't the worst of all worlds, but it certainly is a disappointment to those who want the added value of being able to go to a single vendor for all the tools (and of not having two vendors do the finger-pointing game when something fails to work as planned).

Certainly the major players are involved in the specification development, but it's companies like Netegrity who are actually implementing the standards and developing products to secure Web services transactions.

This issue is devoted to a variety of topics around security. We'll try to introduce some of the issues that you'll encounter as you try to deploy Web services, and look to experts from various security-focused organizations, including Netegrity and HP.

In the meantime, I've got to reschedule my dentist appointment. Seems my dentist is getting insecure about giving me shots.