That is the issue. If it was just a matter of a unique identifier, then a read only token would be fine.
However, for most transit, there is some form of "check in/out" (either through barriers/gates or via validation/inspection). This is combined with rules about "antipassback" (ie one user passing the token back to another to reuse), as well as "total time in system" (ie to avoid people staying in the system all day).
There are also rules that take into account entry/exit times (eg peak/off-peak), entry/exit locations (eg core/non-core zones) etc.
All of these rules require either:
a) An always online set of validators to be able to contact the backend that is maintaining the information, or,
b) a way to record the information on the token so that it is physically transported from one validation location to another.
It also is needed for inspection purposes during a trip.
However, for most transit, there is some form of "check in/out" (either through barriers/gates or via validation/inspection). This is combined with rules about "antipassback" (ie one user passing the token back to another to reuse), as well as "total time in system" (ie to avoid people staying in the system all day).
There are also rules that take into account entry/exit times (eg peak/off-peak), entry/exit locations (eg core/non-core zones) etc.
All of these rules require either:
a) An always online set of validators to be able to contact the backend that is maintaining the information, or,
b) a way to record the information on the token so that it is physically transported from one validation location to another.
It also is needed for inspection purposes during a trip.