Here's the last post I could find on the subject: > For my part, I'm firmly against joining the "provider but not > consumer" camp. It's of no benefit to anyone . . .
I just thought of a great benefit, however. Consider this true scenario: I want to write a MediaWiki API client for editors; something like the Wordpress Dashboard. Really give editors a modern web experience. I'd want to do this as a Rails app: I could build it quickly and find lots of collaborators via GitHub. But there's one problem: people would need to log in to Wikipedia *through my app*. They'd have to enter their username and password to my app, which would turn around an authenticate via the MediaWiki API. Policy-wise, this isn't a good thing; that is, giving people the message that it's ok to type in your credentials to something other than Wikipedia sites. And I believe that this is why no such app exists. And further, why the only similar apps that have been made were fat clients, and e.g. Windows only. Because then, the credentials stay on the user's computer. But imagine: If Wikipedia was an OpenID Provider, or provided OAuth, then my Rails app would be the OpenID Consumer. It'd send people to Wikipedia to log in, and they'd bounce back and begin using the Rails app. My app would never see any private information. I believe this would encourage a new wave of 3rd party app development; everything from big ambitious projects (like my editor dashboard) to small focussed apps (say, a simple web app just for editing one's talk page). Just thinking out loud here! Robb _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
