# I assume that does OpenID, LID and YADIS given the development you # guys have been doing on those areas? Nope. It's an OpenID-only patch. # Is it just Relying Party support, or does it also enable registered # Wikipedia users to use their Wikipedia identity with other places? The patch lets people use their OpenID identities to authenticate to MediaWiki; that's all. -- Jonathan Daugherty JanRain, Inc.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Daugherty wrote: Maybe they should be asked to give a local "alias" for this purpose? (ie, they login with their OpenID, but edits and other portions of the code use their alias.) - -- Jamie - ------------------------------------------------------------------- http://endeavour.zapto.org/astro73/ Thank you to JosephM for inviting me to Gmail! Have lots of invites. Gmail now has 2GB.

On Mon, Jan 30, 2006 at 04:43:19PM -0800, Jonathan Daugherty wrote: Hi, Jonathan. I'm at RecentChangesCamp right now, and I've just heard a good presentation about OpenID and Mediawiki. I think this sounds like a really cool patch, and I'm going to check it out, but I think from my point of view, the most important application for Mediawiki users is single-signon for multiple wikis. Mediawiki as a consumer of identities, and not a producer, isn't very useful for this. I also want to point out that there are now thousands of small, large, and medium-sized wikis using Mediawiki, and that they'd probably all benefit from a federated signon solution. Also, OpenID seems to me prima facie as a pretty good solution to single-signeon for Wikimedia. It seems like identity on Wikimedia sites is really tied to a particular site. People say, "I'm X from French Wikibooks" or "I'm Y from English Wiktionary"; I think Wikimedians could absolutely live with namespacing around a "base" project. So I wonder: considering that single-signon is such a hugely requested feature for Mediawiki, and considering that OpenID is a lightweight solution that would allow SSO not only for Wikimedia sites but for Mediawiki sites across the Web, would we Mediawiki developers think about using this solution along with or instead of custom-built solutions that require access to the same backend database? I'm going to try to work with this patch to get an optional piece of code that's suitable for checking in to CVS. ~ESP

On Tue, Jan 31, 2006 at 04:33:38PM -0800, Brion Vibber wrote: Brion, Why not use OpenID FOR the Wikimedia single-login? ~ESP

Brion Vibber <brion@...> writes: Brion, Hi. I'm an engineer at JanRain, Inc. We have been developing Internet identity systems for a while now. We specialize in OpenID. I think that OpenID can meet your stated requirement. Is there a list somewhere of the other requirements for your authentication solution? I think that regardless of your requirements, there is an existing technology out there that can meet them. We are willing to do a lot of engineering to help wikimedia use an existing technology. It seems to me that a wikimedia.org OpenID server would provide the namespace that you are looing for. It would also provide your users with an Internet-wide identifier at the same time. Josh

Brion Vibber wrote: You could settle on one master namespace (wikipedia.org?), then gradually roll sites over to only accepting logins from that namespace, giving people the option along the way of merging their old separate identity histories into the new master login(s). I suspect OpenID could help with the cross-domain logins, even if a final single namespace is the only one accepted for logins. I'd also guess that after starting to unify, there could be a backlash when people start losing their logins. Multiple namespaces might then seem more appealing. Is there a page or past thread capturing prior discussion and decisions about the single-signon goal? - Gordon

Gerard Meijssen wrote: Picking any one namespace as the starting space does not rule out any application on any Wikimedia project. In any unification -- completely independent of technology used -- it would be natural to start with the one existing namespace. Maybe the largest/most-active, or perhaps the namespace which overlaps all others the most, or perhaps the namespace with the most unique names. You'd then work outward resolving conflicts with other namespaces one by one. And, despite starting with the largest (or most-overlapping or most-unique), that namespace wouldn't necessarily win most conflicts. (It might lose most, because its size means a longer tail of seldom-used accounts.) I'm guessing the Wikipedia projects are still largest (and also have the most overlap with others and the most unique names), but would be interested in pointers to any numbers which suggest otherwise. (If existing project names are loaded with politically undesirable semantics, perhaps the best course would be to pick a relatively cryptic, semantically-unloaded 'name' for the unified login -- "WMLX" or some such, which is vaguely but not really an abbrieviation. Then start rolling other legacy namespaces into it. ) My point is the same: you can pick a single namespace, and wind up with a single namespace at the end of the transition, completely independent of the technology used. Some people seem to be assuming that OpenID/YADIS *necessarily* means allowing signins from multiple and/or foreign namespaces. By my understanding, that's not the case. I can't tell which of the three options listed at http://meta.wikimedia.org/wiki/Single_login_poll had the most developer support, but SUL-2 and SUL-3 both seem to suggest a transition phase where global and local coexist for a while. That would seem a natural application of the OpenID/YADIS approach, with a single global namespace exporting itself to any number of projects which accept global logins, but still have legacy local logins as well. I thank Rob Lanphier for providing a link to the Single_login_specifications page at Meta. - Gordon