]> ULISSY s.r.l.

Via Gaetano Sacchi 16 Roma RM 00153 IT cayerbe@gmail.com

Security Independent Submission identity trajectory proof-of-trajectory geospatial cryptography This document specifies the Trajectory-based Recognition of Identity Proof (TRIP) protocol, a decentralized mechanism for establishing claims of physical-world presence through cryptographically signed, spatially quantized location attestations called "breadcrumbs." Breadcrumbs are chained into an append-only log, bundled into verifiable epochs, and distilled into a Trajectory Identity Token (TIT) that serves as a persistent pseudonymous identifier. Trust in a TIT accumulates through spatiotemporal diversity of the underlying trajectory rather than through biometric capture or centralized credential issuance. TRIP is designed to be transport-agnostic and operates independently of any particular naming system, blockchain, or application layer.

Introduction Conventional approaches to proving that an online actor corresponds to a physical human being rely on biometric capture, government-issued documents, or knowledge-based challenges. Each technique introduces a centralized trust anchor, creates honeypots of personally identifiable information (PII), and is susceptible to replay or deepfake attacks. TRIP takes a fundamentally different approach: it treats sustained physical movement through the real world as evidence of embodied existence. A TRIP-enabled device periodically records its position as a "breadcrumb"--a compact, privacy- preserving, cryptographically signed attestation that the holder of a specific Ed25519 key pair was present in a particular spatial cell at a particular time. An adversary who controls only digital infrastructure cannot fabricate a plausible trajectory because doing so requires controlling radio-frequency environments (GPS, Wi-Fi, cellular, IMU) at many geographic locations over extended periods. This document specifies the data structures, algorithms, and verification procedures that constitute the TRIP protocol. It intentionally omits transport bindings, naming-system integration, and blockchain anchoring, all of which are expected to be addressed in companion specifications.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Breadcrumb

A single, signed attestation of spatiotemporal presence. The atomic unit of the TRIP protocol.

Trajectory

An ordered, append-only chain of breadcrumbs produced by a single identity key pair.

Epoch

A batch of consecutive breadcrumbs whose aggregate integrity is attested by a Merkle root and a signature.

Trajectory Identity Token (TIT)

A 16-byte identifier derived from the public key and genesis breadcrumb, used as a persistent pseudonym.

H3 Cell

A hexagonal cell identifier from the H3 geospatial indexing system, used as the privacy-preserving spatial coordinate in breadcrumbs.

Context Digest

A SHA-256 hash of ambient environmental signals (Wi-Fi BSSIDs, cell tower IDs, IMU readings) that provides corroborating evidence for a breadcrumb's claimed location without revealing the raw signals.

Trust Score

A numerical value reflecting the spatiotemporal diversity and longevity of a trajectory, computed according to a defined trust function.

Protocol Architecture TRIP defines three layers of abstraction:

1. Breadcrumb Layer -- Production and validation of individual signed attestations.
2. Epoch Layer -- Aggregation of breadcrumbs into verifiable batches with Merkle integrity.
3. Trust Layer -- Computation of a reputation score from the spatiotemporal properties of a trajectory.

All cryptographic operations use Ed25519 for signing and SHA-256 for hashing. Spatial coordinates are quantized to the H3 hexagonal grid system before any storage or transmission.

Identity Model A TRIP identity is an Ed25519 key pair. The 32-byte public key is the identity. There is no registration authority; any entity capable of generating a valid Ed25519 key pair MAY participate in the protocol. The private key MUST be stored in a secure enclave or hardware-backed keystore and MUST NOT leave the originating device. A single physical entity MAY maintain multiple TRIP identities. The protocol makes no attempt to link multiple identities to a single entity; such linkage is explicitly a non-goal.

Breadcrumb Specification

Data Structure A breadcrumb is a fixed-schema record consisting of the following fields, serialized as a CBOR map with integer keys: Breadcrumb Fields

Key	CBOR Label	Type	Bytes	Description
index	1	uint	1-9	Zero-based sequence number within the trajectory
identity	2	bstr	32	Ed25519 public key of the producer
timestamp	3	tag(1)	5-9	CBOR epoch-based date/time (seconds since Unix epoch)
cell	4	uint	9	H3 cell index (64-bit unsigned integer)
resolution	5	uint	1	H3 resolution level (0-15)
context	6	bstr	32	SHA-256 context digest
previous	7	bstr / null	32 / 1	SHA-256 hash of preceding breadcrumb, or null for genesis
meta	8	map	variable	OPTIONAL metadata flags (battery, accuracy, etc.)
signature	9	bstr	64	Ed25519 signature over fields 1-8

The canonical CBOR encoding of fields 1 through 8 (inclusive), sorted by CBOR label in ascending integer order, constitutes the "signable payload." The signature in field 9 is an Ed25519 signature over this signable payload.

Breadcrumb Hash The breadcrumb hash is the SHA-256 digest of the complete canonical CBOR encoding of the breadcrumb (fields 1 through 9 inclusive). This hash serves as the chain link: the "previous" field (label 7) of breadcrumb N+1 MUST contain the breadcrumb hash of breadcrumb N.

Breadcrumb Hash Computation

Spatial Quantization Raw geographic coordinates (latitude, longitude) MUST NOT appear in any breadcrumb or in any message transmitted by a TRIP implementation. All spatial data MUST be quantized to an H3 cell index before storage or transmission. The H3 geospatial indexing system partitions the Earth's surface into a hierarchy of hexagonal cells at 16 resolution levels (0-15). The resolution determines the trade-off between location privacy and spatial precision: H3 Resolution Properties (Selected)

Resolution	Avg. Area (km2)	Avg. Edge (km)	TRIP Usage
7	5.161	1.22	Public disclosure / city-level
10	0.015	0.066	Default breadcrumb resolution
12	0.0003	0.010	Precise / commercial

Implementations SHOULD default to resolution 10. Implementations MUST support resolutions 7 through 12 inclusive. A verifier MAY accept breadcrumbs at resolutions outside this range but SHOULD apply reduced trust weight.

Context Digest Construction The context digest provides corroborating environmental evidence for a claimed location without disclosing the raw sensor data. It is constructed as follows:

1. Collect available ambient signals: Wi-Fi BSSIDs, cellular tower identifiers, and inertial measurement unit (IMU) readings.
2. Construct a pipe-delimited string of tagged components in the following order:
   • "h3:" followed by the H3 cell hex string
   • "ts:" followed by the timestamp bucketed to 5-minute intervals (Unix minutes / 5 * 5)
   • "wifi:" followed by the first 16 hex characters of SHA-256(sorted comma-joined BSSIDs), if available
   • "cell:" followed by the first 16 hex characters of SHA-256(sorted comma-joined tower IDs), if available
   • "imu:" followed by the first 16 hex characters of SHA-256(IMU vector string), if available
3. Compute SHA-256 of the resulting pipe-delimited string.

Context Digest Example

If no ambient signals are available, the context digest MUST still be computed from the h3 and ts components alone. A verifier SHOULD assign higher trust weight to breadcrumbs with richer context digests.

Genesis Breadcrumb The first breadcrumb in a trajectory (index 0) is the genesis breadcrumb. Its "previous" field MUST be null (CBOR simple value 22). The genesis breadcrumb establishes the binding between an Ed25519 public key and its trajectory chain.

Velocity Plausibility Before accepting a breadcrumb, a verifier SHOULD check that the implied velocity between consecutive breadcrumbs does not exceed a configurable maximum. The implied velocity is computed using the Haversine distance between the H3 cell centers divided by the time difference. The following entity speed classes are RECOMMENDED: Entity Speed Classes

Class	Max Speed (km/h)	Typical Entity
human	200	Pedestrian, cyclist, public transit
vehicle	500	Automobile, train
drone	300	Unmanned aerial vehicle
anchor	0	Fixed IoT device, kiosk

An entity class tag MAY be included in the meta field (CBOR label 8) under key "entity_class". Verifiers SHOULD reject breadcrumbs that exceed the maximum speed for the declared entity class. If no entity class is declared, verifiers SHOULD apply the "human" speed limit.

Location Deduplication A conforming producer MUST NOT emit a breadcrumb whose H3 cell is identical to the H3 cell of the immediately preceding breadcrumb in the same trajectory. This constraint enforces the core principle that trajectory identity requires physical movement. Implementations SHOULD additionally enforce a minimum geographic distance (RECOMMENDED: 50 meters) between consecutive breadcrumbs.

Trajectory Identity Token (TIT) The Trajectory Identity Token is a compact, deterministic identifier derived from the identity key and the genesis breadcrumb. It serves as a persistent pseudonym that is shorter than a full public key yet remains cryptographically bound to both the key and its origin point.

TIT Derivation

The TIT is 16 bytes (128 bits). Implementations SHOULD represent TITs as 32-character lowercase hexadecimal strings for display and interchange. A TIT is immutable once computed. If an entity wishes to start a new trajectory (e.g., after key compromise), it MUST generate a new key pair, which will produce a new TIT. No mechanism exists within TRIP to link old and new TITs; such linkage is a higher-layer concern.

Epoch Specification

Data Structure An epoch aggregates a contiguous range of breadcrumbs into a single verifiable unit. Epochs enable efficient verification: a verifier can check the epoch Merkle root and signature without examining every individual breadcrumb. Epoch Fields

Key	CBOR Label	Type	Description
epoch_index	1	uint	Zero-based epoch sequence number
identity	2	bstr	Ed25519 public key (32 bytes)
start_time	3	tag(1)	Timestamp of first breadcrumb in epoch
end_time	4	tag(1)	Timestamp of last breadcrumb in epoch
start_index	5	uint	Breadcrumb index of first entry
end_index	6	uint	Breadcrumb index of last entry
merkle_root	7	bstr	SHA-256 Merkle root of breadcrumb hashes (32 bytes)
count	8	uint	Number of breadcrumbs in epoch
previous_epoch	9	bstr / null	Hash of preceding epoch, or null for first epoch
signature	10	bstr	Ed25519 signature over fields 1-9 (64 bytes)

Merkle Tree Construction The Merkle tree is a binary tree constructed from the breadcrumb hashes within the epoch. Leaves are the SHA-256 hashes of individual breadcrumbs. Internal nodes are computed as SHA-256(left_child || right_child). If the number of leaves is odd, the last leaf is duplicated.

Merkle Tree for an Epoch of 4 Breadcrumbs

where H(Bn) = BreadcrumbHash(breadcrumb_n) and H(AB) = SHA-256(H(B0) || H(B1)).

Bundling Rules A producer SHOULD bundle an epoch when the number of unbundled breadcrumbs reaches or exceeds 100. Implementations MAY use a different threshold but MUST NOT create epochs with fewer than 10 breadcrumbs (except for the final epoch if the trajectory is being closed). Epochs MUST be sequential and contiguous: epoch N+1 MUST begin at the breadcrumb immediately following the last breadcrumb of epoch N. No breadcrumb may belong to more than one epoch, and no breadcrumb may be omitted from an epoch.

Trust Computation

Trust Model Overview TRIP trust reflects the difficulty of fabricating a trajectory. A trajectory that visits many distinct spatial cells over a long duration is harder to fake than one confined to a small area or short time span. The trust model quantifies this intuition through three components: trajectory density, spatial diversity, and temporal decay.

Trust Score Function The trust score T for a trajectory is computed using a Parisi percolation model :

Trust Score Computation

A verifier MAY apply additional weighting factors (e.g., context digest richness, geographic spread) but MUST compute at least the base trust score defined above for interoperability.

Trust Thresholds TRIP does not mandate specific trust thresholds for application-level decisions. However, the following reference thresholds are RECOMMENDED for interoperability: Reference Trust Thresholds

Level	Min. Score	Min. Breadcrumbs	Typical Use
anonymous	0	0	Key pair exists, no trajectory
emerging	0.5	50	Read-only access, limited API
established	1.0	100	Handle claiming, messaging
trusted	3.0	300	Financial operations, publishing
sovereign	5.0	500+	Full protocol participation

Verification Procedures

Breadcrumb Verification A verifier MUST perform the following checks on each breadcrumb, in order:

1. Decode the CBOR payload and verify that all mandatory fields (labels 1-7, 9) are present.
2. Verify that the identity field (label 2) is a valid 32-byte Ed25519 public key.
3. Reconstruct the signable payload from fields 1-8 in canonical CBOR encoding.
4. Verify the Ed25519 signature (label 9) against the signable payload using the identity public key.
5. If index > 0, verify that the "previous" field (label 7) matches the hash of the preceding breadcrumb.
6. If index == 0, verify that the "previous" field is null.
7. Verify that the timestamp is not in the future (with a tolerance of RECOMMENDED 5 minutes for clock skew).
8. OPTIONAL: Verify velocity plausibility relative to the preceding breadcrumb ().

Epoch Verification A verifier MUST perform the following checks on each epoch:

1. Verify the Ed25519 signature over fields 1-9.
2. Reconstruct the Merkle tree from the constituent breadcrumb hashes and verify it matches the declared merkle_root.
3. Verify that start_index and end_index define a contiguous range.
4. Verify that count == end_index - start_index + 1.
5. If epoch_index > 0, verify that previous_epoch matches the hash of the preceding epoch.

TIT Verification To verify a claimed TIT, a verifier MUST:

1. Obtain the claimant's Ed25519 public key and genesis breadcrumb.
2. Verify the genesis breadcrumb per .
3. Compute the TIT per and compare with the claimed value.

CBOR Encoding TRIP messages MUST be encoded using CBOR . The canonical encoding follows the deterministic CBOR rules specified in Section 4.2 of :

• Map keys MUST be sorted in ascending integer order.
• Integers MUST use the shortest encoding.
• Byte strings and text strings MUST use definite-length encoding.

Implementations that also support JSON interchange (e.g., for debugging or logging) SHOULD use the following canonical JSON rules: keys sorted alphabetically, numbers normalized (integers where possible), and no trailing whitespace.

CDDL Schema The following CDDL defines the TRIP data structures: uint, ; index 2 => bstr .size 32, ; identity (Ed25519 public key) 3 => #6.1(number), ; timestamp (epoch seconds) 4 => uint, ; cell (H3 index) 5 => uint .le 15, ; resolution (0-15) 6 => bstr .size 32, ; context digest (SHA-256) 7 => bstr .size 32 / nil, ; previous hash or null ? 8 => meta-map, ; optional metadata 9 => bstr .size 64, ; signature (Ed25519) } meta-map = { ? "battery" => uint .le 100, ? "accuracy" => float, ? "network" => tstr, ? "entity_class" => entity-class, ? "manual" => bool, * tstr => any, } entity-class = "human" / "vehicle" / "drone" / "anchor" epoch = { 1 => uint, ; epoch_index 2 => bstr .size 32, ; identity 3 => #6.1(number), ; start_time 4 => #6.1(number), ; end_time 5 => uint, ; start_index 6 => uint, ; end_index 7 => bstr .size 32, ; merkle_root 8 => uint, ; count 9 => bstr .size 32 / nil, ; previous_epoch hash or null 10 => bstr .size 64, ; signature } trajectory-identity-token = bstr .size 16 ]]>

Security Considerations

Threat Model TRIP assumes the following threat model:

• Private key security: The Ed25519 private key is assumed to be held in a secure enclave. If the private key is compromised, the attacker can produce valid breadcrumbs. Key compromise is outside the scope of TRIP; key management and revocation are higher-layer concerns.
• GPS spoofing: An attacker with a software-defined radio can spoof GPS signals in a localized area. The context digest () mitigates this by incorporating Wi-Fi BSSID and cellular tower data that are independent of GPS. Spoofing all signal sources simultaneously at diverse locations is significantly harder.
• Virtual environment: An attacker running the TRIP client in an emulator can feed arbitrary location data. The velocity plausibility check () and the requirement for sustained diversity over time make this attack progressively more expensive.
• Colocation attack: Two colluding devices can generate breadcrumbs at the same locations, but each device produces an independent trajectory under its own key. Cross-trajectory correlation is a verifier-side heuristic and is outside the scope of this specification.

Cryptographic Agility This specification mandates Ed25519 for signatures and SHA-256 for hashing. Future versions of TRIP MAY introduce algorithm negotiation. Implementations SHOULD be designed to allow algorithm substitution without protocol-level changes.

Replay Protection The monotonically increasing index and the chaining via the "previous" hash field provide replay protection within a single trajectory. A replayed breadcrumb will fail the chain integrity check. Cross-trajectory replay (using breadcrumbs from identity A in a trajectory of identity B) will fail signature verification.

Denial of Service An attacker can generate large numbers of breadcrumbs to consume verifier resources. Verifiers SHOULD rate-limit breadcrumb submission per identity and MAY require a minimum trust score before accepting further breadcrumbs for resource-intensive operations.

Privacy Considerations

Location Privacy TRIP's primary privacy mechanism is H3 quantization. By design, a breadcrumb reveals only that the producer was within a hexagonal cell of known area--not the precise GPS coordinates. At the default resolution 10, each cell covers approximately 15,000 square meters (0.015 km2), providing meaningful location privacy in urban environments. Implementations MUST NOT store raw GPS coordinates after H3 quantization. Implementations SHOULD provide users with the ability to choose their preferred resolution level, understanding that lower resolutions (larger cells) provide more privacy at the cost of reduced trust accumulation rate.

Trajectory Correlation A trajectory is intrinsically linkable: all breadcrumbs share the same identity key. This is by design, as trust accumulation requires identity continuity. However, a user who desires unlinkability across contexts MAY maintain separate TRIP identities (key pairs) for separate contexts. Verifiers SHOULD disclose their data retention policies. Breadcrumbs presented for verification need not be stored by the verifier after trust computation.

Context Digest Privacy The context digest is a one-way hash. Wi-Fi BSSIDs, cell tower IDs, and IMU readings cannot be recovered from the digest. However, an attacker who knows the Wi-Fi environment at a specific location and time could reconstruct the digest and confirm the producer's presence. This is a known acceptable trade-off: the digest provides corroboration, not concealment.

IANA Considerations This document has no IANA actions at this time. A future revision may request:

• A CBOR tag for TRIP breadcrumbs and epochs.
• A media type registration for application/trip+cbor.
• An entry in a TBD TRIP entity class registry.

References Normative References Informative References Uber Technologies Wikipedia

Example Breadcrumb (Informative) The following is a JSON representation of a breadcrumb for illustration. The canonical wire format is CBOR as specified in .

Design Rationale (Informative)

Why H3 Over Other Geospatial Systems The H3 system was selected over alternatives (S2, Geohash, Plus Codes) for several reasons: uniform cell area at each resolution level (hexagons tile more evenly than rectangles), hierarchical parent-child relationships enabling multi-resolution disclosure, efficient neighbor computation for velocity checking, and open-source availability with well-maintained libraries across platforms.

Why CBOR Over JSON CBOR provides deterministic encoding essential for reproducible signature computation, compact binary representation suitable for constrained devices and bandwidth-limited networks, and native byte string support for cryptographic material. JSON remains useful for debugging and human-readable interchange but lacks deterministic encoding rules.

Why Trajectory Over Biometrics Biometric systems capture immutable characteristics (fingerprints, iris, face). Once compromised, the credential cannot be rotated. Biometric databases are high-value targets. Deepfake technology increasingly undermines facial recognition. In contrast, a trajectory is: continuously renewable (new movement generates new evidence), inherently distributed (no central biometric database), resistant to digital fabrication (requires physical presence in the real world), and privacy- preserving by design (quantized spatial cells, not raw coordinates).

Acknowledgements The TRIP protocol builds upon foundational work in cryptographic identity systems, geospatial indexing, and percolation theory. The author thanks the contributors to the H3 geospatial system, the Ed25519 specification authors, and the broader IETF community for establishing the standards that TRIP builds upon.