I've updated my Liberty ID-WSF Open Source Toolkits again. This time to reflect the minor changes made in the Advanced Client specifications as they were finalized within the Alliance. For those of you who aren't familiar with this code, I have two toolkits available -- a C++ client and an Axis1/Java Server -- which implement the Liberty ID-WSF protocols (both the basic framework and substantial portions of several services). This new release of the toolkit does not add new functionality -- it only

Paul Trevithick just announced that Higgins will start developing a SAML 2.0 compliant card selector, that will - in addition to Windows CardSpace compatible i-cards - support SAML 2.0 compatible "s-cards" [1] . This will be quite interesting to follow, in particular if Higgins really supports the SAML 2.0 protocol (not only the token format). In that case it would really step up to be part of the identity meta system (actually: the Aleph 0 Identity System ). PS: Welcome in the blogosphere, Paul!

To date, the vast majority of real-world federation roll-outs have been internal or enterprise type deployments. Things like an enterprise authenticating its users out to an outsourced provider (such as a Fidelity 401K, or AOL's Radio Service). Yes there are many exceptions to this general statement (you can see many of them on Liberty's Adoption Page ), but that is the general view of the industry and I certainly don't knowingly use federation in any cross-provider operations. The time has come

The second draft of the Liberty Advanced Client Technologies set of specifications has been published on the Liberty Alliance web site. For those who aren't aware, the Advanced Client Technologies work is the 3rd generation of client technologies coming out of Liberty. The first generation was work that enabled a Liberty-aware client and/or proxy to participate in the SSO transactions (similar to what Cardspace does today). The second generation enabled active clients to act as WSC's in identity

I recently received a comment on my SAML Bashing blog entry. "Jeremy" (not sure which Jeremy as he was otherwise anonymous in his comment -- I wonder if it's really James in disguise -- this seems the kind of comment James would leave, but James is usually quite blatant about it, not hiding behind an identity pseudonym) asked: Kim stated "The question of how the relying party knows which identity provider URL to use is open ended. In a portal scenario, the address might be hard wired, pointing to

James McGovern writes about how relationships must include authorization: Anyway, the notion of relationship is something that belongs to the identity provider and entities such as the Liberty Alliance are defining standards around it. Check out their notion of the people service. The key though is that relationships sometimes require authorization. For example, just because my son can order an insurance card from Amica doesn't mean he is also allowed to cancel the policy for the entire family. Relationship

In Tools to sniff and clone cookies Stephan Brands writes about a scene at a recent Black Hat Security conference where a presenter was able to steal live sessions by sniffing cookies on open internet connections and concludes: The message for those working on digital identity solutions, in particular “lightweight” identity solutions and plain-vanilla browser identity federation a la ID-FF, should be clear: unless asymmetric cryptographic protection is made an integral part of a solution, users are

A recent article on the Teknision blog complains about the pain it is to build and maintain social networks again and again on one site or another: There is something very wrong with the web…… I wonder how many times I have had to find and add Gabor Vida, Steve Mackenzie, Ryan Stewart, Mike Chambers, Phillip Kerman, Mike Downey, Mike Potter, Stacey Mulcahy, Ryan Murphy, Mykel Ruvola( and on and on and on and on) in the last few months. I have spent a huge amount of my time across social networks