Policy for new OAuth providers

[Zverik]

This is a draft I came up with, prompted by @lonvia in https://github.com/openstreetmap/openstreetmap-website/pull/1433. How does it look?

Policy for new OAuth providers

Besides the usual login and password, people use special buttons for signing in to OpenStreetMap with a social account. For example, with Facebook or GitHub. These buttons link a user’s profile to the authentication provider, allowing them to sign in with one click. This way a new user doesn’t even have to have a password: their social provider authenticates them instead.

Any authentication providers that is used by OpenStreetMap mappers can be added to the signing up page. To prevent overcrowding of the page and ensure people do not lose their accounts, we have a few requirements for a new auth provider:

1. Published gem with an OmniAuth strategy. The OSM website uses OmniAuth for interacting with auth providers, so there is no way around it.
2. Pull request to the openstreetmap-website that adds the support. It should affect:
   • Gemfiles.
   • Example.application.yml and omniauth.rb in the config directory.
   • Lib/auth.rb, login.html.erb, en locale and an icon for the web interface.
   • Tests for user creation, user controller and user login.
3. Three active mappers must use the authentication service and vouch for its support. Active means at least 500 mapping days on the HDYC profile. This ensures that a much greater number of casual mappers might also benefit from the new provider.
4. At least hundred thousand users or a sizable part of a specialized community should be registered in the service (shown with either a direct number or a related statistics), and there should be other pointers that it would not go offline in three years. That might mean a roadmap, a financial backing, infrastructure built on top of the service (popular apps, connections with other services) etc.
5. For enabling auto-validation of email addresses, a proof that all addresses that the auth provider sends via API are validated beforehand either by sending an email to a user, or by acquiring these from a provider that validates addresses this way.

Compliance to all five of these requirements does not guarantee that the auth provider will be immediately supported by the OpenStreetMap website by merging the corresponding pull request. But it remove most, if not all, non-technical questions, so your request is processed without involving other working groups and without sidetracking.

[pnorman]

For auto-validation, I think it's better to only autovalidate if the auth provider is also the email provider for all of its users, or if it is an email provider for only some of its users, to autovalidate only those users if they can be detected.

As hard requirements, we also need terms of service which allow openstreetmap-website to use the service without being in violation. This has excluded twitter, which was not possible to use in compliance with their TOS.

I don't see the need for three active mappers, nor am I sure what vouch for its support means.

I have more thoughts on the requirements which avoid adding every small provider out there, but I still need to gather them up. I think we should be looking at is the provider in general use as an identity provider outside their own organization.

[simonpoole]

To add some data points:

Provider	Accounts
Facebook	1'900'000'000
Google (gmail)	>1'000'000'000
Windows Live	> 400'000'000
Wikipedia (en only!)	30'000'000
GitHub	26'000'000
OSM	3'800'000

Or put differently the smallest organisation we currently accept logins from has over 6 times more accounts than OSM which I consider a rather low ratio. I can live with that, but would prefer if we don't consider anything below a billion for any further additions, or to be sure that the criteria scales: 250 times the OSM account number at the time the addition is contemplated.

[Zverik]

So "bugger off" to any service that mappers use, but that hasn't got wide adoption among the regular public? How adding "small" providers with e.g. hundreds of thousand users would hurt the website?

Paul, the clause for three active mappers means that at least some active mappers use the authentication service and will benefit from simplifying the sign in process. Three in a pull request would mean at least thirty more who don't know about this, and thousands of regular occasional mappers.

[simonpoole]

As already pointed out in the other relevant thread, smaller orgs can use OSM as their authentication provider (see mapillary).

[imagico]

A few general thoughts on the matter that might be significant in addition to what has already been said:

• authentication is about trust
• trust is necessary on two levels: registration (once) and login (repeatedly for individual interactions)
• for login the required trust boils down to managing the risk of identity fraud. If an authentication provider just uses the identity for some service where identity fraud is not a significant risk for them we should not rely on such a service to provide authentication for us. This especially applies of course for registrations which are essentially for read only services. And this of course also kind of favors large providers.
• for registration this is about trusting the information provided, specifically the email address. Trust here should IMO only be immediate - we should not trust an authentication provider based on trust they put in a third party (like an email provider). That would mean trusting Google regarding the validity of a self hosted email address is OK but trusting a third party email is not, even if there is a claim that this has been verified at some point in the past - which i think is in effect the same as what Paul suggested.

[simonpoole]

@Zverik Further comment:

Just so that it is clear, I don't believe anybody disagrees with the general goal of streamlining the sign up process (as far as legally possible), making it easier to integrate it in apps and making communicating with both groups of and individual contributors easier for third party applications.

But it is just so clear that it is not in the best interest of OSM to support fragmentation of the community more than it already is and to promote solutions that have the potential to cause privacy issues down the road.

So why can't your/maps.me time and energy be directed to supporting solutions that have a better chance of finding support? For example we have a really good (not to say brilliant) suggestion for resolving the e-mail problem on the table, it essentially needs somebody to do an initial implementation so that we can gauge the impact and see if there are any unforeseen issues with it. That would be a far better use of everybody's time.

[Zverik]

smaller orgs can use OSM as their authentication provider

I click on a "Google" icon in the Vespucci app and it suggests I remember my google password. When I do (and typing it on a mobile keyboard is painful), it redirects to the OSM registration page, but "back" button is not working: it redirects to Google, and Google redirects forward. The application is unusable at that stage, just because you opted for OSM login instead of one better tailored for mobile usage.

Maps.me iOS app does not allow logging in with Google, because Google OAuth was disabled on WebViews few weeks ago. They recommend using an SDK, but osm.org does not support logging in with SDK. If you rely on OSM authentication, you are stuck with the features osm.org provides, and when you try to improve them just a little bit — well, you see how many comments my pull requests get and how often they are merged.

Go Map and Pushpin iOS apps do not have OSM OAuth authentication, so I don't see other examples of this. Using the suggested SFSafariViewController would mean dropping support for iOS 8.

Mapillary uses their own authorization, they just use OSM as one of third-party authentication providers, like we (osm) use facebook/google/github/etc.

Fragmentation

Could anyone please explain how you see that fragmentation would happen? We have added Google as an authentication provider — does that mean we're okay with fragmentation towards Google Map Maker? Why buttons on the sign in page affect our users' mapping platform preferences?

So why can't your/maps.me time and energy be directed to supporting solutions that have a better chance of finding support?

Of all options, I assumed adding an auth endpoint that does not affect website functionality, anyone's privacy or any of the workflows would be the least controversial change. I am starting to suspect most of the comments have nothing to do with the code or suggested changes.

If an authentication provider just uses the identity for some service where identity fraud is not a significant risk for them we should not rely on such a service to provide authentication for us.

Good point, Christoph. Can you come up with an example of such service, which as per point 4 has at least 100k users?

[simonpoole]

@Zverik to clarify: Vespucci doesn't show a google icon (anywhere), I assume that you are referring to the google icon on the OSM login page?

Yes that likely does not work particularly well for creating an account if you are on a mobile device, and as was discussed back in the old issue on mobile account creation, it could obviously be improved by providing either a library/activity or an app that would provide such service on device (lots of caveats here as there are some obvious issue with misuse and so on, and we need to determine if proving a non-public API for creating accounts could work at all).