That's the problem, we don't currently have a one size fits all solution. So we cover all bases and let the customer decide which flavour of smart they want.
We can't have just one solution.
I'd go with the technology solution, but accept some people want a more basic system that works better for turn up and go travel - as well as providing a fallback if my phone breaks, gets stolen etc.
I think we can agree that magstrip tickets are too limited these days. Barcodes allow for more flexibility and the option to have online or offline checks made (or they can just be accepted as is during a network outage).
Barcodes and smart tickets/phones will co-exist for some time.
I haven't heard of it by name, I assumed it existed.
As I said, I think would be difficult and computationally expensive to run anti-fraud checks in the "authorisation loop" when you're scanning your ticket at the gate, working out whether it's possible for you to be at that gateline, based on your previous journey history. Plus, prone to error (clock skew, anyone?), particularly within London where tolerances would be very tight as things are very close together.
You could do it in the background, sure, but that would be reactive.
---
Essentially, it's a very different threat model. At the moment, the thread model is we trust the validity of paper tickets and smartcards intrinsically (the latter because the 'unique' magstripe is hard to forge, the latter because we can cryptographically prove it is genuine).
You cannot trust an e-ticket in the same way.
At a station, you'd have the local gates remember the ticket and so all gates would reject it again if passed back.
The gates can then bundle tickets scanned together and upload periodically, and update a remote database in the cloud that gradually feeds this info out to other gatelines. In this way, you don't need to worry about latency and connectivity issues to try and validate a ticket in real time.
Yes, it would mean that a slow or failed update wouldn't mark the ticket as 'used' but that is the problem of the railway, not the customer, so in effect a proper failsafe.
You'd assume that the process could take place before the passenger has managed to get to another station. A check by a member of staff with a terminal/phone would need a real-time connection to check as I am not sure a phone would be set to store that amount of data (even though with compression and 4G/5G connectivity, I am sure any phone could easily store it and discard periodically) but there's not the same level of rush in that case anyway.
And if anyone hasn't seen the mobile tickets that 'rotate', they will change the data sent to include the current time/date, which has to match the reader (give or take a set time to allow for variances) so a screen capture won't work. That has caused me problems before when a bus had a ticket machine with the clock out by an hour. I was fortunately allowed travel even though it said my ticket had expired.
If it’s a problem that’s for the train operator to worry about but the reality is that the detail of the scan will be sent to the database when connectivity is again available.
There aren't many places these days that have no connectivity (and as time goes on, 700 and 800MHz 4G and 5G coverage will help reach almost all of the UK landmass, not just populated areas).
If a station hasn't got any connectivity, it's perfectly possible for a fixed connection to be hooked up to an access point to allow staff wireless access. Chances are, you'd also offer a connection to the public too. If there are gates or TVMs there is already some sort of connectivity, and likewise to provide data to the CIS etc.
On a train, have the train manager or whoever scan a ticket and if it can't check within a certain timeframe, queue it for checking and move on. If the ticket comes back as rejected, you can return to the passenger. If all else fails, they get away with it - that time. It would be quite hard for someone to bank on problems so the fact a ticket is checked would likely put opportunists off.