]> Humotica

Den Dolder Netherlands jasper@humotica.com https://humotica.com

Humotica

root_ai@humotica.nl https://humotica.com

Security Internet Engineering Task Force verification continuous-authentication biometric behavioral predictive credentials This document specifies RVP (Real-time Verification Protocol), a protocol for continuous, multi-layer identity and process verification. Unlike traditional authentication models that verify once and trust until session expiry, RVP treats every interaction as a verification moment. Each moment produces a cryptographic evidence token capturing who, what, when, how, and with what confidence the verification succeeded or failed. RVP defines a Verification Cascade: an ordered chain of verification methods (biometric, behavioral, device telemetry, environmental context) where each layer activates only when the preceding layer produces insufficient confidence. The cascade operates within a Predictive Airlock that pre-renders expected outcomes and detects deviations in real-time. RVP integrates with TIBET for provenance tokens, UPIP for process integrity evidence, JIS for identity semantics, and W3C Verifiable Credentials for credential issuance and presentation. The protocol is designed for local-first, decentralized operation with zero dependency on centralized identity providers.

Introduction Modern identity verification operates on a flawed assumption: verify once, trust until the session expires. A user authenticates at login -- password, MFA token, biometric scan -- and the system grants a session token that remains valid for minutes, hours, or days. During that period, the system has no evidence that the same person is still present, that the device hasn't been compromised, or that the user's intent aligns with their actions. This "verify-then-trust" model was designed for an era of keyboard-and-mouse interaction with stationary computers. It does not address:

• Mobile devices that change hands, networks, and locations
• AI agents that act autonomously on behalf of users
• Multi-actor processes that span devices and trust domains
• Continuous interactions where identity must be re-established moment by moment
• Regulatory requirements (, , ) that demand continuous monitoring and auditable evidence

This document specifies RVP (Real-time Verification Protocol), a protocol that replaces session-based trust with continuous evidence-based verification. RVP treats every interaction as a verification moment, producing cryptographic evidence of identity confidence at each point.

Problem Statement Current verification systems suffer from five structural failures:

1. TEMPORAL GAP: Verification happens once; trust persists indefinitely. A session token issued at 09:00 proves nothing about identity at 09:05.
2. SINGLE MODALITY: Systems rely on one verification method (password, fingerprint, face). When that method fails or is compromised, the system has no fallback with evidence.
3. CENTRALIZED TRUST: Identity providers (IdPs) create single points of failure and surveillance. A compromised IdP compromises all dependent services.
4. NO PREDICTION: Systems react to events after they happen. There is no mechanism to pre-compute expected behavior and detect deviations in real-time.
5. ENFORCEMENT WITHOUT EVIDENCE: Systems block actions based on rules. When a block occurs, the system records "access denied" but not WHY the request was suspicious, WHAT signals contributed, or HOW the decision was reached.

RVP addresses all five by defining:

• A CONTINUOUS verification model that produces evidence at every interaction
• A CASCADE of verification methods with ordered fallback
• A LOCAL-FIRST architecture with no required central authority
• A PREDICTIVE AIRLOCK that pre-renders expected state and detects deviations before they execute
• An EVIDENCE-FIRST approach where every decision is provable

Design Principles RVP is built on five principles:

EVIDENCE OVER ENFORCEMENT:

The system proves what happened. It does not enforce what should happen. A mismatch is recorded as evidence, not converted into a block. Enforcement can be bypassed; evidence cannot be un-recorded.

CONTINUOUS OVER SESSION:

Every interaction is a verification moment. There are no trusted sessions. Confidence is a continuous score that rises and falls with evidence.

LOCAL OVER CENTRAL:

Verification happens on-device or at the nearest edge node. No centralized identity provider is required. The protocol MUST operate fully offline with degraded but functional verification.

PREDICTIVE OVER REACTIVE:

The system pre-renders expected outcomes before actions execute. Deviation from prediction is the primary signal, not pattern matching against known attacks.

MINIMAL OVER MAXIMAL:

Each verification moment collects only the telemetry needed for the current confidence level. Biometric data is processed locally and reduced to hashes. Raw data never leaves the device unless the user explicitly consents.

Terminology 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 .

Verification Moment

A single point in time where the system evaluates identity confidence based on available telemetry. Produces exactly one Verification Token.

Verification Cascade

An ordered sequence of verification methods (layers) where each subsequent layer activates when the preceding layer produces insufficient confidence. The cascade terminates at the first layer that meets the required confidence threshold, or at HALT if no layer succeeds.

Predictive Airlock

A mechanism that pre-renders the expected outcome of an action before execution. The delta between prediction and reality is a verification signal. Based on the Airlock concept defined in tibet-triage .

Verification Token

A cryptographic record of a single verification moment. Contains: method used, confidence score, telemetry hash (not raw data), timestamp, device context, cascade path, and TIBET provenance fields.

Confidence Score

A value between 0.0 (no confidence) and 1.0 (full confidence) representing the system's belief that the claimed identity matches the actual identity at this moment.

Cascade Layer

A single verification method within the cascade (e.g., keystroke dynamics, facial recognition, fingerprint, device telemetry). Each layer has an independent confidence output.

Telemetry Signal

A measurable data point used as input to a cascade layer. Examples: typing speed, face geometry hash, GPS coordinates, NFC chip response.

Delta

The measured difference between predicted state and actual state at a verification moment. A delta of zero indicates perfect prediction match.

Hard Stop

A cascade outcome where no verification method produces sufficient confidence and the system halts the current action. A hard stop produces a Verification Token with confidence 0.0 and full evidence of all cascade layers attempted.

Soft Verify

A cascade outcome where confidence is below threshold but above zero. The system requests additional verification (deeper cascade) without blocking the action.

Profile

A locally-stored behavioral model for a known identity. Contains statistical baselines for telemetry signals (typing speed, active hours, common locations, device usage patterns). Profiles are never transmitted; only profile hashes are included in Verification Tokens.

HALT

Terminal state of a cascade where accumulated evidence indicates identity cannot be verified. Produces a full evidence token and stops the current action.

GO

Terminal state of a cascade where accumulated evidence meets or exceeds the required confidence threshold. Produces an evidence token and permits the action.

Protocol Overview

Continuous vs. Session-Based Verification Traditional session-based verification: Session Token issued T=1 Action -> Token valid? Yes -> Permit T=2 Action -> Token valid? Yes -> Permit ... T=3600 Action -> Token valid? Yes -> Permit T=3601 Token expires -> Re-login required ]]> The system has NO evidence about identity at T=1 through T=3600. It trusts the session token, which proves only that someone authenticated at T=0. RVP continuous verification: GO (evidence token produced) T=0.004 Action executes T=1.000 Action requested T=1.001 Airlock pre-renders expected outcome T=1.002 Cascade evaluates: keystroke deviates T=1.003 Confidence: 0.61 -> SOFT VERIFY (deeper cascade) T=1.004 Face check: match -> Confidence: 0.89 -> GO T=2.000 Action requested T=2.001 Airlock pre-renders expected outcome T=2.002 Delta: prediction != reality (unexpected command) T=2.003 Cascade evaluates: keystroke + device + face + finger T=2.004 Confidence: 0.12 -> HALT (full evidence token) ]]> Every action produces evidence. The confidence score is computed fresh at every moment. There is no cached trust.

The Verification Moment A Verification Moment is the atomic unit of RVP. It consists of:

1. TRIGGER: An action is requested (command, API call, data access, navigation, transaction)
2. PREDICTION: The airlock pre-renders the expected outcome based on current state, user profile, and context
3. CASCADE: Telemetry layers evaluate identity confidence
4. DELTA: Predicted outcome is compared to actual signals
5. DECISION: GO, SOFT VERIFY, or HALT
6. TOKEN: A Verification Token is produced with all evidence

The entire moment SHOULD complete within the latency budget defined by the deployment context. For interactive systems, this budget is typically 50-200ms. For API calls, the budget is typically 1-10ms overhead.

Architecture Overview

RVP Architecture | Predictive |-->| Verification | | | | Signals | | Airlock | | Cascade | | | +----------+ +--------------+ +------------------+ | | | | | | | | Pre-rendered Confidence | | | expected score | | | state | | | | | v | | | | +--------------+ | | | +----------->| Delta | | | | | Comparator | | | | +--------------+ | | | | | | | v | | | +------------------+ | | +------------------------->| Verification | | | | Token | | | | (TIBET-signed) | | | +------------------+ | | | | | GO / VERIFY / HALT | +-------------------------------------------+----------------+ | v +------------------+ | Action / Block | | (with evidence) | +------------------+ ]]>

Verification Cascade The Verification Cascade is the core decision engine of RVP. It evaluates identity through an ordered sequence of layers, where each layer adds confidence or triggers deeper verification.

Cascade Layers RVP defines six standard cascade layers. Implementations MAY support additional layers. Implementations MUST support at least two layers to qualify as RVP-compliant. "Passive" indicates the layer can operate without explicit user action. Passive layers are preferred because they enable continuous verification without interrupting the user.

Layer Activation The cascade activates layers based on the Confidence Deficit: the difference between the required confidence threshold and the current accumulated confidence. deficit: 0.45 -> continue L1 + L3 DEVICE: 0.65 confidence -> deficit: 0.20 -> continue L1 + L3 + L6: 0.87 confidence -> deficit: 0.00 -> GO ]]> Layers are activated in priority order. Each layer's confidence is ADDED to the accumulated score (with diminishing weight for lower-priority layers). The cascade terminates when:

• Accumulated confidence >= required threshold: GO
• All layers exhausted, confidence > 0 but < threshold: SOFT VERIFY (request explicit verification)
• All layers exhausted, confidence < minimum: HALT
• Any single layer produces negative confidence (active contradiction): immediate HALT

Confidence Scoring Each cascade layer produces a Layer Confidence value between -1.0 and 1.0:

• 1.0: Perfect match with profile
• 0.0: No signal (layer unavailable or inconclusive)
• -1.0: Active contradiction (definite mismatch)

Negative values indicate the layer has positive evidence that the identity does NOT match. A single layer producing -0.5 or lower SHOULD trigger immediate HALT regardless of other layers. The Accumulated Confidence is computed as: Weights MUST sum to 1.0. Default weight distribution assigns equal weight to all activated layers.

Cascade Resolution The cascade resolves to one of three states:

GO:

C_total >= threshold. Action permitted. Verification Token records all layer outputs as evidence.

SOFT VERIFY:

0.0 < C_total < threshold. Action paused. System requests additional verification (e.g., explicit fingerprint scan, face check). This is NOT a block; it is a request for more evidence. The user experience SHOULD be minimal friction (e.g., a fingerprint touch, a glance at camera).

HALT:

C_total <= 0.0, or any layer produced active contradiction, or all layers exhausted below minimum threshold. Action blocked. Full evidence token produced. System MUST NOT disclose which specific layer triggered the halt (to prevent adversarial adaptation).

Cascade Diagram

Cascade Flow = threshold |L1 KEYSTR|----------------------------------------> GO +----+----+ | insufficient v +---------+ >= threshold (cumulative) |L2 BIOMET|----------------------------------------> GO +----+----+ | insufficient contradiction |<-------------------------------------------- HALT v +---------+ >= threshold (cumulative) |L3 DEVICE|----------------------------------------> GO +----+----+ | insufficient v +---------+ >= threshold (cumulative) |L4 VOCAL |----------------------------------------> GO +----+----+ | insufficient v +---------+ >= threshold (cumulative) |L5 BEHAV |----------------------------------------> GO +----+----+ | insufficient v +---------+ >= threshold (cumulative) |L6 AIRLK |----------------------------------------> GO +----+----+ | exhausted v C > 0? --yes--> SOFT VERIFY (request explicit input) | no | v HALT (full evidence token) ]]>

Predictive Airlock The Predictive Airlock is what distinguishes RVP from reactive verification systems. Instead of evaluating actions after they occur, the airlock PRE-RENDERS the expected outcome and measures the delta between prediction and reality.

Pre-Rendering Expected State At each verification moment, the airlock computes: EXPECTED_STATE = f(current_state, user_profile, action_request) This computation uses:

• Current system state (files, processes, network, memory)
• User behavioral profile (typical actions, sequences, timing)
• The requested action (command, API call, navigation)
• Historical patterns (what usually follows this action)

The expected state is computed BEFORE the action executes. For compute-intensive predictions, the airlock MAY use VRAM- accelerated pre-rendering. For resource-constrained devices, the airlock MAY use statistical models in RAM. high confidence signal ]]>

Delta Detection The delta between prediction and reality is computed as: The distance function is domain-specific:

• For commands: edit distance between expected and actual
• For timing: standard deviations from profile mean
• For sequences: probability under profile Markov model
• For outputs: structural diff of expected vs. actual result

A delta of 0.0 means perfect prediction match (strong positive signal). Increasing delta values indicate increasing deviation from expected behavior.

Deviation Classification Deviations are classified into four categories:

Airlock Resolution The airlock contributes to the cascade as L6 (AIRLOCK layer). Its confidence output is derived from the delta: This means a perfect prediction match contributes maximum confidence, while a complete deviation contributes zero (or negative, if the action contradicts the profile entirely). The airlock SHOULD maintain a rolling prediction model that adapts to the user's evolving behavior. Model updates MUST be stored locally and MUST NOT be transmitted.

Telemetry Layers Each telemetry layer defines what signals it collects, how confidence is computed, and what data is retained (as hashes only, never raw biometric data).

L1 KEYSTROKE - Input Behavioral Biometrics Signals:

• Typing speed (words per minute, rolling average)
• Key press duration (per-key timing profile)
• Inter-key interval patterns
• Error rate and correction patterns
• Language and shorthand patterns (e.g., "t" for "het")
• Capitalization habits
• Command vocabulary (for CLI interactions)

Confidence computation:

• Compare current session signals to stored profile
• Statistical distance (Mahalanobis) from profile centroid
• Confidence = 1.0 - normalized_distance

Privacy:

• Raw keystrokes are NEVER stored or transmitted
• Only statistical aggregates are retained in profile
• Profile is stored locally, encrypted at rest
• Verification Token contains only: confidence score + profile_hash + signal_deviation_category

Example:

L2 BIOMETRIC - Physical Identity Signals Sub-layers (activated in order):

L2a FACE:

Facial geometry hash (not raw image). Liveness detection (anti-spoofing). Confidence based on match score to enrolled template. Failure modes: poor lighting, camera obstruction, face covering produce confidence: 0.0 (inconclusive).

L2b FINGERPRINT:

Minutiae hash (not raw fingerprint). Sensor quality assessment. Confidence based on match score to enrolled template. Activated when L2a fails or produces low confidence.

L2c IRIS (if available):

Iris code hash. Activated when L2a and L2b both fail.

Privacy:

• Biometric templates are stored ONLY on-device
• Templates MUST be encrypted with device-bound key
• Templates MUST NOT be transmittable (bound to hardware secure element where available, e.g., TEE/SE)
• Verification Token contains only: confidence score + method_used + template_hash (not template itself)

Fallback chain: confidence > 0? -> use it | confidence = 0 (camera fail) | v Fingerprint -> confidence > 0? -> use it | confidence = 0 (sensor fail) | v Iris -> confidence > 0? -> use it | confidence = 0 (no sensor) | v L2 overall confidence: 0.0 (all biometric unavailable) -> cascade continues to L3 ]]>

L3 DEVICE - Hardware and Network Context Signals:

• Device fingerprint (hardware identifiers, secure element)
• Network type and characteristics (WiFi, cellular, VPN)
• Geolocation (GPS, cell tower, WiFi positioning)
• NFC responses (for document/card binding)
• Installed software state (relevant security patches)
• Battery state, sensor availability

Confidence computation:

• Device fingerprint match to enrolled device: 0.3 base
• Network consistency with profile: +0.1 to +0.2
• Location consistency with profile: +0.1 to +0.2
• NFC document binding (passport, ID): +0.3

Anomaly detection:

• VPN where profile shows direct connection: -0.2
• New country where profile shows single country: -0.3
• Device fingerprint mismatch: -0.5 to -1.0
• NFC document mismatch: -1.0 (immediate HALT)

NFC Document Binding: read signed data from chip 2. Verify document signature (issuing authority CA) 3. Compare document identity to enrolled profile 4. Produce confidence: match=0.95, partial=0.5, fail=0.0 ]]> This layer is critical for compliance, where the European Digital Identity Wallet (EUDIW) requires high-assurance identity verification for cross-border services.

L4 VOCAL - Acoustic Telemetry Signals:

• Voice frequency profile (fundamental + harmonics)
• Speech cadence and rhythm
• Sub-verbal signals (throat sounds, acknowledgments)
• Silence/speech ratio patterns
• DTMF-like tonal analysis for non-speech vocalizations

This layer operates passively when audio input is available (e.g., voice calls, voice commands, ambient microphone with consent). It does NOT require the user to speak specific phrases. Confidence computation:

• Voice profile match: 0.0 to 0.7
• Sub-verbal pattern match: 0.0 to 0.3
• Combined: weighted sum

Privacy:

• Audio is processed in real-time and immediately discarded
• Only statistical features are retained (frequency profile)
• Raw audio MUST NOT be stored or transmitted
• User MUST explicitly consent to vocal telemetry

Human DTMF Integration: Sub-verbal signals (throat sounds indicating "yes", "no", "hmm", "ok") can serve as continuous passive authentication. These signals are distinct per individual and difficult to replicate. A simple throat-clear or acknowledgment sound provides a telemetry data point without requiring conscious user action.

L5 BEHAVIORAL - Intent vs. Action Analysis Signals:

• Action sequence probability (does this action follow logically from previous actions?)
• Time-of-day patterns (active hours profile)
• Interaction frequency and rhythm
• Task context (what project, what goal)
• Command sophistication level (matches user skill profile?)

Confidence computation:

• Action probability under profile model: 0.0 to 0.5
• Temporal consistency: 0.0 to 0.2
• Context consistency: 0.0 to 0.3

This layer detects anomalies like:

• A developer suddenly running unfamiliar admin commands
• Actions at 3 AM when profile shows 9-23 active hours
• Sophisticated attacks from a profile with basic skill level
• Rapid command sequences where profile shows deliberate pace

L6 AIRLOCK - Predictive Delta Verification This layer uses the Predictive Airlock () to compute the delta between expected and actual state. It is unique among cascade layers because it operates on the ACTION rather than the IDENTITY. The insight: identity verification and action verification are the same thing. If the action matches what this identity would do, both the identity and the action are verified simultaneously. Confidence computation:

• Delta = 0.0: full confidence (1.0)
• Delta = 0.5: moderate confidence (0.5)
• Delta = 1.0: zero confidence (0.0)
• Delta > 1.0 (impossible action): negative (-0.5 to -1.0)

Verification Token Every verification moment produces exactly one Verification Token. The token is the atomic evidence unit of RVP.

Token Structure

Verification Token Example L3->L6->GO", "time_elapsed_ms": 3 }, "tibet": { "erin": "verification_moment", "eraan": ["profile_hash", "device_hash", "action_hash"], "eromheen": {"location": "local", "network": "wifi"}, "erachter": "continuous identity verification" }, "token_hash": "rvp:sha256:7d3f..." } ]]>

Token Lifecycle Verification Tokens are immutable once created. They follow a simple lifecycle: STORED -> (optionally) CHAINED -> ARCHIVED ]]> Tokens are stored locally on-device. They MAY be transmitted to a verifier (e.g., a service provider) as proof of verification. When transmitted, only the token is sent -- never the underlying telemetry data.

Token Chain Consecutive Verification Tokens form a chain. Each token references its predecessor: The chain provides:

• CONTINUITY PROOF: This identity has been continuously verified for N moments over T time period
• TREND ANALYSIS: Confidence is stable, rising, or falling
• ANOMALY DETECTION: A sudden break in the chain (missing tokens) is itself a verification signal

TIBET Integration Every Verification Token includes TIBET provenance fields :

• ERIN (what's in it): The verification result and method
• ERAAN (what's attached): Profile hash, device hash, action hash, previous token reference
• EROMHEEN (what's around it): Location, network, device state, environmental context
• ERACHTER (what's behind it): Why this verification was triggered (action request, timer, anomaly)

This ensures every verification moment is not just recorded but PROVENANCE-TRACKED: who verified, how, when, why, and with what evidence.

Cascade Fallback Protocol When a cascade layer fails (hardware unavailable, inconclusive result, or active contradiction), RVP defines a structured fallback protocol.

Fallback Triggers A fallback is triggered when:

• Layer hardware is unavailable (camera broken, no NFC)
• Layer produces confidence = 0.0 (inconclusive)
• Layer produces negative confidence (contradiction)
• Layer times out (exceeds latency budget)

Fallback Flow 0? -> SOFT VERIFY C_total <= 0? -> HALT ]]> The fallback flow is TRANSPARENT: the Verification Token records which layers were attempted, which failed, and why. This evidence is critical for audit and for identifying systematic failures (e.g., a camera that fails frequently may need replacement).

Flare Integration When a verification cascade cannot complete locally (all local methods exhausted, device degraded), RVP MAY use the Flare Rescue Protocol to request verification assistance from a nearby trusted node. I-Poll -> Trusted edge node | v Edge node performs additional verification: - Network reputation check - Cross-reference device registry - Historical chain analysis | v FlareResult -> additional confidence: +0.3 Combined: 0.7 -> SOFT VERIFY (not HALT) ]]> Flare-assisted verification MUST be recorded in the Verification Token with the assisting node's identity and the specific methods used.

Hard Stop Conditions RVP defines conditions that trigger immediate HALT regardless of accumulated confidence:

1. Any layer produces confidence <= -0.5 (strong contradiction)
2. Device fingerprint does not match any enrolled device
3. NFC document signature verification fails
4. Cascade chain shows gap (missing tokens in sequence)
5. Concurrent sessions detected on different devices with conflicting identity claims

Hard stops are FINAL for the current action. The user MUST re-establish identity through an explicit, high-assurance verification flow (e.g., NFC passport tap + biometric).

Credential Binding RVP provides the evidence layer beneath W3C Verifiable Credentials . Where a Verifiable Credential says "this person is 18+," RVP provides the cryptographic evidence of HOW that was determined, WHEN, by WHAT method, and with WHAT confidence.

W3C Verifiable Credentials Integration A Verifiable Credential (VC) consists of:

• Claims (e.g., "age >= 18", "name: ...", "nationality: ...")
• Issuer signature
• Credential metadata

What a VC does NOT contain:

• HOW the issuer verified the claims
• WHEN the verification last occurred
• Whether the subject is still the person who was verified
• What evidence supports the claims right now

RVP fills this gap by attaching an RVP Evidence Chain to any Verifiable Credential:

Credential Issuance from RVP Evidence A credential issuer can use an RVP evidence chain as the basis for issuing a Verifiable Credential: | | | | | | RVP cascade: | | | L2a face -> match | | | L3 NFC passport -> 18+ | | | L6 airlock -> nominal | | | | | | Evidence chain | | | produced (3 tokens) | | | | | | |-- evidence chain --->| | | | | | Issuer verifies: | | | - chain integrity | | | - method sufficiency| | | - confidence levels | | | | |<------ Verifiable Credential --------------------| | (with rvpEvidence attached) | ]]>

Credential Presentation with RVP Proof When presenting a credential to a verifier, the holder can attach CURRENT RVP evidence proving they are still the person the credential was issued to: | | | | | | RVP cascade NOW: | | | L1 keystroke -> match | | | L2a face -> match | | | | | | Fresh verification | | | token produced | | | | | | |-- VC + fresh RVP --->| | | | | | Verifier checks: | | | 1. VC signature OK | | | 2. RVP chain valid | | | 3. Fresh token < 5s | | | 4. Same profile_hash| | | | |<------ Access granted (with evidence) -----------| ]]> This solves the "stolen credential" problem: even if someone obtains a copy of the VC, they cannot produce a matching RVP chain because the cascade layers (biometric, behavioral, device) will not match the enrolled profile.

Age Verification Use Case A common W3C VC use case is age verification. RVP enables continuous age verification without revealing exact age: extract date of birth - Face match to passport photo -> confidence 0.92 - Issue VC: "ageOver: 18" with RVP evidence chain Step 2: Subsequent presentations (continuous) - Present VC to service - RVP produces fresh verification token: L1 keystroke: profile match (0.4) L2a face: same person as passport (0.5) Combined: 0.9 -> GO - Verifier receives: VC + proof that holder IS the subject Zero-knowledge property: - Verifier learns: "this person is 18+" - Verifier does NOT learn: exact age, name, passport number - Verifier DOES learn: verification method and confidence ]]>

Digital Passport / Digital ID (eIDAS 2.0) The European Digital Identity Wallet (EUDIW), mandated by regulation, requires:

• High-assurance identity verification (Level of Assurance: High)
• Cross-border interoperability
• User control over shared attributes
• Offline capability

RVP aligns with EUDIW by providing:

• LOA High verification through cascade (NFC document + biometric + device binding)
• Interoperable evidence tokens (JSON, TIBET-signed)
• Selective disclosure: only confidence scores and method types are shared, never raw biometric data
• Offline: cascade operates locally, tokens stored on-device, evidence chain verifiable without network

Local-First Architecture

On-Device Processing RVP is designed to run entirely on-device. The verification engine, profile storage, telemetry processing, and token generation all operate locally. This is not optional; it is a core protocol requirement. Implementations MUST:

• Process all biometric data on-device
• Store profiles only on-device (encrypted at rest)
• Generate verification tokens locally
• Operate without network connectivity (degraded but functional)

Implementations MUST NOT:

• Transmit raw biometric data to any external service
• Require a centralized server for cascade evaluation
• Store profiles in cloud storage
• Depend on network connectivity for basic verification

Edge Verification For scenarios requiring cross-device verification (e.g., a terminal at an airport, a point-of-sale system), RVP supports edge verification: | | | | | | Edge verifies: | | | - Token signature | | | - Chain integrity | | | - Freshness (<10s) | | | | | | |-- verified claim --->| | | | ]]> The edge node NEVER receives raw biometric data. It receives only the Verification Token (confidence scores, method types, hashes) and the Verifiable Credential.

Network Independence RVP defines three operation modes:

ONLINE:

Full cascade, Flare backup available, token sync

OFFLINE:

Local cascade only, tokens stored for later sync

DEGRADED:

Partial cascade (some layers require network), reduced confidence thresholds accepted

The protocol MUST gracefully degrade: full confidence Offline: L1 + L2 + L6 -> reduced but functional Degraded: L1 + L6 -> minimal but non-zero confidence ]]>

Latency Requirements RVP verification overhead MUST NOT degrade user experience. Target latency budgets: The TIBET/UPIP reference implementation has demonstrated 0.3ms overhead on commodity hardware (Lenovo P520, Xeon W-2133, dual RTX 3060). This confirms that continuous verification is feasible without perceptible latency.

Transport Considerations

5G Integration Current 5G networks provide:

• Sub-1ms radio latency (theoretical)
• 1-10ms end-to-end latency (practical)
• 100 Mbps - 1 Gbps throughput

This is sufficient for RVP edge verification: a verification token (< 2KB) can be transmitted to an edge node and verified within the 50ms interactive budget. 5G network slicing can provide dedicated RVP verification channels with guaranteed latency for high-assurance scenarios (e.g., border control, financial transactions).

6G Preparedness Projected 6G specifications ():

• Sub-0.1ms latency
• 50-200 Gbps throughput
• Native AI/ML integration
• Sensing capabilities (environment-aware network)

6G enables RVP capabilities not feasible on 5G:

• Network-layer telemetry as a cascade layer (the network itself provides identity signals)
• Real-time biometric streaming for edge verification (with user consent) at zero perceptible latency
• Distributed cascade across device + network + edge in under 1ms total

RVP is designed to be 6G-ready by:

• Defining cascade layers as pluggable (new layers for network-native sensing)
• Using I-Poll transport that adapts to available bandwidth
• Supporting sub-millisecond token generation

Offline Operation RVP MUST operate fully offline. In offline mode:

• Only on-device cascade layers are available
• Tokens are stored locally with monotonic sequence numbers
• When connectivity resumes, stored tokens MAY be synced to a verification log (if configured)
• Confidence thresholds MAY be adjusted for offline mode (implementation-specific policy)

I-Poll Transport For AI-to-AI verification and Flare rescue, RVP uses I-Poll as its messaging transport. I-Poll provides:

• HTTP-based push/pull messaging
• Agent addressing via AINS (.aint domains)
• Message types: PUSH, PULL, SYNC, TASK, ACK
• Trust scoring per agent (FIR/A)

RVP verification tokens are transported as I-Poll messages with metadata type "rvp_verification":

Security Considerations

Evidence vs. Enforcement RVP follows the principle of EVIDENCE OVER ENFORCEMENT. The protocol produces cryptographic evidence of verification outcomes. It does NOT prescribe enforcement policy. An implementation MAY:

• Block actions when confidence is below threshold
• Allow actions with reduced privileges
• Require additional verification
• Log and alert without blocking

The choice of enforcement is a POLICY decision, not a PROTOCOL decision. RVP provides the evidence; the deployment context determines the response. This design is deliberate. Enforcement mechanisms can be bypassed (disable the check, spoof the result). Evidence cannot be un-recorded. An attacker who bypasses enforcement still produces anomalous evidence in the verification chain.

Biometric Data Protection RVP implementations MUST comply with biometric data protection requirements:

• Biometric templates MUST be stored only on-device
• Templates MUST be encrypted with device-bound keys
• Raw biometric data MUST be processed and immediately discarded (not stored, not transmitted)
• Verification Tokens MUST NOT contain biometric data (only method type, confidence score, template hash)
• Users MUST be able to delete all biometric data and profiles at any time

These requirements align with Article 9 (special categories of personal data), requirements for biometric identification systems, and data minimization principles.

Replay Attacks An attacker who captures a Verification Token cannot replay it because:

• Each token includes a millisecond-precision timestamp
• Each token references its predecessor (chain integrity)
• Each token includes a nonce derived from device state
• Verifiers SHOULD reject tokens older than a configurable freshness window (default: 10 seconds)

Adversarial Inputs Adversarial attacks on cascade layers:

• FACE SPOOFING: Mitigated by liveness detection (L2a). RVP RECOMMENDS 3D liveness detection (depth sensing) over 2D photo-based detection.
• FINGERPRINT SPOOFING: Mitigated by sensor quality assessment and capacitive/ultrasonic sensing.
• KEYSTROKE MIMICRY: Difficult at scale; requires matching dozens of timing parameters simultaneously. Statistical detection of "too perfect" matches.
• BEHAVIORAL MIMICRY: Requires sustained matching of action patterns, timing, and sequences. Impractical for extended sessions.

Multi-layer cascade is the primary defense: spoofing one layer is feasible; spoofing four or more simultaneously is exponentially harder.

Privacy by Design RVP incorporates privacy by design at every level:

• MINIMIZATION: Only confidence scores and method types leave the device, never raw data
• LOCAL PROCESSING: All biometric and behavioral analysis runs on-device
• SELECTIVE DISCLOSURE: User controls which verification evidence is shared with which verifier
• UNLINKABILITY: Verification Tokens use per-verifier pseudonymous identifiers to prevent cross-service tracking
• DELETION: Users can delete all profiles and tokens at any time with immediate effect

Telemetry Minimization Each cascade layer MUST implement the principle of minimal telemetry:

• Collect only what is needed for confidence computation
• Process immediately, retain only statistical aggregates
• Discard raw signals after processing
• Store only hashes in verification tokens

Implementations MUST provide a telemetry manifest listing every signal collected, its purpose, retention period, and deletion procedure.

Regulatory Alignment

EU AI Act The classifies real-time biometric identification as high-risk (Annex III, Category 1). RVP addresses AI Act requirements by:

• Providing full audit trails (Article 12 - Record-keeping)
• Enabling human oversight (Article 14 - via HALT mechanism)
• Ensuring transparency (Article 13 - cascade path recorded)
• Supporting risk management (Article 9 - confidence scoring)
• Operating locally (minimizing mass surveillance risk)

RVP is NOT a remote biometric identification system. It operates on-device for the device holder's own identity verification. This distinction is critical for AI Act classification.

eIDAS 2.0 / EUDIW The European Digital Identity Wallet regulation () requires:

• Level of Assurance High for cross-border identity
• Qualified Electronic Signatures
• Selective attribute disclosure
• Offline operation capability

RVP provides the verification evidence layer that supports LOA High through multi-factor cascade (biometric + document + device), with full audit trail and offline operation.

NIS2 Directive requires essential and important entities to implement risk management measures including access control and incident evidence. RVP provides:

• Continuous access verification (not session-based)
• Incident evidence through verification chain anomalies
• Tamper-evident audit trail

GDPR RVP is designed for compliance:

• Article 5(1)(c) - Data minimization: only hashes transmitted
• Article 9 - Biometric data: processed locally only
• Article 17 - Right to erasure: full deletion supported
• Article 25 - Data protection by design: privacy is architectural, not bolted on
• Article 35 - DPIA: cascade configuration enables proportionality assessment

DORA The Digital Operational Resilience Act () requires financial entities to maintain ICT risk management frameworks. RVP supports DORA by:

• Providing continuous verification of operator identity
• Producing audit evidence for ICT incident reporting
• Supporting operational resilience through offline capability
• Enabling third-party risk assessment through verification chain analysis

W3C Verified Credentials RVP is designed as a complementary protocol to W3C Verifiable Credentials . It does not replace VCs; it provides the EVIDENCE LAYER that VCs currently lack. A Verifiable Credential answers: "What is claimed?" RVP answers: "How was it verified, and is it still true?" Together, they provide a complete identity verification stack: claims + evidence + continuous proof.

IANA Considerations This document defines the following protocol identifiers:

Protocol prefix:

"rvp:" -- Identifies RVP verification tokens

Hash format:

"rvp:sha256:<hex>" -- SHA-256 hash of verification token

Token ID format:

"rvp-<hex12>" -- 12-character hexadecimal identifier

MIME type (registration requested):

"application/rvp+json" -- RVP verification token in JSON

I-Poll metadata type:

"rvp_verification" -- Identifies I-Poll messages carrying RVP verification tokens

References Normative References Informative References tibet-triage v0.5.0, https://pypi.org/project/tibet-triage/ brain-api brain-api W3C Recommendation European Parliament European Parliament European Parliament European Parliament European Parliament FIDO Alliance W3C Recommendation ITU-R

Verification Token JSON Schema

Cascade Configuration Schema

Use Case Examples

Age Verification at Point of Sale A 19-year-old purchases alcohol at a self-checkout terminal. phone runs RVP cascade: - L2a face: match to enrolled profile (0.45) - L3 device: enrolled device, local network (0.25) - L3 NFC: passport data confirms age >= 18 (0.25) - Accumulated: 0.95 -> GO 3. Phone transmits to terminal: - VC: "ageOver: 18" (signed by issuer) - RVP token: fresh, confidence 0.95, methods: face+device+NFC 4. Terminal verifies: - VC signature valid - RVP token fresh (<5 seconds) - Confidence above store policy (0.80) - Sale approved 5. Evidence: Verification Token stored on phone + terminal log ]]> At no point did the terminal receive: exact age, name, face image, fingerprint, or passport number. Only: "18+" claim + verification confidence.

Continuous Developer Authentication A developer works on a production system for 4 hours. GO Chain started 09:15 Normal development work RVP token #47: confidence 0.94 -> GO L1 keystroke stable, L6 airlock nominal 10:30 Developer leaves desk (no keystrokes for 5 min) RVP token #182: confidence 0.0 -> SOFT VERIFY System locks screen, requires face to resume 10:35 Developer returns, face match RVP token #183: confidence 0.91 -> GO Chain continues 11:45 Typing pattern changes (developer is tired) RVP token #294: confidence 0.78 -> SOFT VERIFY System requests fingerprint touch -> match -> GO 13:00 End of session Chain: 412 tokens, 4 hours, 2 soft verifies, 0 halts Audit trail: complete and tamper-evident ]]>

Child on Parent's Device Jasper's 7-year-old son Storm uses his laptop. deviation: 4.7 sigma - Error rate: 0.38 (profile: 0.04) -> deviation: 8.5 sigma - Confidence: -0.3 (active contradiction) L2a FACE: - Match to Jasper profile: fail - Liveness: detected (not a photo) - Match to known profile "Storm": success - Confidence: 0.0 for Jasper, flagged as "known_child" L3 DEVICE: - Device: Jasper's laptop (enrolled) -> partial match - Location: home -> matches - Confidence: 0.2 Resolution: HALT for Jasper's identity But: Profile recognition -> "Storm" identified Policy: Switch to Storm's permission set (sandbox, no deploy) Token records: "Identity: not Jasper. Recognized: Storm. Method: keystroke_deviation + face_recognition. Action: permission_downgrade to child_sandbox." ]]> No alarm. No block. Just: correct identification through evidence, appropriate permission adjustment, full audit trail.

VPN Anomaly Detection An attacker obtains Jasper's credentials and connects via VPN. deviation: 3.2 sigma - Perfect grammar (profile: shorthand, no caps) -> deviation - Confidence: -0.4 L2a FACE: - Camera: disabled/covered - Confidence: 0.0 (inconclusive) L2b FINGERPRINT: - Not available (remote connection) - Confidence: 0.0 (inconclusive) L3 DEVICE: - Device fingerprint: unknown device - Network: VPN, exit node Romania (profile: NL direct) - Confidence: -0.6 (active contradiction) L5 BEHAVIORAL: - Command sophistication: advanced admin (profile: developer) - Time: 03:00 (profile: 09:00-23:00) - Confidence: -0.3 Accumulated: -1.3 -> HALT (multiple contradictions) Token records every layer, every signal, every contradiction. No ambiguity. Evidence speaks for itself. ]]>

Comparison with Existing Standards RVP is NOT a replacement for these standards, including . It is a COMPLEMENTARY LAYER that provides continuous verification evidence on top of existing identity and authentication frameworks.

Acknowledgements The RVP protocol was developed as part of HumoticaOS, an AI governance framework built on human-AI symbiosis. The Predictive Airlock concept emerged from the tibet-triage project's work on process integrity and cascade verification. The design principles of evidence-over-enforcement and local-first architecture reflect the belief that identity verification should serve the individual, not surveil them.