TRIP: Trajectory-based Recognition of Identity Proof
draft-ayerbe-trip-protocol-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Camilo Ayerbe Posada | ||
| Last updated | 2026-02-01 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ayerbe-trip-protocol-00
Independent Submission C. Ayerbe
Internet-Draft ULISSY s.r.l.
Intended status: Informational 1 February 2026
Expires: 5 August 2026
TRIP: Trajectory-based Recognition of Identity Proof
draft-ayerbe-trip-protocol-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 August 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ayerbe Expires 5 August 2026 [Page 1]
Internet-Draft TRIP February 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 4
2.1. Identity Model . . . . . . . . . . . . . . . . . . . . . 4
3. Breadcrumb Specification . . . . . . . . . . . . . . . . . . 5
3.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 5
3.2. Breadcrumb Hash . . . . . . . . . . . . . . . . . . . . . 6
3.3. Spatial Quantization . . . . . . . . . . . . . . . . . . 6
3.4. Context Digest Construction . . . . . . . . . . . . . . . 7
3.5. Genesis Breadcrumb . . . . . . . . . . . . . . . . . . . 8
3.6. Velocity Plausibility . . . . . . . . . . . . . . . . . . 8
3.7. Location Deduplication . . . . . . . . . . . . . . . . . 8
4. Trajectory Identity Token (TIT) . . . . . . . . . . . . . . . 9
5. Epoch Specification . . . . . . . . . . . . . . . . . . . . . 9
5.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 9
5.2. Merkle Tree Construction . . . . . . . . . . . . . . . . 10
5.3. Bundling Rules . . . . . . . . . . . . . . . . . . . . . 11
6. Trust Computation . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Trust Model Overview . . . . . . . . . . . . . . . . . . 11
6.2. Trust Score Function . . . . . . . . . . . . . . . . . . 11
6.3. Trust Thresholds . . . . . . . . . . . . . . . . . . . . 12
7. Verification Procedures . . . . . . . . . . . . . . . . . . . 13
7.1. Breadcrumb Verification . . . . . . . . . . . . . . . . . 13
7.2. Epoch Verification . . . . . . . . . . . . . . . . . . . 14
7.3. TIT Verification . . . . . . . . . . . . . . . . . . . . 14
8. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. CDDL Schema . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Cryptographic Agility . . . . . . . . . . . . . . . . . . 16
9.3. Replay Protection . . . . . . . . . . . . . . . . . . . . 16
9.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 17
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
10.1. Location Privacy . . . . . . . . . . . . . . . . . . . . 17
10.2. Trajectory Correlation . . . . . . . . . . . . . . . . . 17
10.3. Context Digest Privacy . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 18
Ayerbe Expires 5 August 2026 [Page 2]
Internet-Draft TRIP February 2026
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Example Breadcrumb (Informative) . . . . . . . . . . 19
Appendix B. Design Rationale (Informative) . . . . . . . . . . . 19
B.1. Why H3 Over Other Geospatial Systems . . . . . . . . . . 19
B.2. Why CBOR Over JSON . . . . . . . . . . . . . . . . . . . 20
B.3. Why Trajectory Over Biometrics . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. 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.
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology
Breadcrumb A single, signed attestation of spatiotemporal presence.
The atomic unit of the TRIP protocol.
Ayerbe Expires 5 August 2026 [Page 3]
Internet-Draft TRIP February 2026
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.
2. 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 [RFC8032] for signing and
SHA-256 [RFC6234] for hashing. Spatial coordinates are quantized to
the H3 hexagonal grid system before any storage or transmission.
2.1. 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.
Ayerbe Expires 5 August 2026 [Page 4]
Internet-Draft TRIP February 2026
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.
3. Breadcrumb Specification
3.1. Data Structure
A breadcrumb is a fixed-schema record consisting of the following
fields, serialized as a CBOR [RFC8949] map with integer keys:
+============+=======+========+==========+=======================+
| Key | CBOR | Type | Bytes | Description |
| | Label | | | |
+============+=======+========+==========+=======================+
| 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 / | 32 / 1 | SHA-256 hash of |
| | | null | | 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 |
+------------+-------+--------+----------+-----------------------+
Table 1: Breadcrumb Fields
Ayerbe Expires 5 August 2026 [Page 5]
Internet-Draft TRIP February 2026
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.
3.2. 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.
BreadcrumbHash(B) = SHA-256(CBOR-Canonical(B[1..9]))
B[N+1].previous = BreadcrumbHash(B[N])
B[0].previous = null
Figure 1: Breadcrumb Hash Computation
3.3. 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 [H3] 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:
+============+=================+===========+====================+
| Resolution | Avg. Area (km2) | Avg. Edge | TRIP Usage |
| | | (km) | |
+============+=================+===========+====================+
| 7 | 5.161 | 1.22 | Public disclosure |
| | | | / city-level |
+------------+-----------------+-----------+--------------------+
| 10 | 0.015 | 0.066 | Default breadcrumb |
| | | | resolution |
+------------+-----------------+-----------+--------------------+
| 12 | 0.0003 | 0.010 | Precise / |
| | | | commercial |
+------------+-----------------+-----------+--------------------+
Table 2: H3 Resolution Properties (Selected)
Ayerbe Expires 5 August 2026 [Page 6]
Internet-Draft TRIP February 2026
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.
3.4. 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.
input = "h3:8a2a1072b59ffff|ts:29145660|wifi:a3b2c1d4e5f67890"
digest = SHA-256(input)
Figure 2: 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.
Ayerbe Expires 5 August 2026 [Page 7]
Internet-Draft TRIP February 2026
3.5. 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.
3.6. 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 [HAVERSINE] between the H3 cell centers divided by
the time difference.
The following entity speed classes are RECOMMENDED:
+=========+==================+=====================================+
| 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 |
+---------+------------------+-------------------------------------+
Table 3: Entity Speed Classes
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.
3.7. 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.
Ayerbe Expires 5 August 2026 [Page 8]
Internet-Draft TRIP February 2026
4. 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_input = identity_public_key || BreadcrumbHash(genesis)
tit_full = SHA-256(tit_input)
TIT = tit_full[0..15] // first 16 bytes (128 bits)
Figure 3: 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.
5. Epoch Specification
5.1. 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.
Ayerbe Expires 5 August 2026 [Page 9]
Internet-Draft TRIP February 2026
+================+=======+========+==============================+
| Key | CBOR | Type | Description |
| | Label | | |
+================+=======+========+==============================+
| 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 / | Hash of preceding epoch, or |
| | | null | null for first epoch |
+----------------+-------+--------+------------------------------+
| signature | 10 | bstr | Ed25519 signature over |
| | | | fields 1-9 (64 bytes) |
+----------------+-------+--------+------------------------------+
Table 4: Epoch Fields
5.2. 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.
Ayerbe Expires 5 August 2026 [Page 10]
Internet-Draft TRIP February 2026
MerkleRoot
/ \
H(AB) H(CD)
/ \ / \
H(B0) H(B1) H(B2) H(B3)
Figure 4: Merkle Tree for an Epoch of 4 Breadcrumbs
where H(Bn) = BreadcrumbHash(breadcrumb_n) and H(AB) = SHA-
256(H(B0) || H(B1)).
5.3. 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.
6. Trust Computation
6.1. 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.
6.2. Trust Score Function
The trust score T for a trajectory is computed using a Parisi
percolation model [PARISI]:
Ayerbe Expires 5 August 2026 [Page 11]
Internet-Draft TRIP February 2026
T = D(t) * S * k_percolation
where:
D(t) = exp(-(t - t_last)^2 / (2 * tau^2))
Gaussian temporal decay function
t = current time
t_last = timestamp of most recent breadcrumb
tau = decay half-life (RECOMMENDED: 30 days)
S = unique_cells / total_breadcrumbs
Spatial diversity ratio (0.0 to 1.0)
unique_cells = count of distinct H3 cells visited
k_percolation = min(breadcrumb_count / 100.0, k_max)
Parisi percolation factor [PARISI]
k_max = 7 (RECOMMENDED)
Figure 5: 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.
6.3. Trust Thresholds
TRIP does not mandate specific trust thresholds for application-level
decisions. However, the following reference thresholds are
RECOMMENDED for interoperability:
Ayerbe Expires 5 August 2026 [Page 12]
Internet-Draft TRIP February 2026
+=============+============+=============+=======================+
| Level | Min. Score | Min. | Typical Use |
| | | Breadcrumbs | |
+=============+============+=============+=======================+
| 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 |
+-------------+------------+-------------+-----------------------+
Table 5: Reference Trust Thresholds
7. Verification Procedures
7.1. 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).
Ayerbe Expires 5 August 2026 [Page 13]
Internet-Draft TRIP February 2026
8. OPTIONAL: Verify velocity plausibility relative to the preceding
breadcrumb (Section 3.6).
7.2. 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.
7.3. 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 Section 7.1.
3. Compute the TIT per Section 4 and compare with the claimed value.
8. CBOR Encoding
TRIP messages MUST be encoded using CBOR [RFC8949]. The canonical
encoding follows the deterministic CBOR rules specified in
Section 4.2 of [RFC8949]:
* 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.
Ayerbe Expires 5 August 2026 [Page 14]
Internet-Draft TRIP February 2026
8.1. CDDL Schema
The following CDDL [RFC8610] defines the TRIP data structures:
; TRIP Protocol CDDL Schema
breadcrumb = {
1 => 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
9. Security Considerations
Ayerbe Expires 5 August 2026 [Page 15]
Internet-Draft TRIP February 2026
9.1. 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
(Section 3.4) 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 (Section 3.6) 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.
9.2. 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.
9.3. 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.
Ayerbe Expires 5 August 2026 [Page 16]
Internet-Draft TRIP February 2026
9.4. 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.
10. Privacy Considerations
10.1. 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.
10.2. 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.
10.3. 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.
Ayerbe Expires 5 August 2026 [Page 17]
Internet-Draft TRIP February 2026
11. 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.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
12.2. Informative References
Ayerbe Expires 5 August 2026 [Page 18]
Internet-Draft TRIP February 2026
[H3] Uber Technologies, "H3: A Hexagonal Hierarchical
Geospatial Indexing System", 2018,
<https://h3geo.org/docs/>.
[PARISI] Parisi, G., "Mean-field theory of spin-glasses with finite
coordination number", 1987,
<https://doi.org/10.1103/RevModPhys.91.030501>.
[HAVERSINE]
Wikipedia, "Haversine Formula", 2024,
<https://en.wikipedia.org/wiki/Haversine_formula>.
Appendix A. Example Breadcrumb (Informative)
The following is a JSON representation of a breadcrumb for
illustration. The canonical wire format is CBOR as specified in
Section 8.
{
"index": 42,
"identity": "3b6a27bcceb6a42d62a3a8d02a6f0d73...",
"timestamp": "2026-01-15T14:32:10Z",
"cell": "8a2a1072b59ffff",
"resolution": 10,
"context": "e3b0c44298fc1c149afbf4c8996fb924...",
"previous": "a7ffc6f8bf1ed766...previous_hash...",
"meta": {
"battery": 72,
"accuracy": 8.5,
"network": "wifi",
"entity_class": "human",
"manual": false
},
"signature": "9d61b19deffd5a60ba844af49...sig..."
}
Appendix B. Design Rationale (Informative)
B.1. 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.
Ayerbe Expires 5 August 2026 [Page 19]
Internet-Draft TRIP February 2026
B.2. 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.
B.3. 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.
Author's Address
Camilo Ayerbe
ULISSY s.r.l.
Via Gaetano Sacchi 16
00153 Roma RM
Italy
Email: cayerbe@gmail.com
Ayerbe Expires 5 August 2026 [Page 20]