"single sign on" for public transportation trips/trains

derhuerst commented 1 year ago

problem

There are many tools that allow you to find a single public transport (PT) trip/vehicles and then subscribe to it:

sites mainly targeted towards informing users (departure boards, "raw debugging" sites like bahn.expert)
sites/apps allowing one to subscribe to trips/trains and get realtime information about them (e.g. traewelling & travelynx, but also the "my live itinerary" features of many PT apps)
sites that try to make refunds for cancelled/delayed/inaccessible trains more straightforward (e.g. according to the EU passenger rights)

All of these sites/apps need to re-invent the wheel here (re-harmonize data sources, re-conceptualize UI flows, build UI views, etc.) to allow for such functionality, even though this is usually not their core functionality. This wastes time that could be spent improving the core product!

idea

Maybe there could be some sort of "single-sign on (SSO)" service for PT trips/vehicles, except not to authenticate the user but to identify the trip/vehicle:

If the user hasn't picked a trip/vehicle yet, the app would redirect them to the "SSO" service. Otherwise, it would proceed with step 3.
On the SSO service, the user will be presented with multiple options to find the trip/vehicle, e.g. searching via current location, line/route name, departure boards. They pick one, confirm that the requesting app will have access to many details about their current "situation", configure for how long they want to app to be able to access this data, and finally jump back to the app, passing along a token token that the app can use to fetch more information about the trip/vehicle.
The app can now fetch all the information the SSO service has on the trip/vehicle, either once or continuously. It uses this information to implement their core functionality.

possible enhancements

webhooks

Public transportation is inherently realtime-data-focused. Travellers usually want to be informed about their itinerary in a timely and accurate manner, especially when unplanned disturbances occur (e.g. wheelchair-inaccessible vehicle, disruptions, broken toilet).

The SSO service could provide the option to notify third-party services in a push-based way, e.g. via webhooks.

context information

Obtaining & sharing "context information" (e.g. geolocation, details from the local on-board wifi, etc.) about the user is a notoriously hard problem: Asking for consent, obtaining data in a battery- and network-friendly way, judging measurements' quality, tying them to a specific trip/vehicle.

For users, given that they trust the SSO service, it would be great not to have to provide this information again and again. They could

either have the app of the SSO service installed on their device (or leave the web page open),
or allow the third-party apps to contribute such information back to the platform (subject to consent).

user feedback

Many apps each try individually to motivate users to give feedback about their trip/vehicle (e.g. "is the train on wheelchair-accessible?", "is the vehicle dirty?"), even though the feedback usually applies to co-travellers using other apps too. From a accessibility/UX perspective, it makes a lot of sense to share this feedback across platforms.

The SSO service could share this feedback across third-party apps. Like with "context information" based on measured data (see above), the user could either use the canonical app of the SSO service, or allow third-party apps to pass such information back to the SSO service.

challenges, open problems

stable IDs for trips/vehicles

While some mobility domains have unique identifiers for trips and/or vehicles (e.g. airplanes), most of them do not. Making sense of the patchwork of different data sources, as well as their different granularities and levels of quality, is still a lot of work, albeit just as much as when building this functionality in-house.

centralization of user data

Having such a large amount of highly sensitive data about a large group of people is prone to abuse, both via unauthorized access (data breaches) as well as corporate interests (selling the data to advertisers). There would be a significant interest for companies to become de-facto platforms monopolizing the market of such PT SSO services.

I think similar problems and solutions apply here than with SSO providers (the non-public transport kind) in general. It would be paramount to keep the system open by design, so that users can always use a provider that respects their needs (e.g. a community-run or locally running).

customizability

Most organisations that develop apps want to have tight control over UX, branding, telemetry/tracking, etc. across the entire app. Integrating a third-party SSO service will make it hard to achieve this, and thus be somewhat unattractive.

2martens commented 1 year ago

Sounds great but have a question: wouldn't the option of decentralised SSOs still result in fragmented data wrt to feedback and such? For the purpose of retrieving information from an SSO it works but pushing info to one is tricky.

derhuerst commented 1 year ago

wouldn't the option of decentralised SSOs still result in fragmented data wrt to feedback and such?

Probably. I'd say that the problem is just shifted from the user-facing apps to the SSO services: Sharing user-provided data – with all the usual problems such as false positives, spam, privacy considerations – across federated instances.

public-transport / ideas