Talk:OpenID provider

Early thoughts

 * Yet another wiki (users.wikimedia.org)? Blehhh.
 * Use Meta-Wiki?
 * Use Commons?
 * Really depends on whether a separate domain is absolutely necessary, I suppose. Are there security concerns here?
 * Tangentially related: Requests for comment/Global scripts.
 * GlobalProfile definitely needs some consideration.
 * This page should probably be located at Requests for comment/OpenID provider.
 * s1 --> scheme 1 seems a bit strange. I'd expect version to be used here instead, but maybe this is OpenID terminology? On the other hand, OpenID itself is versioned, so perhaps scheme is a more sane word choice. Dunno.

Overall, this page looks fine. Thanks for putting it together.

But generally (Wikimedia-wide), we need to think about where we want global things to be. Things in this case refers to global user pages, JavaScript gadgets, Scribunto modules, wiki templates, CSS/JS user subpages, user watchlists, etc. Ideally each of these pieces wouldn't have its own wiki. We already have global wikis (Meta-Wiki, Commons, and now Wikidata). If these can be re-used, they absolutely should be, in my opinion. --MZMcBride (talk) 04:25, 2 March 2013 (UTC)

Though this is indeed a "centralised" wiki, it's not really for shared objects for use on our wikis. That's what we approved the creation of Commons for, not that many of us from then are still around to remember it. Of course, now we have data on wikidata.org rather than on Commons, so in part that boat has already sailed. :-( I don't see the link between non-user-specific items (like gadgets, Lua modules, templates etc.) and the purpose of this.
 * On your points:
 * [Maybe these different questions should be in different sections?]
 * URI location : I don't think we're talking about  being a real 'wiki' in any meaningful way, but I understand the concern about YADW. However, given that we're only talking about supporting global accounts, it would be a real mess to use Meta or Commons which have local accounts still. It's conceivable that we wouldn't run a real MW instance here long term - the OpenID service is all we'd expect this to provide. However, opening it up to other things might be something to do.
 * ResourceLoader 2.0 : (And wider issues about central wiki location of things.)
 * GlobalProfiles : Clearly this will be useful to that; it's part of our thinking here. :-)
 * Page location : I'm not sure this is an RFC so much as a WMF Engineering work-strand page; indeed, I was about to slap a on it.
 * Scheme vs. Version vs. … : I'm not qualified to comment, so I won't. :-)
 * I wanted to avoid version, because it could be confused with OpenID version. I picked scheme so that we'd have another terminology to use for that.--Ryan lane (talk) 23:32, 5 March 2013 (UTC)
 * Scheme ? I don't know if we really need such an additional level. Suggest, not to use it. --Wikinaut (talk) 23:38, 5 March 2013 (UTC)
 * This isn't something specific to the extension. It's meant as a way to allow us to change implementations later. I worry about not having a path to change URL implementations later.--Ryan lane (talk) 23:49, 5 March 2013 (UTC)
 * Thoughts?
 * Jdforrester (WMF) (talk) 20:06, 2 March 2013 (UTC)

Use case?
What is an example of an existing tool that would benefit from this? -- Tim Starling (talk) 04:35, 3 March 2013 (UTC)
 * Any application in Labs in which users must create an account to use. So, all MediaWiki developer instances, for example. nagios.wmflabs.org would also be another example, if we want people to be able to mute alerts and such. We don't want Labs project admins storing usernames/passwords. Having a provider allows us to centralize authentication to services we manage that have a more stringent privacy policy and are managed by a team of people required to have signed NDAs. We can also achieve this by using faux OAuth authentication, but there's way more client support for OpenID authentication than OAuth faux authentication.--Ryan lane (talk) 22:31, 5 March 2013 (UTC)