Sometimes it feels that our unveiling of LID in December last year caused "everybody" to also quickly come up with "their" own light-weight scheme (more probably a side effect of 2005 being the year of digital identity than any conspiracy theories...) After OpenID, the latest entry, published today, is Passel, which was developed jointly "since December 28, 2004" (per announcement to the idworkshop@googlegroups.com mailing list) by people from Ping Identity and Jabber Inc., the two Andre Durand companies.

I haven't had too much time yet to look at the gory details, but here are my observations so far:

• It uses e-mail addresses as identifiers — similar to LID's use of URLs, and certainly much easier to understand than yet another new identifier scheme as some other systems do. Assuming they can make it work — there are some substantial difficulties e.g. with spam filters — that would be a good idea I'd think (Opaque reference in the white paper: "Identifiers are email addresses or other common addresses"... whatever that means.)
• It doesn't seem to be REST-ful (it doesn't treat identies as first-class objects that are addressable as far as I see), but it also isn't SOAP/WS-* based. Hmm.
• Identity requirements discovery seems to be tied to HTML-only content.
• Surprisingly, given where they come from, they don't even mention Jabber once! I would have thought people from Jabber and Ping would tie their system to Jabber/XMPP, not e-mail, along the lines I blogged about earlier.
• Requires the use of https. Sounds like a good idea from a security perspective, but a bad idea from an adoption perspective. (We struggled with this in LID, and decided to allow both, so people could make their own tradeoffs)
• It defines a number of new XML schemas, including a new schema for VCard content. I think that is probably a mistake: while Microsoft can probably force through a new version of VCard content as part of InfoCard, I doubt that Passel can; in my mind, neither is a wise incompatbility with what works already. And neither identity scheme will be successful if the exchange of the actual identity information isn't interoperable. We rather stick with VCards in LID... and gpg, and XPath and and and...
• It claims it complies with all of Kim Cameron's Laws of Identity, although I think this would require more discussion than they have in the current documentation. It's hard to get all the stuff out at the same time ... looking forward to reading more.
• While there are implementations in 4 programming languages (wow!), Java, C#, PHP and Perl, the code they have published on their site is curiously small. (But I'm waiting for their promised improved subversion interface before I take a closer look). I also can't see a Passel demo, or anything that actually puts real usable functionality together like we have with our Lid Demo User and FirstSSO and blog software and so forth. So for now, it seems we have to take them at their word that all the use cases described in the white paper actually work; but given who Passel's authors are: Dave Smith (aka dizzyd) and Peter Saint-Andre, I have no doubt they can make it work, they are very senior and experienced people whom I have great respect for.

But there is one thing that really confuses me:

• Chapter 3 in the white paper is titled "Passel as an Identity Meta-System". It is Ping Identity that paid for Passel, that, two months ago, shared the stage with the Microsoft CTO at Digital Identity World, to announce (and demo) their joint plans around Microsoft Infocard, Microsoft's proposal for an Identity Meta-System. There is widespread agreement in the industry that an identity meta-system is only an identity meta-system if it is ubiquitous and has no competition ... So what do I make out of that chapter 3? From what I can tell, there is basically zero technical commonality between Passel and InfoCard. There must be a simple explanation that I simply fail to see right now. (looking for comments)

BTW, a correction: unlike what the Passel white paper claims, LID does support third-party confirmed assertions (and not just self assertions), using an as we think highly innovative approach that puts a premium on privacy.

But nevertheless: welcome to the club of "light-weight" identity schemes. I knew you guys would eventually come around ;-)

This seems to be a non-trivial problem. Would be great if people reading this had some ideas or pointers to share ...

Say you come across a site that is single-sign-on enabled (such as LID SSO enabled). How does the site communicate...

• to you, a human user, that you might be able to take better advantage of it if you logged in using your LID personal digital identity;
• to a non-human client, such as a software agent, that the good stuff is only available to authenticated users?

We have to look at this in the context of internet scale. Today we don't have widespread SSO on the net, so today this is a somewhat smallish problem. Because we all had to sign up individually with Amazon, Ebay and whatever other sites, we are likely to remember (if not our passwords, at least that we might have signed up somewhere). And if we don't, the login dialog on the front page might jiggle our memories. But once SSO is prevalent across the net, chances are, many more sites will (at least will attempt to) take advantage to know who their visitors are. So many more sites will become "relying parties" than we have sites with a user registration scheme today. How do they tell us that they can? Similarly, a software agent must have some computable form of finding out whether a given site is SSO-enabled or not.

Here are some of the choices I see for the user interface:

1. "free for all": every site does it the way they want, and there is no common look and feel (and behavior) to SSO across sites.
2. "only a common login dialog": here's an example for the tentative LID 2.0 common login dialog:
   
   That allows users to identify login dialogs on different sites as belonging to the same SSO system, but that does neither address how to log back out nor help them remember at which sites they are authenticated if they rapidly click back and forth between sites. (Firefox's and Safari's Tabbed Browsing features encourage concurrent, independent browsing sessions and thus make it even harder for the user to remember where they are logged in and where not.)
"browser bar" with SSO functionality that pops up whenever the user interacts with an SSO-enabled page, similar to the way Mozilla pops up their "site navigation bar" when it comes across HTML tags such as <link rel="Start" href="/">. Here's an example from the CNN website:

The disadvantage of that is obviously that its functioning depends on an installed browser plug-in, and it's also one level removed from the interaction between site and user.
3. Some sort of "style guide" for SSO-enabled websites that they would have to adhere to. For example, one could say: if you want to announce to the world that your site is LID SSO-enabled, put the following logos in the top right corner of your site:
   

   Displayed item	Meaning	Action
   	Understands SSO, but currently not logged in.	Clicking on it leads to a login dialog.
   	Currently logged in.	Clicking on it logs off.

   Alternatively, the currently logged in display could be like this:
   

   http://netmesh.info/jernst

   Currently logged in with this LID identity.

   Clicking on icon logs off. Clicking on URL goes to LID URL itself.

   or some variation of it.

A similar problem exists for non-human clients. One could simply add a new field to the HTML header (but that would then limit the scheme to HTML content). Or one could set a special cookie indicating a relying party. Or one could add a new HTTP header. To us, none of those is very obviously the leading contender.

I'd be very surprised if there wasn't some pre-existing work on that subject, usability studies, that kind of thing. Anybody have any pointers? I'd really appreciate it.