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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [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, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [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, . 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, . [PARISI] Parisi, G., "Mean-field theory of spin-glasses with finite coordination number", 1987, . [HAVERSINE] Wikipedia, "Haversine Formula", 2024, . 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]