My father said the other day that there are too many WS-* specifications. I've seen similar opinions expressed all over the web. I don't agree that there are too many - they are just too visible, at least for now.

If you check out the WS-Security spec page on MSDN, you'll find no less that ten specs. Ten! Sounds like a lot until you consider how many different types of security operations there are - i.e. many more than ten. WS-Security specs map to those existing operations in a way that is both standard and composable. Each spec, taken on it's own, is actually pretty simple. Something like WS-Trust seems really hard, until you realize it works pretty much like Kerberos. I.e. in order to access a secure web service, I obtain a security token from a security token service. Substitute "ticket" for "security token" and "KDC" for "security token service" and you pretty much described Kerberos (note to kerb wonks - I know there is much more to kerb than this, but I'm simplifying to make a point). Similarly, WS-SecureConversation has a lot in common with SSL in that both are used to create a shared security token that is used to secure multiple messages as part of a single conversation.

What makes the WS-* specs so daunting is their visibility. Technologies like Kerberos and SSL are buried in the platform by now. Want to use SSL with HttpWebRequest/Response in the CLR? Pass https:// instead of http:// to WebRequest.Create(). No need to read the 90 page SSL protocol spec - you can even remain ignorant that it's actually called TLS, not SSL. Need to authenticate a user using Kerberos over a custom protocol on Windows? Use the SSPI context management functions from the Windows API instead of implementing the 122 page Keberos spec (I can't find it now, but I'm fairly certain SSPI will be wrapped in managed code in the next release of CLR). But using WS-Security, WS-Trust and WS-SecureConversation today means having to handle a lot of the gory details. WSE2 is a start, but we have to wait for Indigo before these WS-* specs get buried.

The WS-* specs are also more visible because they are designed to be composable x-plat standards. That means lots of churn under the harsh public eye of the entire industry. Mistakes get made and fixed with everyone watching. However, the visibility comes with the territory - you can't have x-plat standards if you don't have the public scrutiny. Otto Bismark once said "People who love sausage and people who believe in justice should never watch either of them being made." Let's add x-plat standards to the list along with justice and sausage.

Most of us can safely observe the evolution of the WS-* specs from a distance, waiting for the platform to catch up before trying to tackle secure, transacted and reliable web services. For the early adopters, well, if you play out on the bleeding edge, you've got to expect a little blood once in a while. :)