Designing a fare token for intermittent connectivity.

9 min read

FARE MEDIA

What changes when a QR identifies a rider but the balance and fare rules remain in a central account.

A QR code can make a mobile phone look like a transport credential with very little infrastructure. It can be shown on a screen, read by commodity cameras and distributed through a native application or a web application.

That visible simplicity hides the important question: what does the QR prove at the moment of validation?

In the system considered here, balance and business rules belong to an external account-based platform. The QR mechanism is not expected to calculate fares or store monetary value. Its immediate responsibility is narrower: provide an identifier or claim that lets the existing system locate the correct user and apply its own rules.

This separation is useful. It also means that the QR is not the ticket in isolation. It is one message in a protocol connecting a user, a mobile device, a validator and a central account system—sometimes when the network is unavailable.

Start with the acceptance decision

Before selecting an encoding or application technology, the validator’s decision needs to be defined.

In a fully online transaction, the validator can submit a short opaque token to the back end. The server resolves it to an account, evaluates current status and returns an acceptance result. The QR can be compact and short-lived because most of its meaning remains online.

In an offline transaction, the validator cannot ask the central system what the identifier means or whether the account remains valid. The presented object must carry enough authenticated information for a local decision, or the validator must accept provisionally and defer material decisions until connectivity returns.

Those are different operating models. “Supports offline” is not one feature that can be added after designing the online flow.

The design must state:

what the validator is authorised to decide locally;
how long that decision remains acceptable without current account state;
which risks may be deferred to reconciliation;
how repeated presentation of the same QR is detected or bounded;
what happens when validators disagree because their clocks, keys or revocation data differ.

The answers determine the payload and cryptography.

Online: prefer a short-lived reference

When a reliable network round trip is available, a short opaque reference has attractive properties. It need not expose a durable account identifier or personal data. The server can bind it to a user, device, validity interval and intended transport domain.

The reference should be unpredictable and expire quickly. A captured QR may still be replayed during that interval, so server-side controls need to recognise duplicate or implausible use. Rotation on the phone can reduce the useful capture window, provided the user experience and validator speed remain acceptable.

The server is the authority in this model. A valid-looking string has no independent meaning; acceptance depends on current server state. This simplifies the QR but makes network latency and availability part of the gate transaction.

Offline: carry a verifiable claim

An offline validator needs a self-contained object it can verify with locally available trust material. A typical structure contains a pseudonymous subject reference, issuer or domain, validity interval, token identifier or counter, and an algorithm/key reference. A digital signature or message authentication code protects the encoded fields against alteration.

Compact binary representations such as CBOR, combined with COSE structures, are useful candidates because QR capacity and scan reliability deteriorate as payloads grow. Encoding efficiency matters, but it is secondary to unambiguous interpretation. Every field covered by the signature must have a single defined representation and meaning.

Cryptographic validity does not establish account solvency. It can show that an authorised issuer created the object and that its protected content has not changed. If the current balance and rules live only in the central system, an offline validator cannot know their latest state.

The system must therefore choose one of three broad positions:

make only a limited local decision based on a recently issued entitlement;
accept provisionally and resolve financial consequences later;
refuse transactions when central state cannot be reached.

Cryptography authenticates the selected policy; it does not remove the policy trade-off.

Replay is the central QR problem

A QR displayed on a screen can be photographed, copied or forwarded. A valid signature does not distinguish the original display from a perfect copy.

Replay resistance can be strengthened through short validity windows, rotating tokens, counters, validator-generated challenges or device-held keys. Each measure introduces an operational dependency.

A one-time identifier works well online because the back end can atomically mark it used. Offline, two disconnected validators may both see the same unused identifier. Local deny lists help only within the validator’s recent history. Counters require reconciliation and rules for gaps or rollback. Challenge-response is stronger but no longer consists of a simple passive scan; a communication path is required to return the challenge to the phone.

The correct goal may be bounded replay rather than impossible replay. For low-value, high-throughput transport, a short exposure window plus back-office detection may be preferable to a protocol that slows every gate. That is a risk decision, not a weakness to hide behind the word “encrypted.”

Identity should not be printed in the clear

The requesting system requires a user identifier so that its own platform can apply business rules. Placing a permanent internal customer number directly in every QR would satisfy the integration while creating a portable tracking identifier.

A safer design presents a scoped pseudonymous reference. The central service can resolve it to the relevant account, but unrelated observers cannot use it as a stable identifier across time or domains. Rotation and domain separation reduce linkage further.

Offline verification complicates this because the validator may need a stable subject reference for local duplicate detection and later reconciliation. Stability should be limited to the smallest useful scope: for example, a transport domain and bounded time period rather than the lifetime of the user account.

The payload should contain no personal attributes unless the validator truly needs them for the acceptance decision. A name, document number or balance does not become private merely because it is rendered as black and white modules.

Web application or native application?

A progressive web application can be installed, cache its application shell and operate without an active network through service workers and local storage. It can display previously obtained or locally generated QR data. For an online opaque token, or for an offline token signed by a remote service before connectivity is lost, a web application may be sufficient.

The web platform does not itself answer the stronger security questions. Browser storage, lifecycle and device-binding capabilities vary. If the design depends on a non-exportable private key, platform attestation, strong biometric mediation, background token rotation or tighter control of screenshots and application integrity, a native application with hardware-backed platform APIs is usually the more credible basis.

Even a native application cannot prevent an authorised QR from being photographed. Its advantage is in protecting device keys and establishing that a fresh token was produced by an enrolled application instance. The validator protocol must still use those properties.

The choice should follow the required assurance:

PWA: lower deployment friction; suitable when the QR is principally a server-issued reference and cloning risk is handled operationally.
Native app: greater access to hardware-backed keys and platform controls; suitable when device binding or local signing is a material requirement.
Both: possible if the back end issues tokens with distinguishable assurance levels and the acceptance policy understands the difference.

“Works offline” and “resists cloning offline” should never be treated as the same requirement.

Payload size is a systems parameter

QR capacity is commonly discussed as a maximum number of characters. Real scanners operate below theoretical limits. Screen brightness, cracked displays, camera angle, motion, distance and error-correction level all affect acquisition time.

Verbose JSON, long property names, certificate chains and textual encodings can rapidly enlarge the symbol. Compact field identifiers, binary encoding and omission of information already known by the validator improve scan behaviour. Base encodings add overhead and should be selected with the end-to-end character channel in mind.

The objective is not the smallest possible token. It is the smallest token that remains versioned, unambiguous and independently testable. Saving bytes by relying on undocumented field order or implicit algorithms creates fragile interoperability.

Payload budgets should be tested on the intended validators and phones, under poor but realistic conditions, before the protocol is frozen.

Reconciliation completes the design

Offline transactions create distributed state. Validators collect evidence locally and later submit it to the central system. The back end must distinguish duplicate uploads from duplicate presentations, establish event ordering where possible and preserve enough information to explain a disputed decision.

Signed event records from validators can protect reconciliation data, but validator key management then becomes part of the system. Clock drift, key rotation, damaged queues and prolonged disconnection need explicit handling.

A practical design describes not only the happy-path scan but the complete return to consistency:

token issuance and expiry;
key and trust-list distribution;
local acceptance and evidence capture;
replay and anomaly detection;
idempotent upload;
conflict resolution and account adjustment;
privacy-preserving retention of transaction evidence.

The QR is the smallest visible part of that sequence.

The decision this inquiry should produce

For a central-account transport system, the initial recommendation is to keep the QR free of direct personal identifiers and stored value. Use short-lived opaque references for online acceptance. Define a separate, explicitly risk-bounded signed object if offline acceptance is required.

A web application is technically capable of offline presentation, but it should be selected only if the threat model does not require strong device-held keys or platform evidence. If device binding is a security control rather than a convenience, the native path deserves priority.

Most importantly, decide which offline uncertainty the operator is willing to accept before selecting algorithms. The cryptographic envelope can make a claim authentic. It cannot make a disconnected validator know the current state of a central account.

Context and scope

This note develops an active design inquiry for QR-based mobile presentation in an account-based transport system. The external platform retains balances and business rules; the proposed component supplies a user-related claim. No deployment outcome is asserted, and the commissioning organisation is not identified.