Ashar Voultoiz wrote: Yes, I can do that. It should be noted though that this patch may not the best way to do things long term. A couple things: 1) this patch piggy-backs on top of SpecialUserlogin. So if a username contains "://" or '." then the OpenID code kicks in. This does not provide any sort of possibility for other login types, eg LID. Also it would break any pre-existing logins with those strings in them. 2) MediaWiki insists on upper-casing all titles, including usernames. I worked around that for actually storing the username, but it still happens for display,which looks kinda nasty for eg: "Http://danda.videntity.org/". I'm not sure how to get around that as the title normalization stuff is a bit, umm, inscrutable. I'm wondering if someone on the core team could perform a code review of the patch and either: a) give it a tentative blessing, with some pointers for ways to deal with the above issues. b) reject it as "the wrong way" to do things. If it has a tentative blessing, then I'm more inclined to port it to 1.5.0 and do whatever is necessary to make it "right". I figure that even if it is the wrong way, at least it works now for my wiki and anyone else who want to use it, and may prove useful as sample code for someone to do it "the right way", whatever that might be. regards, Dan Libby

Ævar Arnfjörð Bjarmason wrote: I'd be happy to make it an extension if someone can define and add the necessary hooks. I'm curious if anyone has looked at how I added processLogin() to AuthPlugin() in order handle multi-page authorization sequences. I imagine your LID patch must do something similar, eh Johannes? There is still the matter of how to determine that the current login should be processed via OpenID ( or LID, or... ) rather than by the normal MediaWiki login handler. Checking for '.' in the login was a temporary hack. I suppose that each login-type could have its own login page, but that still leaves the question of how/where the user chooses the login type.

On Oct 6, 2005, at 19:50, Brion Vibber wrote: We've been doing some work integrating LID (the "other" URL-based digital identity system) with WikiPedia, and while ugly, even user talk pages work surprisingly well with very few changes, for the LID URLs we tried so far. I guess that will be the same for Dan and OpenID. The MediaWiki code is more robust than we thought ;-) <snip /> That's probably the most appealing route. This would apply to all REST-ful identifiers for authors, and potentially for non-URL-based "outside" identifiers as well, like URNs or XRIs (see the Identity Commons project, which is another personal digital identity effort). The issue here is privacy and what follows from there. Within LID, for example, we have extensive facilities for voluntary "profile data exchange" (see the LID MediaWiki ;-) at http://lid.netmesh.org/ wiki ), so it's very straightforward to determine what VCard calls the "Formatted Name" for a user, but experience shows that people don't necessarily want others to see their real name in public places such as Wikipedia. Also, there is a namespace issue. The reason DNS is hierarchical is that there are simply too many things that need to be named to be in one, flat namespace. As Wikipedia grows to, say, include every graduate student ever (kindergartener?), how realistic is it to stay with a single-level name space? And the whole point of OpenID, LID, and all the internet-scale identity efforts is to get away from local pseudonyms that need to be invented because somebody else took john.doe already at that site. I'm afraid that I don't have a full-fledged answer here (not sure anybody does), except for the maybe-not-so-trivial one: what if users with REST-ful outside identifiers don't get a talk page?!? Chances are that their REST-ful identifier actually refers to their blog, or some place where people can leave comments ... Other than User:xxx, where else would something break? It's easy to format, say, SpecialListusers differently if it is a URL ... Account federation with local pseudonyms... let's not do that, it's a kludge and not worth the effort ... So much for now ... Johannes Ernst http://netmesh.info/jernst Johannes Ernst http://netmesh.info/jernst

Brion Vibber wrote: Ouch. So clearly a better solution is needed for the user to specify which type of Login system to use. I've seen a couple sites that have a dropdown selector on the login page for the user to pick the login type. That seems pretty clean to me. I worked around this issue by forcing URLs to always use the "?title=" format if the title contains "/". Otherwise there were problems with Apache (php?) munging "//" in the PATH_INFO variable into "/". It was a pretty simple check in Title::getLocalURL(), not much of a tangle. afaik, user talk pages are working fine for OpenID logins. Also, that seems like an issue that would affect any titles with "//", but probably it is not a common case so possibly no one has run into it yet. Interesting. I wasn't aware of the distinction. I'm not sure it is so easy actually. This approach would seem to defeat much of the benefit of OpenID if it is not automatic. Who wants to login with their universal ID only to have to choose a local ID? The difficulty with an automatic approach is guaranteeing a transform that looks nice and yet is still unique. For plain http:// urls, you can get rid of the "http://" portion because it is assumed, but you can't do that if the url starts with "https://".