Are GBFS feeds allowed to have auth on them?

[hunterowens]

Hi all-

in openmobilityfoundation/mobility-data-specification#338, there was a pretty robust debated around what type of auth can be applied to GBFS endpoints. I've merged the PR, but I'd like some clear guidance in the spec around what type of auth (if any) can be put in GBFS endpoints.

Thanks

[heidiguenin]

A few thoughts on this. GTFS term definitions says "Dataset - A complete set of files defined by this specification reference. Altering the dataset creates a new version of the dataset. Datasets should be published at a public, permanent URL, including the zip file name. (e.g., https://www.agency.org/gtfs/gtfs.zip)."

As we're drafting best practices for GBFS (coming soon to a new issue in this repo), we should add this to the best practices.

Then I'd suggest that, once the bike_id rotation approach (#147) is agreed upon, we can add language to the spec itself.

[Empty2k12]

The General Bikeshare Feed Specification, known as GBFS, is the open data standard for bikeshare.

I am strongly against locking certain info behind auth. This project strives to be an open standard that everyone can use to build interesting apps and integrations with open data.
Having locked data and possibly even with a cumbersome process of obtaining access is against what I feel is the goal of this project.

To facilitate integrations that are in everyone's best mind we should work on making the public data safe and useful so they can be used by everyone equally.

@hunterowens which use case are you thinking of that would require data to be behind an authed endpoint?

[markstos]

I work at a vendor that services a number of governments with services that involve GBFS. In one case a bike share provider was using authenticated feeds that we were supposed to integrate with. We were using the popular OpenTripPlanner software.

We were provided the authenticated feeds for gbfs.json and put those in OpenTripPlanner. OpenTripPlanner reasonably expected that gbfs.json would contain references to feeds it could access. But the vendor didn't generate a gbfs.json feed that itself contained the authentication tokens required to make the URLs work.

So for this integration to work, either:

1. OpenTripPlanner would have to understand their authentication scheme and rewrite their URLs to pass through their auth token.
2. Every vendor in our position would have write some kind of custom proxy to write their GBFS feeds so that they contain authenticated feed like themselves.
3. The bike share vendor would themselves have to update their system so the feeds worked seamlessly with OpenTripPlanner.

In this case, the bike share provider relented and provided us public feed URLs to work.

As someone working in the spec in practice, I can say that authenticated URLs slow down development and integration time and tools will break if authentication is added because it's not expected. This is especially true because of GBFS's layered approach where one auto-discovery URL points to yet more URLs.

I recommend that governments in particular demand that their bike share providers use un-authenticated GBFS-compliant feeds.

[stale]

This disucssion has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.