WS-KindofInteresting

Sun and Microsoft recently announced some fruits of their relationship in the identity management and web services space, the wonderfully named WSSOMEP (I think they missed out on the chance to call it SOME (Sign On Metadata Exchange))

WSSOMEP defines how WS-MetadataExchange can be used to determine which Single Sign-On protocol suites (SAML 1.1, ID-FF 1.2, SAML 2.0, WS-Federation, etc) your partner is capable of supporting so that the two of you can actually do something interesting (like enabling SSO for your customers, employees, etc).

WS-MetadataExchange defines a SOAP-based request/response protocol. Fundamentally, one provider says to the other 'tell me what you can do'. If the returned list includes something that the asking provider can also 'so', then we have an intersection of capabilities and we're off to the races. If no intersection, no way forward.

Once you work out the intersection, obviously you don't forget it the next time you want to do SSO so this mechanism is a one time deal between provider pairs (maybe you'd ask for an update occasionally to make sure you aren't falling behind the technology curve)

So this is one way to address the 'what can the other guy do' issue. There are others. Here is my list:

ask the other guy (WSSOMEP model)

look it up (metadata file at well-known location)

ask somebody else (UDDI)

trial and error, e.g. use one of the suites and, if it works, fine. If not, glean something from the error message

What others are there?

For Liberty's ID-Web Services Framework, the Web Services Consumer (WSC) is able to discover versioning support of its eventual partner Web Services Provider (WSP) by interacting with the Discovery Service. The knowledge it gains about the capabilities of the WSP is implicit however, it never explicitly asks the question 'what can the other guy do' but rather 'give me everything I need in order to talk to the other guy'. The 'everything I need' includes the required versioning info.