How should access to the 'provider' API be authenticated?

[jfh01]

Given that the provider API is intended for use by cities (and their vendors/patners) and NOT the general public, how should providers implement access control on their API endpoints?

Simple option would be for LADOT to issue a shared secret at the time when providers are granted an API.

Longer term, probably need a more cryptographic or account-oriented solution, since cities may want the ability to authorize 3rd parties (e.g. vendors) to access MDS data on their behalf.

[aickin]

I’d argue that it might be a good choice to remove transport protocol completely from this spec, or at least put it into a separate optional spec.

For example, you could imagine a provider and agency agreeing that the provider just emails a large data dump of all trips every week or that the provider FTPs the data to a central server. Authentication would be figured out differently in each of those situations.

[thekaveman]

@aickin that's an interesting thought, I can see how that kind of setup could be more useful to certain organizations that maybe aren't quite prepared to deal with API calls and AWS databases etc.

That being said... do we have any of those agencies listening in, that want to put forth their thoughts on this matter? Given that this is still early days for MDS, I would hesitate to add too many "options" for how to move this data around etc. until we've at least established the baseline spec and its utility. Unless we have a willing partner agency that wants to try a different transport protocol approach?

[jfh01]

I proposed a static file option in #58. Given the technical capabilities of LA and a few other cities, and the likelihood of vendors emerging to help cities consume real-time APIs, it seems wise to have a game plan on this. But for many cities, something far less sophisticated is likely the best option.

[jfh01]

@thekaveman Good question. My guess is that the cities least equipped to deal with a full API are also the least likely to be hanging out in a GitHub issues list. Might need to figure out a way to do some outreach to them.

[hunterowens]

@LADOTBikeshare has been maintain a list of all the cities we've reach out to with email address, and there is also NACTO.

[asadowns]

I would suggest a JWT that is issued by the provider to LADOT (or other agencies). This provides a lot of customization from the provider's perspective if there is other information they want to encode in the token and allows the providers to authorize accounts with well-defined permissions for accessing only MDS resources.

From the agency's perspective it is also relatively easy to issue new tokens and track token usage to prevent improper access or sharing. We also have envisioned agencies being able to generate their own tokens with bounded from this master token for use by their employees or vendors which seems like a win.

Another benefit here from the agency perspective is that each token can be issued only for their relevant area of operation (city or district) so there's no concern about any sort of improper access of data from areas outside the agency's purview.

If it's helpful would be happy to provide some example tokens and requests.

[hunterowens]

JSON Web Tokens seems like a good idea to me.

In terms of implementation, a top level document called auth.md would allow us to easily take this in / out of spec without too much issue / easy to add alternative methods. @asadowns can you prepare a PR? This would be good to have for 0.2.0 as it is a breaking change.

[asadowns]

@hunterowens yes. would be happy to.

[SLarrick]

@jfh01 I completely agree that cities least equipped to deal with APIs are also least likely to see this thread. In terms of outreach, I've been talking to a number of cities and reviewing a number of policies throughout the US and think it would be a good idea for the folks working on MDS to reach out to some of the shared mobility program managers, especially in smaller-to-mid-sized cities. You can see which cities explicitly ask for APIs in column U here - https://docs.google.com/spreadsheets/d/1ehA-PFoCnUswfOB7RaaguRN8xW5_khNvVWzOobsO_AA/edit#gid=0

Very few of the cities I've talked to are equipped currently to deal with a full API.

Full disclosure: I work for a company (Stae.co) that wants to help equip them to deal with a full API.

[jfh01]

@SLarrick Great research notes!

[migurski]

Yes, thank you @SLarrick! We’re doing a bit of research on API requests from cities. We are finding broad alignment on desire for an API without a lot of detail. We are discussing an officially-sanctioned MDS flat file converter tool at #58 which may help bridge the gap between keeping MDS sophisticated, simple, and accessible.