“Bigliettazione Account Based e Mobile ticketing sono sinonimi.”
“Ah, bella la bigliettazione Account Based, però non è utilizzabile su larga scala perchè esclude tutta quella fetta di popolazione non digitalizzata.”
“L’Account Based Ticketing è l’EMV.”
Queste sono solo alcune delle affermazioni che sentiamo ripetere regolarmente quando spieghiamo che facciamo bigliettazione per il trasporto passeggeri in modalità Account Based. C’è sicuramente tanta confusione intorno a questo termine, che in realtà ha una definizione semplice: la bigliettazione Account-Based è un metodo di ticketing dove la prova del diritto di viaggiare e tutti i record del viaggio sono contenuti in un sistema di back office sempre accessibile e non dentro un supporto fisico (“media”) in possesso del passeggero.
In questo post del blog abbiamo approfondito questa definizione, andando a spiegare perché crediamo che l’Account Based sia la bigliettazione del presente proiettata verso il futuro.
In questo articolo invece vogliamo provare a raccontare la storia dalla parte del supporto utilizzato per la bigliettazione. Quello che ne è uscito è una divertente conversazione, che però crediamo possa aiutare a chiarire alcune differenze fondamentali tra sistemi Card/Media-based (MBT) e quelli Account-Based (ABT).
Buona lettura!
BIGLIETTO CARTACEO
MBT
Sono un biglietto cartaceo: non sono sicuro per definizione perché è come se fossi denaro contante ed è difficile – se non impossibile – tracciarmi, soprattutto in tempo reale.
Serve a poco impreziosirmi per scopi di anticontraffazione, se non ad aumentare il mio costo di stampa.
Il mio più grande difetto è il mio costo di gestione, soprattutto di distribuzione.
ABT
Non sono un biglietto, sono un semplice token per accedere al biglietto vero e proprio che è al sicuro nel sistema centrale. Sono solo la rappresentazione fisica di un biglietto digitale nel server.
La mia sicurezza è basata sulla connessione con il server centrale o, in assenza di connettività, con le tecniche di gestione del rischio offline.
Posso essere emesso in loco, ovunque, attraverso dei semplici dispositivi di mercato connessi con il sistema centrale (ma in grado anche di funzionare offline). Costo pochissimo.
SMART CARD
MBT
Sono una smart card e sono di fatto un piccolo computer. La mia sicurezza è basata sull’utilizzo di Secure Element.
Essendo un computer devo interagire con altri computer: i reader (validatori) con cui vengo a contatto sono dotati di intelligenza.
Di solito sono parte di un sistema closed loop e vengo fornita da un operatore di trasporto: i miei costi di acquisto (anche nel caso delle chip on paper) e di gestione non sono trascurabili. Sono un rifiuto speciale quindi devo essere smaltito adeguatamente.
ABT
Sono la stessa smart card, ma posso essere usata in modo diverso, ovvero come semplice token in sola lettura (sfruttando gli opportuni protocolli di comunicazione sicura con il validatore), mentre i titoli di viaggio sono custoditi nel server.
Risulta così possibile semplificare i reader, evitando di usare Secure Element. L’autenticazione non è card-reader, ma card-sistema centrale (e quindi è intrinsecamente più moderna e più sicura).
Potrei addirittura essere una smart card qualsiasi, anche la tessera fedeltà del supermercato o la card dell’hotel.
In una fase di evoluzione progressiva da un sistema MBT a un sistema ABT, potrei contenere un token ABT nel mio data model.
SMARTPHONE
MBT
Sono un cellulare e devo contenere il titolo di viaggio. Lo posso fare emulando una smart card (in modalità HCE), ma questo è possibile solo per Android (e non per iOS) nel mercato europeo. Sono solo un supporto più costoso per titoli di viaggio veicolati in realtà alla stregua di una smart card.
Devo far leggere il titolo di viaggio da un reader esterno (validatore), facendo uso delle sue capacità di elaborazione e connettività. Non viene usata la mia connettività.
Lo posso fare all’interno di un’app, ma se l’app viene cancellata, il biglietto viene irrimediabilmente perso.
ABT
Sono uno smartphone e vengo usato nel pieno delle mie funzionalità, ovvero connettività e interfaccia utente. Il titolo di viaggio è nel server ed io offro solo il collegamento ad esso.
Come da ISO/TR 20526, sono un “Active dynamic media” e rispetto ad un “Passive dynamic media” (come una smart card) ho due grandi vantaggi:
1) un’interfaccia per l’utente
2) la connessione ad Internet
e quindi posso permettere non solo il paradigma diretto ma anche il paradigma inverso di validazione (ovvero adesivi QR code a bordo mezzo o in fermata, inquadrati dalla mia fotocamera).
Sono l’unico scenario di bigliettazione in cui l’utente si sente tecnologicamente partecipe (user in the loop) in termini di responsabilità e di investimenti abilitanti.
Sono il canale preferenziale per fare il MaaS.