This amounts to a real conversation now on this subject, with Phil Windley, Marc Canter, Bob Wyman, and now Pat Patterson chiming in:

Pat writes that in his experience, the dynamics between identity providers and relying parties may be quite complex:

...In the B2C world, it seems likely that the role of identity provider will naturally gravitate towards the big guys - maintaining a secure identity infrastructure is expensive - scale provides natural economies...

...On the other hand, in the B2B arena, the dynamics may turn out to be the reverse, as relying parties (service providers) ... may take the driving seat, implementing a range of protocols as they implement federation with a range of their customers.

Let's take this a step further. If user-centricity is really what we are after, it follows that I am my own identity provider in many circumstances, doesn't it? (Even if I let somebody else manage the server that runs the code and stores the data.) There seems to be a C2C model as well. What might the dynamics be there? That's the truly decentralized, peer-to-peer version of identity ...

John Merrells of SXIP and others have been asking for an update on my XML-RSIG (as in "really simple XML signatures") proposal. Here you are...

Phil Brooke so far has produced the most comprehensive paper on XML-RSIG, at 14 pages! (it's in PDF, download here). He performed a systematic evaluation and suggests a number of improvements, such as:

• converting the last white-space character of lines to hexadecimal form, such as  , in order to prevent OpenPGP from removing trailing white space
• using ASCII-armored signatures only
• making a signature node generally the first child node of a parent, in order to optimize processing
• including any included content from an XInclude statement when processing the signature
• always use UTF-encoding
• signing and verification operations should be in "text" mode.

His paper is worth reading. It appears that he has not found any XML-RSIG show-stoppers in his experiments, and I very much appreciate his suggestions.

Also, John Kemp told me about a recent article he wrote titled "XML Signatures in PHP", which makes the case that while XML-DSig is hard, it is maybe not as hard as some people may think. He has some example code how to connect Aleksey Sanin's XML Security Library to PHP, and use it to sign XML in a web context, e.g. from PHP, using XML-DSig.

Based on this and previous feedback, I'll produce a revised proposal some time soon.

On the heels of Phil Windley's post (I commented here) comes Bob Wyman's post on the same subject. In response to Marc Canter, he says:

Marc Canter ... mentions that PeopleAggregator will support a wide range of "identity" systems ... Basically, if a system exists and has anything to do with identity, Marc's folk appear to intend to support it...

This is a rather drastic but very rational departure from the customary practice of only supporting a single identity system per site...

I think Marc has been talking about this at least since last summer, but of course I very much agree with the sentiment. Protocol wars are for geeks and we-will-take-over-the-world plotters, interoperability is what matters to the end user. Which is why MyLID.net and NetMesh InfoGrid are now multi-protocol, already supporting three identity protocols in the same easy-to-use package.

From a Higgins talk at EclipseCon.

Higgins is a software framework that integrates

• identity data
• profile data
• relationship data

within and across multiple systems.

This quote, and the accompanying 6 slides are the best summary of what Higgins is all about that I have seen so far. Recommended.

Download PowerPoint slides.

Phil Windley has summarized an e-mail conversation between himself and myself, on the question of multi-protocol identity implementations.

So far, I believe MyLID.net (Sign up!), the hosted identity service that we are running at NetMesh, and its equivalent InfoGrid LID software implementation, are the only multi-protocol, user-centric identity implementations there are: they support LID, OpenID and Yadis in the same, tightly integrated package. So Phil ponders whether or not multi-protocol implementations will become common-place, and whether it is more likely that Relying Parties become multi-protocol, or identity providers.

Among other things, he writes:

• There will be hundreds of identity providers and I'll have accounts at dozens of them. Still, I don't want to pick which identity provider I choose to use for a particular task according to what protocol they speak (that should be below the radar) but rather according to other "business" criteria. I may choose to use my Amazon account sometimes and my BYU account other times.
• As a relying party, I don't want to have to worry about which scheme to use. In fact, I care more about what conclusions I can draw from the authentication protocol used and the data it provides than I care about the specific protocol...
• Relying parties will want to support multiple authentication schemes and need software and systems to do it.
• Identity providers will compete to support as many as possible in order to be as "full service" as possible.

I guess I agree with all of these conclusions. The history of TV or even power chords is a great example: different standards evolved in different sub-markets, but instead of one sub-market suddenly switching from 110V to 230V (or vice versa), or from PAL to NTSC, modern TV sets understand all of those and the user can simply "plug in" their device without worrying about what's underneath.

This is of course a vision we want to help achieve for user-controlled identity, which is why we have implemented all these protocols in the NetMesh code base already, and why we (and I myself personally) am so engaged in driving convergence ...

This development snapshot allows you:

• to build websites that accept LID, OpenID and Yadis URLs as a form of identification.
• to host your own LID, OpenID and Yadis URLs. This most recent version is in PHP.

It is licensed both as open-source and as commercial software, depending on your preferences.

There are also new web-based administration tools that allow you to create accounts for users, categorize them into groups, serve different information based on the group that a user belongs to etc.

For example, you could say "I only want people who have signed an NDA have access to the document at URL http://example.com/secret-document.doc". If so, you can create a group called nda and assign those people (actually, their identity URLs) to it who have signed an NDA.

There's a template called FirstSSO that makes it real easy to create an access-protected website. Because it is a template, you can decide which features should be included in your website. In my opinion, one of its coolest feature is the way it handless access control:

In the NDA example above, you simply would upload the document to the server with name secret-document%nda.doc, and it is automatically only accessible to people in the group nda. Even a non-technical document author / website owner can do that!

Download from the NetMesh Developer's Site and enjoy. Note that this is a development snapshot, and so expect bugs. Feedback appreciated.