I believe the OpenID extension is matured to the point where it's usable on the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects.
My preference for this would be to have a centralized wiki for identity urls. The identity urls would be based on user pages. I'm proposing this for a few reasons:
1. It's easier to deal with identity urls in a centralized location, and it allows us to avoid including the OpenID extension on every wiki 2. We could very strictly limit our vulnerability surface on this wiki by only including what's necessary 3. At a later point we could decide to limit all authentication to this location, pointing login links from all projects/wikis here 4. At a later point we could decide to also use this as a global profile location
I'd prefer if we avoid the bikeshedding of the domain name in this discussion, if we are all in agreement over the use of a centralized wiki.
Thoughts?
- Ryan
Is this up for discussion, or are we at the point of planning deployment? It isn't apparent to me why any WMF site would be an OpenID provider.
maiki
On 02/22/2013 11:33 AM, Ryan Lane wrote:
I believe the OpenID extension is matured to the point where it's usable on the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects.
My preference for this would be to have a centralized wiki for identity urls. The identity urls would be based on user pages. I'm proposing this for a few reasons:
- It's easier to deal with identity urls in a centralized location, and it
allows us to avoid including the OpenID extension on every wiki 2. We could very strictly limit our vulnerability surface on this wiki by only including what's necessary 3. At a later point we could decide to limit all authentication to this location, pointing login links from all projects/wikis here 4. At a later point we could decide to also use this as a global profile location
I'd prefer if we avoid the bikeshedding of the domain name in this discussion, if we are all in agreement over the use of a centralized wiki.
Thoughts?
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
<quote name="maiki" date="2013-02-22" time="12:17:25 -0800">
Is this up for discussion, or are we at the point of planning deployment? It isn't apparent to me why any WMF site would be an OpenID provider.
To phrase this differently:
Do you more prefer that WMF sites consume OpenIDs instead of (or in addition to) providing them?
Greg
On Fri, Feb 22, 2013 at 12:40 PM, Greg Grossmeier greg@wikimedia.orgwrote:
<quote name="maiki" date="2013-02-22" time="12:17:25 -0800"> > Is this up for discussion, or are we at the point of planning > deployment? It isn't apparent to me why any WMF site would be an OpenID > provider.
To phrase this differently:
Do you more prefer that WMF sites consume OpenIDs instead of (or in addition to) providing them?
This isn't really a matter of having one or the other. As Marc has mentioned, we need some non-hacky form of authentication for bots, tools, out-of-cluster applications, and non-mediawiki applications.
OpenID as a consumer is a more difficult task for a number of reasons. I like to tackle problems one at a time and making a provider is an easy first step.
- Ryan
<quote name="Ryan Lane" date="2013-02-22" time="14:00:49 -0800">
This isn't really a matter of having one or the other. As Marc has mentioned, we need some non-hacky form of authentication for bots, tools, out-of-cluster applications, and non-mediawiki applications.
Right, figured not, just trying to clarify.
OpenID as a consumer is a more difficult task for a number of reasons. I like to tackle problems one at a time and making a provider is an easy first step.
Reasonable :)
On 02/22/2013 03:17 PM, maiki wrote:
Is this up for discussion, or are we at the point of planning deployment?
The latter. I can elucidate a number of scenarios where that is beneficial, but the primary one from my perspective is that of authenticating for external tools (like bots and webservices) written by community developers. Each of them currently need their own mechanism, have to implement baroque processes to associate a Wiki[mp]edia account, and increase exposure of credentials for the users.
OpenID neatly fixes all that in one, simple to implement, open and well known manner.
-- Marc
RE: https://www.mediawiki.org/wiki/Extension:OpenID (manual page)
Just my few "meta" points:
if you should find bugs so, please file them here https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&...
Open bugs are https://bugzilla.wikimedia.org/buglist.cgi?component=OpenID&resolution=-...
These links are also at the bottom of the info box (manual page).
Questions will certainly soon be answered by Ryan.
Tom (Wikinaut and maintainer of E:OpenID)
On 2013-02-22 4:43 PM, "Marc A.
. Each of them currently need their own mechanism, have to implement
baroque processes to associate a Wiki[mp]edia account, and increase exposure of credentials for the users.
Actually theres been a centralized method of doing that for a while now (TUSC), so each tool is not reinventing the wheel, but open id sounds much less hacky.
-bawolff
P.s. I agree with Marc's comment about meta but didnt want to mention it out of concern for that being considered a bikeshed over which domain (but really meta seems the most logical place)
On 02/22/2013 03:50 PM, Brian Wolff wrote:
Actually theres been a centralized method of doing that for a while now (TUSC), so each tool is not reinventing the wheel, but open id sounds much less hacky.
Oh, cool. I did not know that.
Of course, a /great/ transitional mechanism them presents itself: if TUSC is taught to speak OpenID, then all the tools using it benefit without having to be hacked at!
-- Marc
On 02/22/2013 03:43 PM, Marc A. Pelletier wrote:
On 02/22/2013 03:17 PM, maiki wrote:
Is this up for discussion, or are we at the point of planning deployment?
The latter. I can elucidate a number of scenarios where that is beneficial, but the primary one from my perspective is that of authenticating for external tools (like bots and webservices) written by community developers. Each of them currently need their own mechanism, have to implement baroque processes to associate a Wiki[mp]edia account, and increase exposure of credentials for the users.
OpenID allows you to tell a tool, "I can prove I am User:JohnSmith on Wikimedia". That will work as a standard replacement for TUSC.
Thus, tools like CommonsHelper (https://toolserver.org/~magnus/commonshelper.php) will be able to verify who you are. However, they will still have to do the actual edits/actions themselves. For instance, if you want CommonsHelper to do the actual upload, it's actually done by https://commons.wikimedia.org/wiki/User:File_Upload_Bot_%28Magnus_Manske%29 .
A better solution would be OAuth, which is a more flexible way of letting apps act directly on a user's behalf in confined ways. For example, we could have OAuth scopes for:
* Editing * Watchlist changes * Uploading
and potentially many more. See https://www.mediawiki.org/wiki/OAuth#Scope
Then, using the CommonsHelper example again, if I uploaded something through the OAuth version of that tool, it would show as uploaded by me.
Another good part of OAuth is that individual users revoke an app at any time if it misbehaves.
So OpenID is an interim step (and has secondary benefits), but I think OAuth is the way to go medium-term. People (including Chris Steipp) are already working on this, which is great.
https://www.mediawiki.org/wiki/OAuth
Matt Flaschen
On Fri, Feb 22, 2013 at 12:43 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 02/22/2013 03:17 PM, maiki wrote:
Is this up for discussion, or are we at the point of planning deployment?
The latter. I can elucidate a number of scenarios where that is beneficial, but the primary one from my perspective is that of authenticating for external tools (like bots and webservices) written by community developers. Each of them currently need their own mechanism, have to implement baroque processes to associate a Wiki[mp]edia account, and increase exposure of credentials for the users.
OpenID neatly fixes all that in one, simple to implement, open and well known manner.
-- Marc
To add another possible use case: We recently ran a small survey for readers of blog.wikimedia.org. In one question, we asked the editors among them "Would you be interested in being able to log into the blog with your Wikimedia account?", and 73% (of 137 respondents) said yes.
On 2013-02-22 3:34 PM, "Ryan Lane" rlane32@gmail.com wrote:
I believe the OpenID extension is matured to the point where it's usable
on
the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects.
My preference for this would be to have a centralized wiki for identity urls. The identity urls would be based on user pages. I'm proposing this for a few reasons:
- It's easier to deal with identity urls in a centralized location, and
it
allows us to avoid including the OpenID extension on every wiki 2. We could very strictly limit our vulnerability surface on this wiki by only including what's necessary 3. At a later point we could decide to limit all authentication to this location, pointing login links from all projects/wikis here 4. At a later point we could decide to also use this as a global profile location
I'd prefer if we avoid the bikeshedding of the domain name in this discussion, if we are all in agreement over the use of a centralized wiki.
Thoughts?
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
That sounds awesome. (Being a provider)
When you say centralized wiki do you mean a preexisting wiki, or do you want to create a new wiki just for this? I would certainly prefer to use something that already exists.
-bawolff
Do you intend to cover both SUL and legacy accounts?
I suspect that meta might not work due to the fact that there might be some accounts that were created on meta, but never merged. So either the URL would have to be different from the regular [[User:Xxx]] @ meta, like meta.wikimedia.org/user/sul/Xxxx (SUL account) or meta.wikimedia.org/user/enwiki/Xxxx (nonmerged enwiki-only account, or a new domain should be setup.
On Fri, Feb 22, 2013 at 3:46 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 02/22/2013 03:44 PM, Brian Wolff wrote:
I would certainly prefer to use something that already exists.
Meta would seem to be the natural, if ill-named, target.
-- Marc
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 22 February 2013 12:54, Yuri Astrakhan yuriastrakhan@gmail.com wrote:
Do you intend to cover both SUL and legacy accounts?
I don't think it's worth anyone's time working out a way of supporting non-global accounts, given the on-going work to fix these as part of "SUL finalisation" which hopefully will get some finished soon. See https://www.mediawiki.org/wiki/Admin_tools_development#Roadmap for wider work in this area.
(Please, let's not get side-tracked into discussing whether it should be meta or some other wiki or non-wiki domain.)
J.
On Fri, Feb 22, 2013 at 1:03 PM, James Forrester jforrester@wikimedia.orgwrote:
On 22 February 2013 12:54, Yuri Astrakhan yuriastrakhan@gmail.com wrote:
Do you intend to cover both SUL and legacy accounts?
I don't think it's worth anyone's time working out a way of supporting non-global accounts, given the on-going work to fix these as part of "SUL finalisation" which hopefully will get some finished soon. See https://www.mediawiki.org/wiki/Admin_tools_development#Roadmap for wider work in this area.
Totally agreed. I think it would be a waste of time to support non-global accounts.
- Ryan
----- Original Message -----
From: "Ryan Lane" rlane32@gmail.com
I believe the OpenID extension is matured to the point where it's usable on the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects.
I, too, want to clarify: you're proposing centralizing WMF identity to whatever extent it is not already centralized, and then using OpenID *within MWF*: so that all WMF sites and installed extensions can auth users against our own user database?
Not authenticating users against external OID providers (which, as nearly as I can tell, largely amount to "I am whom I say I am"), or allowing external non-WMF sites to authenticate against our user database.
Cheers, -- jra
On Fri, Feb 22, 2013 at 2:03 PM, Jay Ashworth jra@baylink.com wrote:
----- Original Message -----
From: "Ryan Lane" rlane32@gmail.com
I believe the OpenID extension is matured to the point where it's usable
on
the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects.
I, too, want to clarify: you're proposing centralizing WMF identity to whatever extent it is not already centralized, and then using OpenID *within MWF*: so that all WMF sites and installed extensions can auth users against our own user database?
Not authenticating users against external OID providers (which, as nearly as I can tell, largely amount to "I am whom I say I am"), or allowing external non-WMF sites to authenticate against our user database.
Any OpenID consumer, whether WMF or not, would be able to use us as an authentication provider.
- Ryan
On Fri, Feb 22, 2013 at 2:30 PM, Thomas Gries mail@tgries.de wrote:
Ryan wrote:
Any OpenID consumer, whether WMF or not, would be able to use us as an authentication provider.
There is currently no option, but an option (to restrict serving OpenIDs to certain consumer domains eg. only to our domain) could be implemented.
I see no reason in doing so. If third parties want to allow Wikimedia as a provider, I don't see why we'd object.
- Ryan
To be absolutely clear, this does *not* solve the problem of bots/tools authenticating on behalf of a user. All it does is solve the problem of where a bot/tool authenticates under its own user account and, out of pure courtesy for the community, asks users to prove their identity before allowing them to use the bot/tool. For bots/tools that actually perform edits as the user, OpenID would be useless.
Also, I think Wikipedia acting as an OpenID consumer would be bounds more useful than acting as a provider. That's not to say that having both wouldn't be a good idea, but the consumer side of it should definitely be a priority. Think of sites now like StackOverflow, where creating an account is as simple as pressing a few Accept buttons.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Feb 22, 2013 at 5:37 PM, Ryan Lane rlane32@gmail.com wrote:
On Fri, Feb 22, 2013 at 2:30 PM, Thomas Gries mail@tgries.de wrote:
Ryan wrote:
Any OpenID consumer, whether WMF or not, would be able to use us as an authentication provider.
There is currently no option, but an option (to restrict serving OpenIDs to certain consumer domains eg. only to our domain) could be implemented.
I see no reason in doing so. If third parties want to allow Wikimedia as a provider, I don't see why we'd object.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 2013-02-22 7:20 PM, "Tyler Romeo" tylerromeo@gmail.com wrote:
To be absolutely clear, this does *not* solve the problem of bots/tools authenticating on behalf of a user. All it does is solve the problem of where a bot/tool authenticates under its own user account and, out of pure courtesy for the community, asks users to prove their identity before allowing them to use the bot/tool.
Which coincides to several bots/tools and would generally be quite useful. Quite honestly having bots make edits directly on someones behalf using their account sounds scary.
This would also be useful for test wikis people set up on labs. You could just authenticate via openid instead of creating a new account.
-bawolff
This would also be useful for test wikis people set up on labs. You could
just authenticate via openid instead of creating a new account.
You can already test this here : http://openid-wiki2.instance-proxy.wmflabs.org/wiki
On 02/22/2013 06:33 PM, Brian Wolff wrote:
Which coincides to several bots/tools and would generally be quite useful. Quite honestly having bots make edits directly on someones behalf using their account sounds scary.
For autonomous bots, yes (they should keep using their own accounts). But for tools, it's common on other sites already, and makes sense here. Instead of the API requiring a user password and an elaborate token mechanism, it could just use OAuth.
If an OAuth app misbehaves, a user can revoke it, or (in severe cases) it can be globally denied OAuth access.
Matt Flaschen
On Fri, Feb 22, 2013 at 3:19 PM, Tyler Romeo tylerromeo@gmail.com wrote:
To be absolutely clear, this does *not* solve the problem of bots/tools authenticating on behalf of a user. All it does is solve the problem of where a bot/tool authenticates under its own user account and, out of pure courtesy for the community, asks users to prove their identity before allowing them to use the bot/tool. For bots/tools that actually perform edits as the user, OpenID would be useless.
You're confusing use cases. What you're talking is the use case for OAuth. This thread isn't about OAuth. I believe we have plans to add OAuth next quarter, but if you wish to continue discussing it, please make a new thread.
In cases where a tool is keeping an authentication database, and is not acting on behalf of a user, then OpenID would let the tool eliminate its username/password store.
Also, I think Wikipedia acting as an OpenID consumer would be bounds more useful than acting as a provider. That's not to say that having both wouldn't be a good idea, but the consumer side of it should definitely be a priority. Think of sites now like StackOverflow, where creating an account is as simple as pressing a few Accept buttons.
Sure, it would be great, but allowing authentication as a consumer is a much more difficult step, and we're not ready to take it right now. OpenID as a provider solves some long-standing problems and is a step in the right direction, let's focus on one thing at a time.
- Ryan
In cases where a tool is keeping an authentication database, and is not acting on behalf of a user, then OpenID would let the tool eliminate its username/password store.
This is exactly what I'm saying. It doesn't do this. If a tool has a username/password store, i.e., it uses the username and password of each user, enabling OpenID wouldn't solve the authentication problem. Like I said, it only works in cases where the bot does all of its work under its own account.
Sure, it would be great, but allowing authentication as a consumer is a
much more difficult step, and we're not ready to take it right now. OpenID
as a provider solves some long-standing problems and is a step in the right direction, let's focus on one thing at a time.
How exactly is it so difficult? You just set the configuration option for the extension.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Feb 22, 2013 at 6:48 PM, Ryan Lane rlane32@gmail.com wrote:
On Fri, Feb 22, 2013 at 3:19 PM, Tyler Romeo tylerromeo@gmail.com wrote:
To be absolutely clear, this does *not* solve the problem of bots/tools authenticating on behalf of a user. All it does is solve the problem of where a bot/tool authenticates under its own user account and, out of
pure
courtesy for the community, asks users to prove their identity before allowing them to use the bot/tool. For bots/tools that actually perform edits as the user, OpenID would be useless.
You're confusing use cases. What you're talking is the use case for OAuth. This thread isn't about OAuth. I believe we have plans to add OAuth next quarter, but if you wish to continue discussing it, please make a new thread.
In cases where a tool is keeping an authentication database, and is not acting on behalf of a user, then OpenID would let the tool eliminate its username/password store.
Also, I think Wikipedia acting as an OpenID consumer would be bounds more useful than acting as a provider. That's not to say that having both wouldn't be a good idea, but the consumer side of it should definitely
be a
priority. Think of sites now like StackOverflow, where creating an
account
is as simple as pressing a few Accept buttons.
Sure, it would be great, but allowing authentication as a consumer is a much more difficult step, and we're not ready to take it right now. OpenID as a provider solves some long-standing problems and is a step in the right direction, let's focus on one thing at a time.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Feb 22, 2013 at 4:07 PM, Tyler Romeo tylerromeo@gmail.com wrote:
In cases where a tool is keeping an authentication database, and is not acting on behalf of a user, then OpenID would let the tool eliminate its username/password store.
This is exactly what I'm saying. It doesn't do this. If a tool has a username/password store, i.e., it uses the username and password of each user, enabling OpenID wouldn't solve the authentication problem. Like I said, it only works in cases where the bot does all of its work under its own account.
Let's consider bugzilla.wikimedia.org, for instance. It has its own credentials store. With OpenID as a provider on the projects, it could be possible to use your Wikimedia credentials rather than a username/password specific to bugzilla.
In this situation bugzilla isn't acting on behalf of a user to interact with another application. An application acting on behalf of a user with another application is what OAuth does, not OpenID, and this thread isn't about that.
Sure, it would be great, but allowing authentication as a consumer is a
much more difficult step, and we're not ready to take it right now. OpenID
as a provider solves some long-standing problems and is a step in the
right
direction, let's focus on one thing at a time.
How exactly is it so difficult? You just set the configuration option for the extension.
Feel free to bring this question up in another thread. Please search through the archives before doing so, though. I've answered this question numerous times over the past 2-3 years.
- Ryan
On 02/22/2013 07:31 PM, Ryan Lane wrote:
Let's consider bugzilla.wikimedia.org, for instance. It has its own credentials store. With OpenID as a provider on the projects, it could be possible to use your Wikimedia credentials rather than a username/password specific to bugzilla.
This, alone, makes the case for me. There is support for OpenID: https://github.com/jalcine/bugzilla-openid.
Now, if we could make it possible to edit comments in Bugzilla...
On Sat, Feb 23, 2013 at 8:22 AM, Mark A. Hershberger mah@everybody.org wrote:
On 02/22/2013 07:31 PM, Ryan Lane wrote:
Let's consider bugzilla.wikimedia.org, for instance. It has its own credentials store. With OpenID as a provider on the projects, it could be possible to use your Wikimedia credentials rather than a username/password specific to bugzilla.
This, alone, makes the case for me. There is support for OpenID: https://github.com/jalcine/bugzilla-openid.
Now, if we could make it possible to edit comments in Bugzilla...
I've been thinking about this issue quite a bit since there's a possibility we could use OpenID for Gerrit.
With Gerrit, there's a very manual conversion cost when switching authn/ authz mechanisms...at least if people want to keep their existing account (with its settings, contribs, etc).
I'm curious if other tools like BZ have similar switching costs.
-Chad
On Sat, Feb 23, 2013 at 8:32 AM, Chad innocentkiller@gmail.com wrote:
With Gerrit, there's a very manual conversion cost when switching authn/ authz mechanisms...at least if people want to keep their existing account (with its settings, contribs, etc).
I'm curious if other tools like BZ have similar switching costs.
Would the fact that Bugzilla uses your e-mail address publicly for everything (rather than a separate account name) cause any problems when switching to OpenID?
-- Casey Brown (Cbrown1023) caseybrown.org
On 02/23/2013 02:46 PM, Casey Brown wrote:
Would the fact that Bugzilla uses your e-mail address publicly for everything (rather than a separate account name) cause any problems when switching to OpenID?
It should be careful not to publicize people's wiki email (sometimes private and used only to receive mail) unless they clearly know that's going to happen.
The most transparent approach is probably to ask them to put it in again into Bugzilla at OpenID account creation. It's a little more work, but people know what's happening.
Matt Flaschen
Am 23.02.2013 00:48, schrieb Ryan Lane:
On Fri, Feb 22, 2013 at 3:19 PM, Tyler Romeo tylerromeo@gmail.com wrote:
To be absolutely clear, this does *not* solve the problem of bots/tools authenticating on behalf of a user. All it does is solve the problem of where a bot/tool authenticates under its own user account and, out of pure courtesy for the community, asks users to prove their identity before allowing them to use the bot/tool. For bots/tools that actually perform edits as the user, OpenID would be useless.
You're confusing use cases. What you're talking is the use case for OAuth. This thread isn't about OAuth. I believe we have plans to add OAuth next quarter, but if you wish to continue discussing it, please make a new thread.
In cases where a tool is keeping an authentication database, and is not acting on behalf of a user, then OpenID would let the tool eliminate its username/password store.
Here is a nice figure taken from https://developers.google.com/accounts/docs/OpenID In case you cannot see the figure in the mail, goto section "Interaction_sequence"
OpenID login process
----- Original Message -----
From: "Ryan Lane" rlane32@gmail.com
I see no reason in doing so. If third parties want to allow Wikimedia as a provider, I don't see why we'd object.
There is no potential liability there?
Cheers, -- jra
On 02/22/2013 10:44 PM, Jay Ashworth wrote:
There is no potential liability there?
IANAL, but I can't think of a scenario where allowing a user to prove "I am user X on Wikimedia projects" can create liability; if the client is pleased with the (proven) assertion for their purposes, they can use it. If not, they won't.
-- Marc
----- Original Message -----
From: "Marc A. Pelletier" marc@uberbox.org
On 02/22/2013 10:44 PM, Jay Ashworth wrote:
There is no potential liability there?
IANAL, but I can't think of a scenario where allowing a user to prove "I am user X on Wikimedia projects" can create liability; if the client is pleased with the (proven) assertion for their purposes, they can use it. If not, they won't.
If those are the accepted semantics of the reply, then I retract the concern.
Cheers, -- jra
----- Original Message -----
From: "Ryan Lane" rlane32@gmail.com
Any OpenID consumer, whether WMF or not, would be able to use us as an authentication provider.
So, then, all OpenID guarantees is "this provider says it's the same person it was last time"?
Cheers, -- jra
On 02/22/2013 10:43 PM, Jay Ashworth wrote:
So, then, all OpenID guarantees is "this provider says it's the same person it was last time"?
The exact semantics is, IIRC, "that person has presented credential to us we accept as identifying them as our user $IDENTIFIER". Whether the client trusts that $IDENTIFIER is reasonably stable for their purposes, or that they trust our word, is their call.
-- Marc
---- Original Message -----
From: "Marc A. Pelletier" marc@uberbox.org
On 02/22/2013 10:43 PM, Jay Ashworth wrote:
So, then, all OpenID guarantees is "this provider says it's the same person it was last time"?
The exact semantics is, IIRC, "that person has presented credential to us we accept as identifying them as our user $IDENTIFIER". Whether the client trusts that $IDENTIFIER is reasonably stable for their purposes, or that they trust our word, is their call.
I'm translating that as "yes". :-)
I've always looked with rather a jaundiced eye at OpenID, as it was sold as "you can run your own authenticator service", and that always struck me as "I am who I say I am", which is, obviously, pretty useless, in the general case. (Early examples showed login boxes where you *provided the URL of a random OID provider*; clearly, if the site doesn't trust said provider, the transaction is useless.)
Cheers, -- jra
On 2013-02-23 12:18 AM, "Jay Ashworth" jra@baylink.com wrote:
---- Original Message -----
From: "Marc A. Pelletier" marc@uberbox.org
On 02/22/2013 10:43 PM, Jay Ashworth wrote:
So, then, all OpenID guarantees is "this provider says it's the same person it was last time"?
The exact semantics is, IIRC, "that person has presented credential to us we accept as identifying them as our user $IDENTIFIER". Whether the client trusts that $IDENTIFIER is reasonably stable for their purposes, or that they trust our word, is their call.
I'm translating that as "yes". :-)
I've always looked with rather a jaundiced eye at OpenID, as it was sold as "you can run your own authenticator service", and that always struck me as "I am who I say I am", which is, obviously, pretty useless, in the general case. (Early examples showed login boxes where you *provided the URL of a random OID provider*; clearly, if the site doesn't trust said provider, the transaction is useless.)
Cheers,
-- jra
While that depends on your use case. In many situations it is the user's (and only the user's) problem if the oid provider is untrustworthy. It then becomes the users responsibility to pick a good oid provider. ( giving users security responsibilities - because that has never gone wrong ;). That said, in many ways no different from normal passwords: Users arent supposed to share passwords - users aren't supposed to pick oid providers they don't trust.
What ive always wondered is what happens if your oid provider goes under/otherwise dissapears. I imagine that means you lose your user account all across the internet, which is a scary thought
-bawolff
On 02/22/2013 11:32 PM, Brian Wolff wrote:
What ive always wondered is what happens if your oid provider goes under/otherwise dissapears. I imagine that means you lose your user account all across the internet, which is a scary thought
Some sites, like Stack Overflow, allow you to add alternate OpenIDs, which helps for temporary or permanent downtime.
Matt Flaschen
On 2013-02-23 12:37 AM, "Matthew Flaschen" mflaschen@wikimedia.org wrote:
On 02/22/2013 11:32 PM, Brian Wolff wrote:
What ive always wondered is what happens if your oid provider goes under/otherwise dissapears. I imagine that means you lose your user
account
all across the internet, which is a scary thought
Some sites, like Stack Overflow, allow you to add alternate OpenIDs, which helps for temporary or permanent downtime.
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Presumably you would have to do that before the downtime though as you wouldn't be able to login once downtime starts. So one could easily be caught off guard.
-bawolff
So I definitely see the use case for OpenID as a provider (and as long as everybody is aware that OpenID is not OAuth, I'm fine with that), but I'm not a bot/tool developers. I am, however, a frequent user of the Internet, and I find it extraordinarily surprising that Wikipedia is one of the few sites still out there that doesn't have some sort of OpenID login. My main question is that if we're really taking the time to deploy Extension:OpenID on WMF wikis, why not put in the extra ten seconds to also allow consumers. People keep going on about how the account creation process is ugly and needs to be re-designed, and yet with OpenID it takes three clicks to register an account, and especially with the recent version push Thomas did, it's better than ever.
Some sites, like Stack Overflow, allow you to add alternate OpenIDs,
which helps for temporary or permanent downtime.
E:OpenID does this as well, not to mention you can always set a password and login traditionally.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Feb 22, 2013 at 11:40 PM, Brian Wolff bawolff@gmail.com wrote:
On 2013-02-23 12:37 AM, "Matthew Flaschen" mflaschen@wikimedia.org wrote:
On 02/22/2013 11:32 PM, Brian Wolff wrote:
What ive always wondered is what happens if your oid provider goes under/otherwise dissapears. I imagine that means you lose your user
account
all across the internet, which is a scary thought
Some sites, like Stack Overflow, allow you to add alternate OpenIDs, which helps for temporary or permanent downtime.
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Presumably you would have to do that before the downtime though as you wouldn't be able to login once downtime starts. So one could easily be caught off guard.
-bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
see also https://bugzilla.wikimedia.org/show_bug.cgi?id=9604 (2007) "Support OpenID extension on all wikimedia projects"
Am 23.02.2013 05:40, schrieb Brian Wolff:
Some sites, like Stack Overflow, allow you to add alternate OpenIDs, which helps for temporary or permanent downtime.
Presumably you would have to do that before the downtime though as you wouldn't be able to login once downtime starts. So one could easily be caught off guard.
-bawolff
E:OpenID is usually configured for standard (password) Login or OpenID Login, so with E:OpenID-enabled MediaWIkis (as Consumer) you are on the safe side regarding this aspect.
You can associate one or many OpenIDs to your account. You can manage your OpenIDs (add further, delete unwanted) in a new preferences tab "OpenID".
T.
On 02/22/2013 08:32 PM, Brian Wolff wrote:
What ive always wondered is what happens if your oid provider goes under/otherwise dissapears. I imagine that means you lose your user account all across the internet, which is a scary thought
There is an additional part of OpenID called delegation. It let's you choose which provider you use, but you control your URL. When I cared, I used interi.org as my login, and if my provider ever went away I could sign up with a new one and set it as my delegated provider. If I recall, it is just a couple of meta elements.
In other threads: I've used OpenID for years, but I couldn't imagine why the wikae would be using it; I don't use bots or tools that require user accounts. I still don't get it, but it isn't that important for me; if this is helpful to those folks, good luck. ^_^
maiki
On 02/22/2013 05:03 PM, Jay Ashworth wrote:
or allowing external non-WMF sites to authenticate against our user database.
Actually, that's the objective -- allow external tools to have their users be able to prove "I am Wikimedia user Coren" without having to hack around with edits-as-authentication-tokens or the enduser giving their credentials to some untrusted system.
-- Marc
wikitech-l@lists.wikimedia.org