I’ve found NDEF cards that can hold 16KB & 32KB, even as much as 64KB. That may be too much capacity for ticketing but it blows QR codes out of the water
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.
scoot|1 year ago
rswail|1 year ago
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.
teknologist|1 year ago