TRIP: Trajectory-based Recognition of Identity Proof

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

Terms defined in the RATS Architecture [RFC9334] (Attester, Evidence, Verifier, Attestation Result, Relying Party) are used throughout this document with their RFC 9334 meanings. Additional terms specific to TRIP:¶

Breadcrumb:

A single, signed attestation of spatiotemporal presence. The atomic unit of TRIP Evidence.¶

Trajectory:

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

Epoch:

A bundle of breadcrumbs (default 100) sealed with a Merkle root, forming a verifiable checkpoint.¶

Trajectory Identity Token (TIT):

A pseudonymous identifier derived from an Ed25519 public key paired with trajectory metadata.¶

Criticality Engine:

The analytical subsystem that evaluates trajectory statistics for signs of biological Self-Organized Criticality (SOC). In RATS terms, the Criticality Engine is a component of the Verifier.¶

PSD Scaling Exponent (alpha):

The slope of the Power Spectral Density of the displacement time series in log-log space. This quantity is referred to in the spectral analysis literature as the "spectral exponent" or "scaling exponent." In human mobility, alpha reflects long-range temporal correlation in movement and tends to be higher than for memoryless synthetic processes. TRIP uses alpha as an empirically-calibrated statistical feature (Section 7.5), not as a fixed physical constant; any specific numeric range is a per-deployment calibration. The 1/f "pink noise" framing, motivated by Parisi's work on scale-free correlations in biological systems [PARISI-NOBEL], is the historical motivation for the approach, not a normative boundary.¶

Hamiltonian (H):

A weighted energy function that quantifies how much a new breadcrumb deviates from the identity's learned behavioral profile.¶

Anchor Cell:

An H3 cell where an identity has historically spent significant time (e.g., home, workplace).¶

Flock:

The set of co-located TRIP entities whose aggregate movement provides a reference signal for alignment verification.¶

Proof-of-Humanity (PoH) Certificate:

A compact Attestation Result containing only statistical exponents derived from the trajectory, with no raw location data.¶

2.1. Role Mapping

2.2. Attestation Topology

TRIP's Active Verification Protocol (Section 12.2) implements the RATS background-check model: the Relying Party initiates verification by sending the identity's public key and a freshness nonce to the Verifier, which challenges the Attester, evaluates the Evidence, and returns a PoH Certificate (Attestation Result) to the Relying Party.¶

Background-Check Model (normative):

  Relying Party ---[nonce, identity_key]---> Verifier
                                               |
                                    Verifier --[challenge]--> Attester
                                    Verifier <-[response]--- Attester
                                               |
  Relying Party <---[PoH Certificate]------- Verifier

The background-check model is the REQUIRED attestation topology for TRIP. It ensures that every Attestation Result is bound to a specific Relying Party challenge, preventing replay of certificates across contexts.¶

A passport-model deployment, where the Attester obtains a PoH Certificate in advance and presents it directly to Relying Parties, is not prohibited but provides weaker freshness guarantees. In the passport model, the certificate's validity duration (field 11 of the PoH Certificate, Section 10) and the chain head hash (field 13) provide the only freshness binding. Relying Parties accepting passport-model certificates SHOULD require short validity durations.¶

TRIP proposes the use of post-handshake attestation via [I-D.fossati-seat-expat] for integration with standard RATS attestation flows.¶

2.3. Evidence Flow

H3-quantized Evidence is transmitted from the Attester to the Verifier. This is an explicit design choice: the Verifier requires access to the full breadcrumb chain to compute PSD scaling exponents, fit Levy flight parameters, and evaluate the Hamiltonian.¶

Privacy preservation derives from the H3 quantization transform applied by the Attester before any data leaves the device, NOT from data locality. Raw GPS coordinates MUST NOT be transmitted. The quantization transform is lossy and irreversible.¶

The Verifier MUST NOT forward raw Evidence to Relying Parties. Only the Attestation Result (PoH Certificate) is disclosed to Relying Parties.¶

2.4. Verifier Trust Model

The Relying Party MUST trust the Verifier that produced the Attestation Result. The TRIP protocol supports multiple independent Verifiers. An Attester MAY submit Evidence to more than one Verifier. A Relying Party MAY accept Attestation Results from any Verifier it trusts.¶

Each Verifier MUST have its own Ed25519 key pair. The Verifier signs PoH Certificates with its private key (field 14). Relying Parties verify this signature against the Verifier's published public key.¶

3.1. Spatial Quantization

The H3 geospatial indexing system [H3] partitions the Earth's surface into hexagonal cells at multiple resolutions. TRIP employs resolutions 7 through 10:¶

A conforming implementation MUST quantize raw GPS coordinates to an H3 cell before any signing or storage operation. Raw coordinates MUST NOT appear in breadcrumbs or in any protocol message transmitted between TRIP entities.¶

H3 resolution is a configurable protocol parameter. Implementations SHOULD default to resolution 10. Deployments MAY select alternative resolutions based on jurisdictional requirements, population density, and use-case sensitivity. Lower resolutions (larger cells) provide stronger location privacy at the cost of reduced spatial discrimination for trust computation.¶

3.2. Context Digest Computation

The context digest binds ambient environmental signals to the breadcrumb without revealing them. The digest is computed as follows:¶

1. 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 (floor(Unix_minutes / 5) * 5)¶

   • "wifi:" followed by the first 16 hex characters of SHA-256(sorted comma-joined BSSIDs), if Wi-Fi scan data is available¶

   • "cell:" followed by the first 16 hex characters of SHA-256(sorted comma-joined tower IDs), if cellular data is available¶

   • "imu:" followed by the first 16 hex characters of SHA-256(IMU vector string), if inertial sensor data is available¶

2. Compute SHA-256 over the UTF-8 encoding of the resulting string.¶

Absent components MUST be omitted entirely, not represented as empty strings.¶

3.3. Signature Production

The signable payload is the deterministic CBOR encoding (per Section 4.2 of [RFC8949]) of a CBOR map containing fields 0 through 7, with map keys sorted in ascending integer order. The Ed25519 signature [RFC8032] is computed over the raw bytes of this CBOR encoding and stored at key 8.¶

signable_payload = CBOR-Deterministic(fields[0..7])
signature        = Ed25519-Sign(private_key, signable_payload)

Deterministic CBOR encoding ensures that any conforming implementation produces identical byte sequences for the same logical content, which is essential for reproducible signature verification across heterogeneous platforms.¶

3.4. Block Hash and Chaining

The block hash is the SHA-256 digest of the complete deterministic CBOR encoding of the breadcrumb (fields 0 through 8 inclusive, i.e., including the signature):¶

BreadcrumbHash(B) = SHA-256(CBOR-Deterministic(B[0..8]))
B[N+1].field[6]   = BreadcrumbHash(B[N])
B[0].field[6]     = null

Each breadcrumb at index > 0 MUST carry the block hash of its immediate predecessor in field 6, forming an append-only hash chain. The genesis breadcrumb (index 0) MUST set field 6 to null (CBOR simple value 22).¶

4.1. Location Deduplication

Proof-of-Trajectory requires demonstrated movement. A conforming implementation MUST reject a breadcrumb if the H3 cell is identical to the immediately preceding breadcrumb. Implementations SHOULD also enforce a cap (default 10) on the number of breadcrumbs recordable at any single H3 cell to prevent stationary farming.¶

4.2. Minimum Collection Interval

Breadcrumbs SHOULD be collected at intervals of no less than 15 minutes. An implementation MAY allow shorter intervals during explicit "exploration" sessions but MUST NOT accept intervals shorter than 5 minutes.¶

4.3. Chain Verification

A Verifier MUST check:¶

1. Index values form a contiguous sequence starting at 0.¶

2. Timestamps are monotonically non-decreasing.¶

3. Each previousHash matches the block hash of the prior breadcrumb.¶

4. Each Ed25519 signature verifies against the identity public key and the canonical signed data.¶

7.1. Power Spectral Density Analysis

The primary diagnostic is the Power Spectral Density (PSD) of the displacement time series. Given a trajectory of N breadcrumbs with displacements d(i) between consecutive breadcrumbs, the PSD is computed via the Discrete Fourier Transform:¶

S(f) = |DFT(d)|^2

where d = [d(0), d(1), ..., d(N-1)]
and d(i) = haversine_distance(cell(i), cell(i-1))

The PSD is then fitted to a power-law model:¶

S(f) ~ 1 / f^alpha

The exponent alpha is the PSD scaling exponent -- referred to in the spectral analysis literature as the "spectral exponent" or "scaling exponent." In the context of human mobility, this quantity captures the degree of long-range temporal correlation in movement patterns. The theoretical significance of this exponent derives from Parisi's work demonstrating that biological systems operating at criticality produce characteristic scale-free correlations [PARISI-NOBEL]. The PSD scaling exponent is the critical diagnostic:¶

The bounds in Table 5 are the reference calibration derived in Section 7.5; they are indicative score inputs, not a classification gate, and MUST be re-derived per deployment.¶

A conforming implementation MUST compute the PSD scaling exponent over a sliding window of the most recent 64 breadcrumbs (minimum) to 256 breadcrumbs (recommended).¶

The alpha estimator is the log-periodogram (ordinary least-squares) regression of log-PSD on log-frequency -- the Geweke and Porter-Hudak estimator [GPH1983]. A conforming implementation MUST record the window length N and the fitted frequency range, and MUST reuse the identical window length and frequency range when calibrating and when scoring: alpha values obtained under different window lengths or fitted frequency ranges are not comparable.¶

The estimator's standard error, under log-periodogram asymptotics, is approximately¶

ell_bar = (1 / |F|) * sum_{k in F} ln(f_k)
Sxx     = sum_{k in F} ( ln(f_k) - ell_bar )^2
SE(alpha) ~ sqrt( (pi^2 / 6) / Sxx )

where F is the set of fitted frequency bins and ell_bar is the mean of the log-frequencies (not the log of the mean frequency). This is a model-dependent approximation under log-periodogram assumptions, not a universal guarantee for finite, quantized, deduplicated, or irregularly sampled trajectories; numeric SE values and any sample-length threshold derived from them MUST be verified for the deployment's pipeline before use as a conformance criterion.¶

The PSD scaling exponent is a scored feature, not a binary classification gate. It contributes to the Criticality Confidence (Section 7.2) and, through it, to trust scoring (Section 11). An implementation MUST NOT accept or reject a trajectory on the basis of alpha alone. Empirical validation (Section 7.5) shows that a fixed narrow band such as [0.30, 0.80] rejects the majority of genuine human trajectories; such a band MUST NOT be used as a hard acceptance criterion. Deployments MUST calibrate the acceptance range and the alpha score against representative human-mobility data for their population, processed through the identical pipeline: the same H3 resolution (Section 3.1), deduplication rule (Section 4.1), collection interval (Section 4.2), window length, and fitted frequency range. A calibration is not transferable to a deployment that differs in any element of this tuple.¶

The key insight is that automated movement generators tend to lack the long-range temporal correlations ("memory") present in human movement. A random walk produces white noise (alpha near 0). A deterministic replay produces brown noise (alpha near 2). Human trajectories fall between these extremes, but not in a band as narrow as earlier revisions assumed; the calibrated range and the achievable separation are established empirically in Section 7.5.¶

NOTE: Earlier revisions specified a fixed "biological" band [0.30, 0.80] centered at 0.55, informed by literature on 1/f-like properties of human motion [VADAI-GPS] [MACZAK-SPECTRAL]. Direct validation against a human-mobility dataset (Section 7.5) found that this fixed band does not hold for individual trajectories processed through the TRIP pipeline: it excludes most genuine human trajectories. The alpha acceptance range is therefore a per-deployment calibrated parameter, and alpha is used as a score rather than a gate.¶

7.2. Criticality Confidence Score

The Criticality Confidence is a value in [0, 1] derived from the PSD scaling exponent relative to the deployment's calibrated human range:¶

alpha_score = clamp(1 - |alpha - alpha_center| / alpha_halfwidth, 0, 1)

criticality_confidence = alpha_score * fit_reliability

where:
  alpha_center, alpha_halfwidth are calibrated per deployment
    (see {{empirical-validation}}; reference values
    alpha_center ~ 0.70, alpha_halfwidth ~ 0.55, giving the
    reference band of {{alpha-ranges}})
  fit_reliability is a reliability weight in [0, 1]; default 1.0

When fit_reliability is 1.0 (the default), criticality_confidence reduces to alpha_score: a single-factor score. A deployment using the default MUST describe the result as a one-factor alpha score and MUST NOT present it as the combination of two independent reliability factors.¶

The coefficient of determination (R-squared) of the log-log power-law regression MUST NOT be used as the fit_reliability term. The periodogram is chi-squared distributed at each frequency, so R-squared of a log-log line is not a valid goodness-of-fit measure; empirically it is near zero (Section 7.5) even for genuine human trajectories and would collapse the confidence to zero. The achievable R-squared is in fact limited by the estimator's own noise. Under the stated log-periodogram assumptions, the approximate expected explained-variance fraction is¶

R2_approx = Vs / (Vs + pi^2/6),  Vs = alpha^2 * Var_{k in F}( ln f_k )

so at human-range alpha this expected fraction is small -- on the order of the observed median R-squared near 0.04. It is an approximation of the expected value, not a guaranteed maximum across realizations, and it is a property of the estimator rather than of the trajectory; it is model-dependent and MUST be verified for the deployment's frequency selection before being quoted. fit_reliability SHOULD instead be derived from the calibrated separability of the alpha score (Section 7.5), or set to 1.0 where no better estimator is available.¶

A criticality_confidence below 0.5 SHOULD trigger elevated monitoring. A value below 0.3 SHOULD flag the trajectory for manual review or additional verification challenges.¶

7.3. The Levy Exponent Does Not Determine the Spectral Exponent

Earlier revisions posited an analytical "bridge" in which the truncated-Levy displacement exponent beta (Section 8.1) predicts the PSD scaling exponent alpha (Section 7.1) via alpha ~ (3 - beta) * g, placing alpha in the assumed biological range. Empirical validation (Section 7.5) does not support this relationship: synthetic trajectories drawn from the truncated-Levy law of Section 8.1 with beta ~ 1.75 -- matching the human step-size distribution -- produce alpha values near zero, far outside any human-calibrated range.¶

The correct statement is narrower: the marginal distribution of step magnitudes does not, by itself, determine their temporal correlation structure. beta characterizes the distribution of step magnitudes; alpha characterizes the temporal correlation structure of the displacement series. For independent, identically distributed step magnitudes the magnitude series is spectrally white regardless of the marginal step-size distribution, so matching the human step-size distribution does not reproduce the human temporal-correlation signature. This is not a claim of universal statistical independence of alpha and beta in real human trajectories, where the two may be coupled by the underlying mobility process.¶

This separation is a security property, not a defect. An adversary who replicates the Section 8.1 displacement law -- a documented, learnable distribution -- does not thereby reproduce the alpha signature; in validation (Section 7.5) such an adversary remains separable from genuine human trajectories by alpha. The property TRIP relies on is temporal correlation rather than the step-size distribution; the evidence establishes discrimination against the tested adversaries, not that temporal correlation is intrinsically difficult for a sophisticated adversary to reproduce. Implementations MUST NOT infer the PSD scaling exponent from the Levy displacement exponent using the previously proposed analytical relationship, and MUST NOT use their agreement as an internal-consistency check.¶

7.4. Convergence Analysis

The PSD scaling exponent, Levy flight parameters, and flock alignment metrics are fundamentally ensemble properties derived from statistical physics. Applying them to a single trajectory raises the question: how many breadcrumbs are required for these ensemble properties to converge on an individual trajectory with a given confidence level?¶

This section provides guidance on convergence behavior. Definitive false positive and false negative rates require empirical validation against real-world datasets (e.g., GeoLife, MDC), which is planned for a companion publication. The framework below describes the expected convergence properties and the protocol's mitigation strategies.¶

7.5. Empirical Validation

The statistical claims of this section were validated against real human mobility data and synthetic adversaries. Human trajectories were drawn from the GeoLife GPS dataset and processed through the TRIP pipeline exactly as specified (H3 resolution 10 quantization per Section 3.1, deduplication per Section 4.1, and the collection interval of Section 4.2). Synthetic adversaries -- random walk, Gaussian walk, correlated random walk, truncated-Levy (the Section 8.1 law), scripted deterministic movement, and integrated drift -- were generated and processed identically. The exponent alpha was computed by the Section 7.1 method and, independently, by Detrended Fluctuation Analysis (DFA) as a non-stationarity-robust cross-check.¶

Principal findings:¶

• As a score, alpha separates human from synthetic trajectories with area under the ROC curve approximately 0.85 against pooled adversaries and approximately 0.78 against an informed truncated-Levy adversary using the Section 8.1 law.¶

• A fixed band [0.30, 0.80] classifies only about one third of genuine human trajectories (Section Section 7.1 method) as biological -- unsuitable as a hard acceptance gate. A reference two-sided calibration of approximately [0.16, 1.25] yields human acceptance of roughly 60-68% at synthetic false-positive rates of 5-8%. A two-sided range is required: an integrated-drift adversary reaches alpha near 1.8.¶

• The log-log power-law fit is poor (median R-squared near 0.04), which is why R-squared is not used as a confidence measure (Section 7.2).¶

• the marginal step-size distribution does not determine the temporal-correlation structure (Section 7.3): an adversary matching the human step-size law does not reproduce the human alpha signature.¶

These results derive from a specific dataset and adversary set and are bounded accordingly; they establish the calibration methodology and the qualitative separation, not universal error rates. The methodology and artifacts are available for reproduction and per-deployment recalibration [TRIP-VALIDATION].¶

The following structural results are independent of any particular dataset and were reported from numerical simulation by S. Nikolaichuk; they are stated here pending independent reproduction. First, for independent, identically distributed step magnitudes the step-magnitude spectrum is white, so the estimator responds to temporal correlation and not to the marginal step-size law. Second, the log-periodogram R-squared is bounded by the estimator's own noise (Section 7.2), so a low R-squared is expected and is not evidence of a poor trajectory. Third, three pipeline parameters -- H3 resolution, the deduplication rule, and the window length -- can bias the estimated alpha, with downward effects reported under the tested simulation conditions; the observed direction depends on those conditions, which is why calibration MUST hold the full pipeline tuple (Section 7.1) fixed. These are properties of the estimator and the pipeline, not measurements of the GeoLife sample.¶

8.1. Truncated Levy Flights

Human displacement between consecutive recorded locations follows a truncated power-law distribution:¶

P(delta_r) ~ delta_r^(-beta) * exp(-delta_r / kappa)

where:
  delta_r = displacement distance (km)
  beta    = power-law exponent (typically 1.50 - 1.90)
  kappa   = exponential cutoff distance (km)

The exponent beta captures the heavy-tailed nature of human movement: most displacements are short (home to office) but occasional long jumps (travel) follow a predictable distribution. The cutoff kappa is learned per identity and represents the characteristic maximum range.¶

A conforming implementation MUST maintain a running estimate of beta and kappa for each identity by fitting the displacement histogram using maximum likelihood estimation over the most recent epoch (100 breadcrumbs).¶

A new displacement that falls outside the 99.9th percentile of the fitted distribution MUST increment the spatial anomaly counter.¶

As established in Section 7.3, beta (step-size distribution) and alpha (temporal correlation) are independent features. Implementations MUST NOT treat agreement between the fitted beta and the observed alpha as a consistency check; they measure different properties and are evaluated separately.¶

8.2. Trajectory Predictability

Research has demonstrated that approximately 93% of human movement is predictable based on historical patterns [SONG-LIMITS]. TRIP exploits this by maintaining a Markov Transition Matrix over anchor cells:¶

T[a_i][a_j] = count(transitions from a_i to a_j)
               / count(all departures from a_i)

where a_i, a_j are anchor cells.

An anchor cell is defined as any H3 cell where the identity has recorded 5 or more breadcrumbs. The transition matrix is rebuilt at each epoch boundary.¶

The predictability score Pi for an identity is the fraction of observed transitions that match the highest-probability successor in the Markov matrix. Human identities converge toward Pi values in the range [0.80, 0.95] after approximately 200 breadcrumbs. Deviations below 0.60 are anomalous.¶

8.3. Circadian and Weekly Profiles

The implementation SHOULD maintain two histogram profiles:¶

• A circadian profile C[hour] recording the probability of activity in each hour of the day (24 bins).¶

• A weekly profile W[day] recording the probability of activity on each day of the week (7 bins).¶

These profiles provide the temporal baseline for the Hamiltonian temporal energy component (Section 9.2).¶

9.1. H_spatial: Displacement Anomaly

Given the identity's fitted truncated Levy distribution P(delta_r), the spatial energy for a displacement delta_r is the negative log-likelihood (surprise):¶

H_spatial = -log(P(delta_r))

where P(delta_r) = C * delta_r^(-beta) * exp(-delta_r / kappa)
and C is the normalization constant.

Typical displacements yield H_spatial near the identity's historical baseline. A displacement that exceeds the identity's learned kappa cutoff by more than a factor of 3 produces an H_spatial value in the CRITICAL range.¶

9.2. H_temporal: Rhythm Anomaly

H_temporal = -log(C[current_hour]) - log(W[current_day])

Activity at 3:00 AM for an identity with a 9-to-5 circadian profile yields high H_temporal. Activity at 8:00 AM on a Tuesday for the same identity yields low H_temporal.¶

9.3. H_kinetic: Transition Anomaly

from_anchor = nearest anchor to previous breadcrumb
to_anchor   = nearest anchor to current breadcrumb
H_kinetic   = -log(max(T[from_anchor][to_anchor], epsilon))

where epsilon = 0.001 (floor to prevent log(0))

A home-to-office transition at 8:00 AM yields low H_kinetic. An office-to-unknown-city transition yields high H_kinetic.¶

9.4. H_flock: Topological Alignment

Inspired by Parisi's finding that starlings track their k nearest topological neighbors (k approximately 6-7) rather than all birds within a metric radius [BALLERINI-TOPOLOGICAL], the flock energy measures alignment between the identity's velocity vector and the aggregate velocity of co-located TRIP entities.¶

v_self  = displacement vector of current identity
v_flock = mean displacement vector of k nearest
          co-located identities (k = 7)

alignment = dot(v_self, v_flock)
            / (|v_self| * |v_flock|)

H_flock = 1.0 - max(alignment, 0)

When flock data is unavailable (sparse network or privacy constraints), the implementation SHOULD fall back to comparing the current velocity against the identity's own historical velocity distribution at the same location and time-of-day.¶

H_flock defeats GPS replay attacks: an adversary replaying a previously recorded trajectory will find that the ambient flock has changed since the recording, producing a misalignment signal.¶

9.5. H_contextual: Sensor Cross-Correlation

H_contextual = divergence(
  observed_imu_magnitude,
  expected_imu_magnitude_for(gps_displacement)
)

Implementations that lack IMU access MUST set H_contextual = 0 and SHOULD increase the weights of other components proportionally.¶

9.6. H_structure: Chain Structural Integrity

• Inter-breadcrumb timing regularity: excessively uniform intervals suggest automation.¶

• Hash chain continuity: any break in the chain produces maximum H_structure.¶

• Phase-space smoothness: the velocity-acceleration phase portrait of a human trajectory traces smooth loops, while bots produce either chaotic blobs or tight limit cycles.¶

9.7. Alert Classification

The total Hamiltonian H maps to an alert level. The baseline H_baseline is the rolling median of the identity's own recent energy values, making the threshold self-calibrating per identity:¶

10.1. Calibration Provenance

The criticality confidence (field 7) is computed relative to a deployment's calibrated human range (Section 7.2) and is therefore meaningful only together with the calibration that produced it. Field 15 carries that calibration, bound into the signed certificate, so a Relying Party can interpret field 7 and decide whether two Verifiers' values are comparable.¶

Field 15 is a calibration reference: a SHA-256 digest of an immutable, versioned calibration profile, with an OPTIONAL inline copy of the profile.¶

calibration-ref = {
  0 => bstr .size 32,          ; profile-digest
  ? 1 => calibration-profile   ; OPTIONAL inline copy
}

calibration-profile = {
  0  => uint,            ; profile_version
  1  => tstr,            ; estimator_id
  2  => uint,            ; h3_resolution
  3  => tstr,            ; deduplication_rule
  4  => uint,            ; collection_interval_s
  5  => uint,            ; window_n
  6  => [float, float],  ; fitted_frequency_range [lo, hi]
  7  => float,           ; alpha_center
  8  => float,           ; alpha_halfwidth
  9  => tstr,            ; reliability_model
  10 => tstr,            ; calibration_dataset_id
  11 => uint             ; calibration_date
}

The profile is encoded in the core deterministic CBOR encoding of [RFC8949] (Section 4.2.1). The profile digest is the SHA-256 of that deterministic encoding:¶

profile-digest = SHA-256( deterministic-CBOR( calibration-profile ) )

When an inline profile (key 1) is present, a recipient MUST compute its digest and MUST reject the certificate if the computed digest does not equal the referenced digest (key 0).¶

DOMAIN        = "TRIP-PoH-Certificate-v1"   ; ASCII label
signing-input = DOMAIN || deterministic-CBOR( cert-without-14 )
signature     = Ed25519( verifier_private_key, signing-input )

12.1. Chain-Level Replay Protection

The monotonically increasing index and the chaining via the previous block hash field provide replay protection within a single trajectory. A replayed breadcrumb will fail the chain integrity check. Cross-trajectory replay will fail Ed25519 signature verification.¶

12.2. Active Verification Protocol

The Active Verification Protocol provides cryptographic freshness guarantees by binding the Attestation Result to a Relying Party-supplied nonce, the current chain head, and the current time. This is the ONLY verification mode supported by TRIP. There is no passive verification mode.¶

The protocol proceeds as follows:¶

1. The Relying Party generates an unpredictable nonce (RECOMMENDED: 16 bytes from a cryptographically secure random number generator) and sends a Verification Request to the Verifier:¶

   VerificationRequest = {
     0 => bstr .size 32,   ; identity public key
     1 => bstr .size 16,   ; nonce
     2 => uint,            ; request timestamp
     3 => uint,            ; requested freshness window (seconds)
   }
   

   ¶

2. The Verifier delivers a Liveness Challenge to the Attester via a real-time channel (e.g., WebSocket push, push notification):¶

   LivenessChallenge = {
     0 => bstr .size 16,   ; nonce (from Relying Party)
     1 => bstr .size 32,   ; verifier identity (public key)
     2 => uint,            ; challenge timestamp
     3 => uint,            ; response deadline (seconds)
   }
   

   ¶

3. The Attester constructs and signs a Liveness Response binding the nonce to the current chain state:¶

   LivenessResponse = {
     0 => bstr .size 16,   ; nonce echo
     1 => bstr .size 32,   ; chain_head_hash
     2 => uint,            ; response timestamp
     3 => uint,            ; current breadcrumb index
     4 => bstr .size 64,   ; Ed25519 signature over fields 0-3
   }
   

   ¶

4. The Verifier validates the Liveness Response by checking:¶

   • The Ed25519 signature (field 4) is valid against the identity's public key over fields 0-3.¶

   • The nonce echo (field 0) matches the original Verification Request.¶

   • The chain_head_hash (field 1) is consistent with the Verifier's stored trajectory state.¶

   • The response timestamp (field 2) is within the deadline.¶

   • The breadcrumb index (field 3) matches or exceeds the Verifier's last known index.¶

5. Upon successful validation, the Verifier produces a fresh PoH Certificate with field 12 set to the nonce and field 13 set to the chain_head_hash, signs it, and returns it to the Relying Party.¶

6. The Relying Party verifies the PoH Certificate per Section 10, confirming that field 12 matches its original nonce.¶

If the Attester does not respond within the deadline, the Verifier MUST return an error. The Verifier MUST NOT issue a PoH Certificate without a valid Liveness Response.¶

12.3. Active Verification CDDL

The following CDDL [RFC8610] schema defines the Active Verification messages:¶

; Active Verification Protocol CDDL Schema

verification-request = {
  0 => bstr .size 32,        ; identity_key
  1 => bstr .size 16,        ; nonce
  2 => uint,                 ; request_timestamp
  3 => uint,                 ; freshness_window_seconds
}

liveness-challenge = {
  0 => bstr .size 16,        ; nonce
  1 => bstr .size 32,        ; verifier_key
  2 => uint,                 ; challenge_timestamp
  3 => uint,                 ; response_deadline_seconds
}

liveness-response = {
  0 => bstr .size 16,        ; nonce_echo
  1 => bstr .size 32,        ; chain_head_hash
  2 => uint,                 ; response_timestamp
  3 => uint,                 ; current_breadcrumb_index
  4 => bstr .size 64,        ; ed25519_signature
}

13.1. GPS Replay Attacks

An adversary records a legitimate trajectory and replays the GPS coordinates on a different device. TRIP detects this through multiple channels:¶

• H_flock: the ambient flock has changed since the recording.¶

• H_contextual: unless the adversary also replays Wi-Fi BSSIDs, cellular tower IDs, and IMU data, the context digest will not match.¶

• H_structure: the timing regularity of a replay is typically either too perfect or shifted in a detectable pattern.¶

13.2. Synthetic Walk Generators

• PSD scaling exponent test: random walk generators produce white noise (alpha approximately 0) and drift generators produce high alpha. In validation (Section 7.5) both fall well outside the calibrated human range and remain separable from human trajectories as a score; see Section 7.5 for the measured separation.¶

• Levy flight fitting: synthetic displacements rarely match the truncated power-law distribution with biologically plausible beta and kappa values.¶

• Predictability test: synthetic trajectories either show near-zero predictability (random) or near-perfect predictability (scripted), both outside the human [0.80, 0.95] range.¶

13.3. Emulator Injection

An adversary runs the TRIP client on an Android/iOS emulator with spoofed GPS. Detection relies on H_contextual (emulators lack real IMU data) and context digest (emulators lack real Wi-Fi and cellular data).¶

13.4. Device Strapping (Robot Dog Attack)

An adversary straps a phone to a mobile robot or drone. This is the most sophisticated attack because it produces real GPS, Wi-Fi, cellular, and IMU data from actual physical movement. Mitigation relies on PSD analysis (robotic movement lacks 1/f noise), phase-space smoothness (H_structure), and circadian profiles. This attack remains an active area of research.¶

13.5. Verifier Compromise

A compromised Verifier could issue fraudulent PoH Certificates. Mitigations: Relying Parties SHOULD accept certificates from multiple independent Verifiers; key rotation and revocation procedures SHOULD be established; the Active Verification Protocol ensures even a compromised Verifier cannot produce a valid certificate without the Attester's cooperation.¶

13.6. Denial of Service

Verifiers SHOULD rate-limit requests per identity and per Relying Party. The Active Verification Protocol's real-time requirement provides an inherent rate limit on valid completions.¶

13.7. Statistical Classifier Limitations

The Criticality Engine applies ensemble statistical properties (PSD scaling exponent, Levy flight parameters, flock alignment) to individual trajectories. As discussed in Section 7.4, the reliability of these classifiers depends on trajectory length. Implementers MUST be aware that:¶

• Classification confidence is low during the bootstrap regime (fewer than 64 breadcrumbs) and moderate during the provisional regime (64-199 breadcrumbs).¶

• alpha is a per-deployment-calibrated scored feature, not a fixed classification gate. Validation (Section 7.5) found that a fixed [0.30, 0.80] band rejects the majority of genuine human trajectories; deployments MUST calibrate the range against population-specific data.¶

• The composition of six Hamiltonian components provides defense in depth, but the components are not independent and the combined error rate is an empirical quantity (Section 7.5), not a product of per-test rates.¶

• The separation results in Section 7.5 derive from a specific dataset (GeoLife) and adversary set. They establish the calibration methodology and qualitative separation, not universal error rates; per-deployment validation against representative data remains REQUIRED.¶

• An acceptance band narrower than the estimator's standard error (Section 7.1) will reject genuine trajectories, and the pipeline biases (Section 7.5), which reduced estimated alpha under the tested conditions, fall hardest on low-mobility users, whose displacement series carry less spectral information. Deployments SHOULD ensure the calibrated band is wider than SE(alpha) and SHOULD assess false-rejection impact on low-mobility populations. This draft makes no quantified fairness claim absent representative testing.¶

• Score shopping: an identity able to request many certificates may retry until a favorable criticality score is issued. Verifiers SHOULD bound the number of certificate requests per identity over a time window. Per-identity rate limiting alone does not address an adversary controlling many identities (Sybil); see Section 13.6 and the Active Verification requirement (Section 12).¶

14.1. Quantization-Based Privacy

TRIP's privacy model is based on lossy spatial quantization, not on data locality. H3-quantized Evidence is transmitted from the Attester to the Verifier. Raw GPS coordinates MUST NOT be transmitted. At the default resolution 10, each cell covers approximately 15,000 m^2, providing meaningful ambiguity in populated areas.¶

14.2. Verifier Data Handling

The Verifier MUST NOT forward raw Evidence to Relying Parties. The Verifier MUST disclose its data retention policy. The Verifier SHOULD retain only statistical aggregates and MAY discard individual breadcrumbs after incorporation. The Verifier MUST support data deletion where required by law.¶

14.3. Relying Party Data Minimization

The PoH Certificate reveals statistical exponents and aggregate counts. A Relying Party does NOT learn which cities or specific locations the identity has visited, the identity's home or workplace, the identity's daily schedule, or any raw trajectory data.¶

14.4. Trajectory Correlation and Sybil Resistance

A single physical entity operating multiple TRIP identities simultaneously constitutes a Sybil attack. TRIP raises the cost: each identity requires a separate physical device, weeks of sustained movement, and independent trajectory accumulation. The H_flock component provides detection of co-located trajectories with identical displacement vectors.¶

14.5. Population Density Considerations

In sparsely populated areas, even cell-level granularity may narrow identification. Implementations SHOULD use lower resolution in rural areas and MAY allow users to override to a lower resolution at any time.¶

15.1. Multiple Verifier Deployments

Any entity that implements the verification procedures defined in this specification MAY operate as a TRIP Verifier. An Attester MAY submit Evidence to more than one Verifier.¶

15.2. Verifier Interoperability

All conforming Verifiers MUST implement chain integrity verification, PSD scaling exponent classification, and the PoH Certificate format. Two Verifiers processing the same Evidence SHOULD produce consistent alpha, beta, and kappa values within numerical precision bounds.¶

15.3. Transport Binding

This specification does not mandate a specific transport. Implementations MAY use HTTPS, WebSocket, CoAP, or any transport providing confidentiality and integrity protection. The Active Verification Protocol requires a real-time channel.¶

15.4. Naming System Integration

The binding of human-readable names to TRIP identities is outside the scope of this specification and is expected to be addressed in a companion document.¶

15.5. Accessibility and Low-Mobility Users

TRIP does not require geographic travel. It requires sustained physical existence over time. A person who remains in a single H3 cell generates a valid trajectory; the trust scoring formula assigns 20% weight to temporal continuity and 40% to breadcrumb count, both accumulating regardless of spatial diversity. The context digest provides environmental diversity even without movement. The Hamiltonian is self-calibrating per identity. For stationary users, implementations SHOULD supplement spatial PSD with temporal PSD (analyzing inter-breadcrumb timing patterns). Deployments MUST NOT impose minimum spatial diversity requirements that would exclude users with mobility limitations.¶

17.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/rfc/rfc2119>.

[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/rfc/rfc8032>.

[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/rfc/rfc8174>.

[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/rfc/rfc8610>.

[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/rfc/rfc8949>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

17.2. Informative References

[BALLERINI-TOPOLOGICAL]

Ballerini, M., Cabibbo, N., Candelier, R., Cavagna, A., Cisbani, E., Giardina, I., Lecomte, V., Orlandi, A., Parisi, G., Procaccini, A., Viale, M., and V. Zdravkovic, "Interaction ruling animal collective behavior depends on topological rather than metric distance", DOI 10.1073/pnas.0711437105, 2008, <https://doi.org/10.1073/pnas.0711437105>.

[BARABASI-MOBILITY]

Gonzalez, M.C., Hidalgo, C.A., and A.-L. Barabasi, "Understanding individual human mobility patterns", DOI 10.1038/nature06958, 2008, <https://doi.org/10.1038/nature06958>.

[CAVAGNA-STARLINGS]

Cavagna, A., Cimarelli, A., Giardina, I., Parisi, G., Santagati, R., Stefanini, F., and M. Viale, "Scale-free correlations in starling flocks", DOI 10.1073/pnas.1005766107, 2010, <https://doi.org/10.1073/pnas.1005766107>.

[GPH1983]

Geweke, J. and S. Porter-Hudak, "The Estimation and Application of Long Memory Time Series Models", DOI 10.1111/j.1467-9892.1983.tb00371.x, 1983, <https://doi.org/10.1111/j.1467-9892.1983.tb00371.x>.

[H3]

Uber Technologies, "H3: Uber's Hexagonal Hierarchical Spatial Index", 2023, <https://h3geo.org/>.

[I-D.fossati-seat-expat]

Sardar, M. U., Fossati, T., Reddy.K, T., Sheffer, Y., Tschofenig, H., and I. Mihalcea, "Remote Attestation with Exported Authenticators", Work in Progress, Internet-Draft, draft-fossati-seat-expat-04, 19 September 2026, <https://datatracker.ietf.org/doc/html/draft-fossati-seat-expat-04>.

[I-D.lkspa-rats-verifiable-geo-fence]

Krishnan, R., Smith, N., Lopez, D., Prasad, A., Addepalli, S., and H. Birkholz, "Verifiable Proof of Environment Attestation Profile", Work in Progress, Internet-Draft, draft-lkspa-rats-verifiable-geo-fence-03, 13 June 2026, <https://datatracker.ietf.org/doc/html/draft-lkspa-rats-verifiable-geo-fence-03>.

[I-D.mandyam-rats-proxlocclaim]

Mandyam, G., "The Proximate Location Claim", Work in Progress, Internet-Draft, draft-mandyam-rats-proxlocclaim-01, 17 January 2024, <https://datatracker.ietf.org/doc/html/draft-mandyam-rats-proxlocclaim-01>.

[I-D.richardson-rats-geographic-results]

Richardson, M., "Geographic Attestation Results", Work in Progress, Internet-Draft, draft-richardson-rats-geographic-results-03, 3 September 2026, <https://datatracker.ietf.org/doc/html/draft-richardson-rats-geographic-results-03>.

[MACZAK-SPECTRAL]

Maczak, B., "General spectral characteristics of human activity", DOI 10.1038/s41598-024-54165-4, 2024, <https://doi.org/10.1038/s41598-024-54165-4>.

[PARISI-NOBEL]

The Nobel Foundation, "Nobel Prize in Physics 2021: Giorgio Parisi", 2021, <https://www.nobelprize.org/prizes/physics/2021/parisi/facts/>.

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

[SONG-LIMITS]

Song, C., Qu, Z., Blumm, N., and A.-L. Barabasi, "Limits of Predictability in Human Mobility", DOI 10.1126/science.1177170, 2010, <https://doi.org/10.1126/science.1177170>.

[TRIP-VALIDATION]

Posada, C. A. and S. Nikolaichuk, "TRIP Criticality Engine: Empirical Validation against Human Mobility Data (methodology and artifacts)", 2026, <https://github.com/GNS-Foundation/trip-validation/releases/tag/v0.1.0>.

[VADAI-GPS]

Vadai, G., Antal, A., and Z. Gingl, "Spectral Analysis of Fluctuations in Humans' Daily Motion", DOI 10.1142/S0219477519500287, 2019, <https://doi.org/10.1142/S0219477519500287>.

A.1. EAT Location Claim

The Entity Attestation Token [RFC9711] defines a location claim that conveys a single point-in-time geographic position in WGS-84 coordinates. The claim provides no temporal depth, no privacy quantization, and no behavioral context. TRIP could emit its Trajectory Identity Token or Proof-of-Humanity Certificate as an EAT claim, providing longitudinal behavioral evidence within an EAT-formatted Attestation Result. The two are complementary.¶

A.2. Proximate Location Claim

The Proximate Location Claim [I-D.mandyam-rats-proxlocclaim] defines evidence of relative position derived from secure ranging between two devices, typically using ultra-wideband (UWB) radio per FiRa Consortium specifications. Proximate Location is instantaneous and pairwise; TRIP is longitudinal and self-attested. Proximate Location requires dedicated radio hardware in both endpoints; TRIP uses commodity GNSS and ambient signals already present on consumer mobile devices.¶

A.3. Verifiable Geofencing for Workloads

The Verifiable Geofencing draft [I-D.lkspa-rats-verifiable-geo-fence] targets confidential computing workloads, providing cryptographically verifiable proof-of-residency that binds a workload identity to a host platform and a geographic boundary. Verifiable Geofencing answers "where is this workload executing?". TRIP answers "who is the human or autonomous entity behind this identity, and how has that entity moved over time?". The two address orthogonal concerns: residency versus operator integrity.¶

A.4. Geographic Attestation Results

The Geographic Results draft [I-D.richardson-rats-geographic-results] defines how geographic location is conveyed within the RATS architecture as an attestation result, carrying the basis on which the location claim rests (for example, evidence, endorsement, or attestation result). It answers where an entity is, with explicit provenance for that assertion. TRIP instead conveys how an entity has moved over time as behavioral evidence of humanity; a TRIP token can be expressed as, or carried alongside, a geographic result. The two are complementary: location with provenance versus longitudinal operator integrity.¶

A.5. Comparison Summary

TRIP is the only proposal in this set that uses behavioral trajectory over time as its source of evidence. The others provide instantaneous location claims, jurisdictional residency proofs, or one-time endorsements. TRIP is intended to coexist with these specifications, supplying a distinct dimension of evidence -- continuity of physical existence -- that none of them addresses.¶

B.1. Changes from -02

This section summarizes the substantive changes from draft-ayerbe-trip-protocol-02:¶

• Replaced the term "Parisi Factor" with the standard spectral analysis term "PSD scaling exponent alpha" throughout the document. The theoretical contribution of Parisi's work is acknowledged in the motivation and terminology, not in the variable naming.¶

• Added Section 7.3 (Levy-PSD Bridge) providing the analytical relationship between the Levy flight displacement exponent beta and the PSD scaling exponent alpha, with supporting references to empirical studies [MACZAK-SPECTRAL] [VADAI-GPS].¶

• Added Section 7.4 (Convergence Analysis) addressing the application of ensemble statistical properties to single trajectories, including minimum trajectory length guidance and error rate estimation framework.¶

• Removed Passive Verification mode entirely (Section 12). All Attestation Results MUST now be produced via the Active Verification Protocol with Relying Party-supplied nonces. The PoH Certificate fields for nonce (field 12) and chain head hash (field 13) are now REQUIRED, not optional.¶

• Updated the PoH Certificate (Section 10) to reflect mandatory Active Verification fields.¶

• Added references to recent empirical studies on spectral properties of human GPS trajectories.¶

B.2. Changes from -03

This section summarizes the changes from draft-ayerbe-trip-protocol-03:¶

• Added Appendix A (Relationship to Other Geo-Location Proposals) positioning TRIP relative to four parallel proposals: EAT Location Claim, Proximate Location, Verifiable Geofencing, and PoP Endorsement, per the commitment made on rats@ietf.org in February.¶

• Added RFC 8610 reference and citation in Section 12.3.¶

• Editorial cleanup of Section 16.¶