From the start of the OAuth idea I've been thinking we should handle the code in an abstract way. ie: Applications and Authorizations should be something MediaWiki implements internally in an abstract way. And then we write an OAuth extension that extends this and lets you authorize OAuth 2 clients. Things like mass-reverts by application, authorization revocation, and displaying what application was responsible for an edit would be handled from within MediaWiki abstractly instead of being OAuth specific. -- Skip for TL;DR version -- Originally I had some ideas like implementing some custom auth system for other wiki. Implementing OAuth 1.0 in addition to OAuth 2 (at the time it appeared signatures had disappeared and OAuth 2 was worse than OAuth 1 in some cases). And supporting something along the lines of Google's application passwords. I'm not focused on that right now. But I still think it would be a good idea to do. We don't know what'll happen in the future. Someone could write an OAuth 3 that is also not backwards compatible and we want to implement. Or someone could come up with a different standard that does things in a more secure way or supports discovery in a very well thought out way. So doing things abstractly will let us add those as things go along without any trouble. Additionally doing this abstractly allows us to test just small components of the system in an isolated way without needing a whole OAuth stack. -- / continue reading from here -- I had an interesting thought when I was thinking about how we'd do this abstractly. - I started thinking that every user instance should have some sort of ->getApplication()/->getAuthorization() connection. And this would be used when noting what was responsible for various edits/logs/etc... - To make things easy on code I thought that ->getApplication() should always return an Application instance so you don't have to null test it. Under that idea MediaWiki itself would have a dummy Application which would be tied to every standard edit. The database would probably even reflect this. After this I started thinking of separating things a bit more. - By default every blandly created User instance would be tied to an "Unknown" application. - While when a user instance is setup using session data we assign the "Internal" application to it. - As a result of this all dummy edits made through internal code would end up associated with an "Unknown" application instead of the "Internal" one. In other words, we'd finally have a formal way to find system made edits like the initial Main Page edit populated by the installer. That would be an "Unknown" application. The same would go for various extensions that made dummy edits. - To top all this off we could potentially also make a special built-in "Import" application. This would result in all edits made by importing edits from another wiki being nicely annotated in the UI with information saying they were imported rather than actually made on the wiki by said person. What does everyone think of this idea? -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]