It’s a cool idea, don’t get me wrong. But what happens when 99.9% of the YADIS sites turn out to only support OpenID and not LID? The momentum behind OpenID, as far as I can tell, is blogs and blog-related sites. In many people’s minds, LID is just way too heavy-weight for that kind of application.
Mostly I fear that YADIS will lead to Canterism — the attempted support of anything and everything to the point that nothing ever gets done.
The idea here is to improve things for end uses once we’ve accepted the assumption that there are going to be several identity schemes for a while. We don’t want user interfaces which require the user to understand the differences between OpenID, YADIS, TypeKey, [whatever].
It’s a fair argument that users will perhaps be more confused when they get back an error explaining that their site doesn’t support the particular flavour of YADIS that their identity provider does, but I’d like to think that sites would go to the effort of making things better for their users and supporting all of the commonly-used systems, especially since there are ready-made libraries out there that can just be plugged in. I added OpenID consumer support to one of my employer’s webapps in less than half an hour.
The opposite approach, which is an equally valid solution, is the use of identity proxies which act as a gateway between systems. I wrote a couple as a proof of concept in the early days of OpenID. This puts the onus on the identity server rather than the consumer.
As for the Canterism complaint, YADIS has a very well-defined role and people resisting its smearing. It’s not attempting to support everything, it’s just providing a mechanism for things that don’t support everything to figure out what they have in common.
Ok, well, I’m totally onboard with the notion that URLs make for a much better identifier than some of the other alternatives that various identity systems have been pushing. And just so we’re clear, I don’t mind the way YADIS is implemented at all. It’s abundantly simple, really, which is cool. I miss all-lower-case XML elements, but that’s just me being all OCD.
What I do object to, is the inevitableness of having to support every identity system out there, on the off-chance that someone chose to use system Z instead of system A like everyone else. And since not every system will have libraries for every language, that’ll be a colossal pain. Personally, I’d rather just have the protocols and systems and such fight it out, winner-take-all, may the best man win.
Imagine what’d happen if you needed to send someone an email, but first had to figure out which of the 17 different protocols their email provider supported. If things had turned out that way, I wonder if email would still be considered the “killer app” of the internet.
Really, it’s the entire issue of “providing a mechanism for things that don’t support everything to figure out what they have in common” that I don’t particularly agree with. Long-term, I don’t see it working out that way. What happens when your client supports LID and i-names, and my server only supports OpenID and sxip? It’s all fine and good when there’s some intersection of capabilities, but eventually someone has to bend in the name of interoperability. But now, instead of people switching towards the mechanism with the most momentum, which will eventually coalesce into a viable “industry standard,” we’re going to get something that’s closer to the current state of web feeds today with, what? 9 different varieties of RSS, several of which are based on RDF and are more or less incompatible with the others, 2 major versions of Atom, CDF, !okay/news, several text-based feed formats, and who knows how many different variants of those formats that are only used by their respective creators. Ask any of the parser people around here how much fun that is.
Email, in contrast, has SMTP.
I’m really starting to think that what it comes down to is this:
People smell the money. They know its there, and they want a piece of the pie. Identity is a big, big, big deal, and everyone knows it. Lessons of the past, such as Passport have been learned, and people have some good ideas about how to avoid the pitfalls. But they’re all having these ideas at the same time (because, undoubtedly, the time is right), and now, instead of all getting together and working on a single spec that handles the important parts well and allows for extensibility, we’re working on 800 different systems, that are only compatible with each other in the sense that their separate implementations can probably manage to sit together on the same server.
If I had my way, we’d stick with OpenID (or something very similar) for authentication, and it would allow for all of the extra stuff tacked on top as an optional if-you-need-it kind of thing. But frankly, between OpenID and FOAF, I don’t really see a significant need for anything else, at least in the decentralized authentication arena.
Also, NetMesh seriously needs to stop treating the “(tm)” after “LID” like it’s the “(pbuh)” suffix. Yes, “LID” is your trademark, we get that message loud and clear, no need to repeat yourself.
I don’t mean to be overly abrasive or anything, but identity is a big deal to me, and I don’t want to see this whole “Identity 2.0” thing fall flat on its face from too much bloat. And IMHO, YADIS, despite being simple itself, looks like its poised to turn into a bloat-enabler.
Just so we’re all clear:
I’m not even saying YADIS shouldn’t exist. Like you said, “there are going to be several identity schemes for a while.” But I would hope that the emphasis is on for a while. If YADIS turns out to be a permanently necessary thing, I have a feeling that “Identity 2.0” will be as much of a joke as “Web 2.0”.
What this means is that identity providers need to seriously consider the various protocols and what they offer the end user. I don’t have a huge problem with being able to consume all or most of the different identity varieties. But we should be a lot more careful about what sort of identities we serve up. Think of it as Postel’s law if you like. Or better yet, the DRY principle.
I’d like to invite everybody who has implemented either
1) an entire identity system, or
2) a single-sign-on system/protocol, or
3) a capability of some kind that’s higher up the stack (e.g. profile exchange, authenticated messaging, ... (just using some LID examples here — there are zillion other opportunities))
to “plug their stuff into YADIS”.
The more the merrier — yes, we may have short-term market confusion (e.g. the OpenID SSO vs. LID SSO discussion above, and which will have more implementations) but that exists anyway even without being under the same YADIS umbrella. With YADIS, we get a reasonably well understood mechanism by which evolution and integration can occur. Personally, I don’t care very much about LID SSO vs. OpenID SSO, I just want this problem to be solved because I rather develop more valuable features higher up in the stack. (which was part of the original motivation of Brad and myself to stick our heads together, from which YADIS emerged)
Also note that with YADIS, identity consumers aka relying parties will have a much easier time implementing user, credential and group management, which opens up an entirely separate set of possible new features that can be implemented reasonably quickly.
I just want this problem to be solved because I rather develop more valuable features higher up in the stack.
Likewise. Actually, that’s part of my point. LID seems to be putting things that should probably be further up the stack into the mix. Identity systems currently range all the way from “prove you have this username” to “prove you are Bob Aman, you have SSN 078-05-1120, you live in Webster, NY, and have blue eyes.” The latter is an example of trying to pull things from too far up the stack into the mix, and to some extent, I think both LID and sxip are trying to do this. Instead, I personally think we really ought to be trying to find the One True Authentication mechanism, and then just make it extensible to provide for the additional extra information.
Also, I think it’s a lot worse than “short-term market confusion.” By and large, we’re trying to make these “identities” be uniquely identifying. If there was any lesson to be learned from flickr, it was that there are few things on the net people want to hold onto more than their identities. People will actively attempt to prevent the disappearance from the “market” of an identity system if they’ve already begun using it, even if the mechanism that they’re using is utter trash. Fortunately, thus far, despite millions of these “identities” floating around, the only people who are using them are early adopters.
I’ve thought about it, and thought about it some more, and come to this conclusion:
If nothing else, the inevitable plethora of identity systems can act as additional inverse functional properties (i.e., unique key) by which to identify a single abstract “identity.” As long as we have a way of converting from one inverse functional property to another, the identity stack we pick doesn’t really matter, so long as an open method of authentication is present.
I’ve also come to the conclusion that I was wrong about YADIS affecting the adoption of particular identity system implementations. So I’m going to shut up now.