This is more or less the right list; though it would also be appropriate to mediawiki-l , the list for all mediawiki developers. You might also take a look at what the Identity Commons is doing. I don't understand all of the standards involved, but it involves a richer API than just distributed authentication... http://idcommons.net/technology.html +sj+ _ _ :-------.-.--------.--.--------.-.--------.--.--------[...]

If we did do something like this, we would probably use a standard like LDAP or ACAP rather than a home-grown one. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/> <http://creativecommons.org/licenses/publicdomain/

Hello all On 12 Apr 2005, at 3.15 AM, Thomas Gries wrote: They do look similar; the document does not specify a means to achieve this, but rather a definition of the user-side requirements. So I don't know if this is some centrally managed authentication mechanism, which would be entirely appropriate for WikiMedia's projects and ... less so for the other uses of MediaWiki, or whether it does imply a similar system to Drupal's. While I can see how there is a high convenience factor to just having the MediaWiki community "piggyback" off of WikiMedia's infrastructure, I would submit that making this framework on that can be used on other publishing systems (other wikis, CMSes, blogging systems, etc) would have several benefits: • to users who interact with many different publishing systems, one identity that is both secure and omnipresent is obviously beneficial • specifically to users who might only encounter each publishing system in one installation each, the resistance to registering to contribute is high; they are far more likely to participate in any of those sites, any of those systems, if the "speed bump" which is creating an account presents a more compelling value proposition • to site developers who need/want the features of two different publishing systems for different parts of the site, a user experience involving multiple accounts internal to their site would be quite unacceptable; a unified framework would be one large step towards allowing the site dev to provide a seamless user experience • this may be a little naive, but it would seem that this is only the first of many issues where some communication between the various publishing system development staffs would lead to benefits all around (for system devs reuse of code and "more eyeballs", for site devs more features and greater interoperability, and finally for end-users, again, a more seamless experience, and the ability to leverage their knowledge of how to interact with one publishing system meaningfully to get more out of the others they might work with. Thanks -RS