[esotericn]

Off the top of my head.

Issue an asym key to a user upon them registering their official bank details. Backend holds one side of it (not sure whether to call this the pub or priv).

User uses the asym key to sign a message and shows that message to the inspector (in reality, QR code or similar).

If the user cheats you go after the account holder behind the key for reconciliation.

edit: Doesn't work as you need to enforce buying even if unchecked.

[Freak_NL]

You can't detect cheating if the user is using a custom client in this scenerio. At most, the software client used by the inspector could mark your ticket with the backend as 'checked', which would mean that any checked ticket that doesn't get reported as actually purchased at some point could indicate fraud. A sophisticated custom client could just actually purchase any ticket that gets checked though. It would still net you a rather significant discount depending on the coverage of ticket inspections.

What does work is providing a way to check-in and out of transport via gates or poles not under the control of the traveller with a token like the Oyster card.

[angry_octet]

This is only a problem if you want gate-less tickets, i.e. get on a bus/train without scanning at a reader or network comms, which seems an overly strict requirement.

[anticensor]

Gateless ticket control is a must if you want to do a fast all-doors boarding in a bus.

[angry_octet]

And no comms between client device and internet endpoint for several minutes? Is so, you can say 'network down, manual scan required'. If client can get network, it buys a ticket online.

[Freak_NL]

Buses and trams typically don't have gates, but a common solution is to have the check-in device right inside the doors.

[anticensor]

That is only suitable for FDB.

[esotericn]

Ah, I see the issue. It's the timestamping problem.

You have no way of detecting whether a user "bought a ticket" on seeing the inspector or not.

[lixtra]

You can do statistical analysis if certain users get checked unusually often (I.e. generate tickets only when checked). After some time you can force those users into online only mode.

[lonelappde]

That doesn't work because ticket checks are far too rate to develop a statistical model for any one user.

[esotericn]

You have no way of knowing that they generate tickets only when checked.

[dwild]

I have nearly no information about this scheme because the post got removed.

It has to be partially online, how do you pay without an online connection? Is there some kind of amount you have and then you can redeem them offline?

At one point you do require an online check in, that's for sure, that's when you find out whether the tickets were bought only when checked or not.