WS-Federation TC roundup and thoughts

A proposal for a new OASIS Technical Committee called WSFED was submitted on March 19 for the “continued refinement” of WS-Federation V1.1. Following OASIS process rules, a period of public comment was held; you can see the official comments in these mailing list archives (Sun’s comments are here). The TC proposers will have a teleconference tomorrow to discuss the comments.

Tim Bray has offered some of his trademark bracing commentary, and the Burton Group has blogged some commentary and analysis, wherein they specifically invite further comments.

Some previous analysis of WS-Federation with respect to SAML, on a fairly detailed technical level, can be found on Hubert’s blog. Elsewhere he notes an analysis done by the Danish government at a higher business and technical level, ultimately motivating their selection of SAML V2.0. (A couple of previous posts of mine about SAML2 usage in the public sector put additional meat on the bones of this sort of analysis.)

I’m proud to have been involved in a number of successful convergence activities. In a way, any standards effort that codifies current practice has a strong element of convergence or boiling down, but when it’s an explicit effort to make there be fewer stacks in the world so that usage and deployment can surge forward, it’s really something cool. SAML V1.0 itself converged the S2ML and AuthXML camps. SAML V2.0 converged the SAML V1.x, Shibboleth profile, and Liberty ID-FF streams. It’s not easy to do, and even when the parties are very friendly towards each other, there are challenges. But first, the lightbulb has to want to change.

I can think of a number of activities that could promote convergence. To give deployers of federated identity technologies the best confidence that the results will be useful and interoperable, I personally think that a program of profile, extension, and/or binding definition activities in the Security Services (SAML) TC is the ideal way to go — it comes with long expertise, lots of existence proofs, and even an interoperability certification program run by the Liberty Alliance. But any joint effort that gets the parties committed to addressing overlaps in a standards body would be helpful.

UPDATE 5 Apr 2007: The telecon was held this morning. TC convener Paul Cotton responded to the collected comments by reading from a prepared text that gave the same answer 30 times: “Proposed response: no changes to the WSFED TC charter are required.” The sole exception was to accept the comment noting extraneous characters. Message received loud and clear! :-) Further reaction can be found at Paul’s place and in comments at the Burton blog.

UPDATE 11 Apr 2007: The comment resolution log has been posted.

No tags for this post.

2 Comments to “WS-Federation TC roundup and thoughts”

  1. curious 14 April 2007 at 11:17 am #

    Curious if you have seen http://duckdown.blogspot.com/2007/04/federated-identity-and-industry.html

  2. Eve 14 April 2007 at 2:19 pm #

    Hi, James. :-)

    Seriously, I hadn’t seen it yet, but I think the point about working with a knowledgeable counterpart in each of the other domains you’re federating with is an important deployment consideration, both initially and in an ongoing fashion — as certificates expire, for example. (However, I don’t think this is the top barrier to federation.)

    Where everybody could probably do a much better job is in planning for the long term in such a relationship, so that there’s an understanding of regular maintenance and hygiene rather than dealing with fire drills all the time. This problem isn’t unique to identity federation, but there’s no doubt a special list of tasks that would be involved compared to other IT activities.