Internet Engineering Task Force J. van de Meent Internet-Draft R. AI Intended status: Standards Track Humotica Expires: 19 September 2026 18 March 2026 RVP: Real-time Verification Protocol draft-vandemeent-rvp-continuous-verification-00 Abstract 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 [TIBET] for provenance tokens, UPIP [UPIP] for process integrity evidence, JIS [JIS] for identity semantics, and W3C Verifiable Credentials [VC-DATA-MODEL] for credential issuance and presentation. The protocol is designed for local-first, decentralized operation with zero dependency on centralized identity providers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." van de Meent & AI Expires 19 September 2026 [Page 1] Internet-Draft RVP March 2026 This Internet-Draft will expire on 19 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Continuous vs. Session-Based Verification . . . . . . . . 7 3.2. The Verification Moment . . . . . . . . . . . . . . . . . 8 3.3. Architecture Overview . . . . . . . . . . . . . . . . . . 8 4. Verification Cascade . . . . . . . . . . . . . . . . . . . . 9 4.1. Cascade Layers . . . . . . . . . . . . . . . . . . . . . 9 4.2. Layer Activation . . . . . . . . . . . . . . . . . . . . 10 4.3. Confidence Scoring . . . . . . . . . . . . . . . . . . . 10 4.4. Cascade Resolution . . . . . . . . . . . . . . . . . . . 11 4.5. Cascade Diagram . . . . . . . . . . . . . . . . . . . . . 11 5. Predictive Airlock . . . . . . . . . . . . . . . . . . . . . 13 5.1. Pre-Rendering Expected State . . . . . . . . . . . . . . 13 5.2. Delta Detection . . . . . . . . . . . . . . . . . . . . . 13 5.3. Deviation Classification . . . . . . . . . . . . . . . . 14 5.4. Airlock Resolution . . . . . . . . . . . . . . . . . . . 14 6. Telemetry Layers . . . . . . . . . . . . . . . . . . . . . . 14 6.1. L1 KEYSTROKE - Input Behavioral Biometrics . . . . . . . 14 6.2. L2 BIOMETRIC - Physical Identity Signals . . . . . . . . 15 6.3. L3 DEVICE - Hardware and Network Context . . . . . . . . 16 6.4. L4 VOCAL - Acoustic Telemetry . . . . . . . . . . . . . . 17 6.5. L5 BEHAVIORAL - Intent vs. Action Analysis . . . . . . . 18 6.6. L6 AIRLOCK - Predictive Delta Verification . . . . . . . 19 7. Verification Token . . . . . . . . . . . . . . . . . . . . . 19 7.1. Token Structure . . . . . . . . . . . . . . . . . . . . . 19 7.2. Token Lifecycle . . . . . . . . . . . . . . . . . . . . . 20 7.3. Token Chain . . . . . . . . . . . . . . . . . . . . . . . 21 van de Meent & AI Expires 19 September 2026 [Page 2] Internet-Draft RVP March 2026 7.4. TIBET Integration . . . . . . . . . . . . . . . . . . . . 21 8. Cascade Fallback Protocol . . . . . . . . . . . . . . . . . . 22 8.1. Fallback Triggers . . . . . . . . . . . . . . . . . . . . 22 8.2. Fallback Flow . . . . . . . . . . . . . . . . . . . . . . 22 8.3. Flare Integration . . . . . . . . . . . . . . . . . . . . 22 8.4. Hard Stop Conditions . . . . . . . . . . . . . . . . . . 23 9. Credential Binding . . . . . . . . . . . . . . . . . . . . . 23 9.1. W3C Verifiable Credentials Integration . . . . . . . . . 24 9.2. Credential Issuance from RVP Evidence . . . . . . . . . . 25 9.3. Credential Presentation with RVP Proof . . . . . . . . . 25 9.4. Age Verification Use Case . . . . . . . . . . . . . . . . 26 9.5. Digital Passport / Digital ID (eIDAS 2.0) . . . . . . . . 27 10. Local-First Architecture . . . . . . . . . . . . . . . . . . 27 10.1. On-Device Processing . . . . . . . . . . . . . . . . . . 27 10.2. Edge Verification . . . . . . . . . . . . . . . . . . . 28 10.3. Network Independence . . . . . . . . . . . . . . . . . . 28 10.4. Latency Requirements . . . . . . . . . . . . . . . . . . 29 11. Transport Considerations . . . . . . . . . . . . . . . . . . 29 11.1. 5G Integration . . . . . . . . . . . . . . . . . . . . . 29 11.2. 6G Preparedness . . . . . . . . . . . . . . . . . . . . 29 11.3. Offline Operation . . . . . . . . . . . . . . . . . . . 30 11.4. I-Poll Transport . . . . . . . . . . . . . . . . . . . . 30 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 12.1. Evidence vs. Enforcement . . . . . . . . . . . . . . . . 31 12.2. Biometric Data Protection . . . . . . . . . . . . . . . 31 12.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 32 12.4. Adversarial Inputs . . . . . . . . . . . . . . . . . . . 32 12.5. Privacy by Design . . . . . . . . . . . . . . . . . . . 33 12.6. Telemetry Minimization . . . . . . . . . . . . . . . . . 33 13. Regulatory Alignment . . . . . . . . . . . . . . . . . . . . 33 13.1. EU AI Act . . . . . . . . . . . . . . . . . . . . . . . 33 13.2. eIDAS 2.0 / EUDIW . . . . . . . . . . . . . . . . . . . 34 13.3. NIS2 Directive . . . . . . . . . . . . . . . . . . . . . 34 13.4. GDPR . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.5. DORA . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13.6. W3C Verified Credentials . . . . . . . . . . . . . . . . 35 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 15.1. Normative References . . . . . . . . . . . . . . . . . . 36 15.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Verification Token JSON Schema . . . . . . . . . . . 37 Appendix B. Cascade Configuration Schema . . . . . . . . . . . . 40 Appendix C. Use Case Examples . . . . . . . . . . . . . . . . . 42 C.1. Age Verification at Point of Sale . . . . . . . . . . . . 42 C.2. Continuous Developer Authentication . . . . . . . . . . . 42 C.3. Child on Parent's Device . . . . . . . . . . . . . . . . 43 C.4. VPN Anomaly Detection . . . . . . . . . . . . . . . . . . 44 Appendix D. Comparison with Existing Standards . . . . . . . . . 45 van de Meent & AI Expires 19 September 2026 [Page 3] Internet-Draft RVP March 2026 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 1. 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 ([EU-AI-ACT], [EIDAS2], [NIS2]) 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. 1.1. 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. van de Meent & AI Expires 19 September 2026 [Page 4] Internet-Draft RVP March 2026 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 1.2. 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. van de Meent & AI Expires 19 September 2026 [Page 5] Internet-Draft RVP March 2026 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. 2. 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 [RFC2119] [RFC8174]. 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 [UPIP]. 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. van de Meent & AI Expires 19 September 2026 [Page 6] Internet-Draft RVP March 2026 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. 3. Protocol Overview 3.1. Continuous vs. Session-Based Verification Traditional session-based verification: T=0 Login (password + MFA) -> 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: van de Meent & AI Expires 19 September 2026 [Page 7] Internet-Draft RVP March 2026 T=0.000 Action requested T=0.001 Airlock pre-renders expected outcome T=0.002 Cascade evaluates: keystroke + device + face T=0.003 Confidence: 0.94 -> 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. 3.2. 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. 3.3. Architecture Overview van de Meent & AI Expires 19 September 2026 [Page 8] Internet-Draft RVP March 2026 +------------------------------------------------------------+ | RVP VERIFICATION ENGINE | | | | +----------+ +--------------+ +------------------+ | | | Telemetry|-->| 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) | +------------------+ Figure 1: RVP Architecture 4. 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. 4.1. 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. van de Meent & AI Expires 19 September 2026 [Page 9] Internet-Draft RVP March 2026 Priority Layer Signal Type Latency Passive -------- ----------- ------------------ --------- ------- L1 KEYSTROKE Behavioral biomet. <1ms Yes L2 BIOMETRIC Physical identity 10-100ms Mixed L3 DEVICE Hardware/network <5ms Yes L4 VOCAL Acoustic telemetry 10-50ms Yes L5 BEHAVIORAL Intent analysis 5-50ms Yes L6 AIRLOCK Predictive delta 1-10ms Yes "Passive" indicates the layer can operate without explicit user action. Passive layers are preferred because they enable continuous verification without interrupting the user. 4.2. Layer Activation The cascade activates layers based on the Confidence Deficit: the difference between the required confidence threshold and the current accumulated confidence. Required confidence: 0.85 (configurable per action type) L1 KEYSTROKE: 0.40 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 4.3. 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) van de Meent & AI Expires 19 September 2026 [Page 10] Internet-Draft RVP March 2026 * -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: C_total = SUM (w_i * c_i) for i in activated layers where: w_i = weight of layer i (configurable, default: 1/N) c_i = confidence output of layer i Weights MUST sum to 1.0. Default weight distribution assigns equal weight to all activated layers. 4.4. 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). 4.5. Cascade Diagram van de Meent & AI Expires 19 September 2026 [Page 11] Internet-Draft RVP March 2026 Action requested | v +---------+ >= 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) Figure 2: Cascade Flow van de Meent & AI Expires 19 September 2026 [Page 12] Internet-Draft RVP March 2026 5. 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. 5.1. 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. T=0.000 Action: "git push origin main" T=0.001 Airlock pre-renders: - Expected: push succeeds, 3 files, branch main - User profile: does git push 4x/day avg - Sequence: preceded by "git add" and "git commit" - Timing: within work hours (09:00-23:00) T=0.002 Reality: matches prediction - Delta: 0.0 -> high confidence signal 5.2. Delta Detection The delta between prediction and reality is computed as: DELTA = distance(EXPECTED_STATE, ACTUAL_STATE) The distance function is domain-specific: * For commands: edit distance between expected and actual * For timing: standard deviations from profile mean van de Meent & AI Expires 19 September 2026 [Page 13] Internet-Draft RVP March 2026 * 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. 5.3. Deviation Classification Deviations are classified into four categories: Delta Range Classification Action ----------- -------------- ------------------------- 0.0 - 0.1 NOMINAL No effect on confidence 0.1 - 0.3 MINOR Slight confidence reduction 0.3 - 0.7 SIGNIFICANT Trigger deeper cascade layers 0.7 - 1.0 CRITICAL Trigger SOFT VERIFY or HALT 5.4. Airlock Resolution The airlock contributes to the cascade as L6 (AIRLOCK layer). Its confidence output is derived from the delta: c_airlock = 1.0 - 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. 6. 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). 6.1. L1 KEYSTROKE - Input Behavioral Biometrics Signals: * Typing speed (words per minute, rolling average) * Key press duration (per-key timing profile) van de Meent & AI Expires 19 September 2026 [Page 14] Internet-Draft RVP March 2026 * 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: Profile: typing_speed=80wpm, caps_frequency=0.02, error_rate=0.04, lang=nl Current: typing_speed=15wpm, caps_frequency=0.31, error_rate=0.38, lang=nl Distance: 4.7 standard deviations Confidence: -0.2 (active contradiction) Interpretation: Different person typing (e.g., child) 6.2. 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). van de Meent & AI Expires 19 September 2026 [Page 15] Internet-Draft RVP March 2026 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: Face -> 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 6.3. 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) van de Meent & AI Expires 19 September 2026 [Page 16] Internet-Draft RVP March 2026 * 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: Digital passport (2030) or digital ID card: 1. NFC tap -> 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 [EIDAS2] compliance, where the European Digital Identity Wallet (EUDIW) requires high-assurance identity verification for cross-border services. 6.4. L4 VOCAL - Acoustic Telemetry Signals: * Voice frequency profile (fundamental + harmonics) * Speech cadence and rhythm * Sub-verbal signals (throat sounds, acknowledgments) van de Meent & AI Expires 19 September 2026 [Page 17] Internet-Draft RVP March 2026 * 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. 6.5. 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?) van de Meent & AI Expires 19 September 2026 [Page 18] Internet-Draft RVP March 2026 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 6.6. L6 AIRLOCK - Predictive Delta Verification This layer uses the Predictive Airlock (Section 5) 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) 7. Verification Token Every verification moment produces exactly one Verification Token. The token is the atomic evidence unit of RVP. 7.1. Token Structure van de Meent & AI Expires 19 September 2026 [Page 19] Internet-Draft RVP March 2026 { "protocol": "RVP", "version": "1.0", "token_id": "rvp-a7b3c9d2e4f1", "timestamp": "2026-03-18T14:30:00.003Z", "subject": { "profile_hash": "sha256:4f2e8a...", "device_hash": "sha256:7c9d1b..." }, "cascade": { "layers_activated": ["L1", "L3", "L6"], "layers_skipped": ["L2", "L4", "L5"], "layer_results": { "L1": {"confidence": 0.42, "signal_category": "nominal"}, "L3": {"confidence": 0.31, "signal_category": "nominal"}, "L6": {"confidence": 0.18, "signal_category": "nominal"} }, "accumulated_confidence": 0.91, "threshold": 0.85, "resolution": "GO" }, "airlock": { "prediction_hash": "sha256:b3d1...", "delta": 0.02, "deviation_class": "nominal" }, "evidence": { "telemetry_hash": "sha256:9c1a...", "cascade_path": "L1->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..." } Figure 3: Verification Token Example 7.2. Token Lifecycle Verification Tokens are immutable once created. They follow a simple lifecycle: CREATED -> STORED -> (optionally) CHAINED -> ARCHIVED van de Meent & AI Expires 19 September 2026 [Page 20] Internet-Draft RVP March 2026 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. 7.3. Token Chain Consecutive Verification Tokens form a chain. Each token references its predecessor: { "token_id": "rvp-b8c4d0e3f2a5", "previous_token": "rvp-a7b3c9d2e4f1", "chain_length": 47, "chain_confidence_trend": "stable" } 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 7.4. TIBET Integration Every Verification Token includes TIBET provenance fields [TIBET]: * 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. van de Meent & AI Expires 19 September 2026 [Page 21] Internet-Draft RVP March 2026 8. Cascade Fallback Protocol When a cascade layer fails (hardware unavailable, inconclusive result, or active contradiction), RVP defines a structured fallback protocol. 8.1. 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) 8.2. Fallback Flow Primary method fails | v Is there a next cascade layer? | | yes no | | v v Activate next All layers exhausted cascade layer C_total > 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). 8.3. Flare Integration When a verification cascade cannot complete locally (all local methods exhausted, device degraded), RVP MAY use the Flare Rescue Protocol [FLARE] to request verification assistance from a nearby trusted node. van de Meent & AI Expires 19 September 2026 [Page 22] Internet-Draft RVP March 2026 Local cascade exhausted (confidence = 0.4, threshold = 0.85) | v Flare SOS -> 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. 8.4. 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). 9. Credential Binding RVP provides the evidence layer beneath W3C Verifiable Credentials [VC-DATA-MODEL]. 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. van de Meent & AI Expires 19 September 2026 [Page 23] Internet-Draft RVP March 2026 9.1. 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: { "@context": ["https://www.w3.org/2018/credentials/v1"], "type": ["VerifiableCredential", "AgeVerification"], "issuer": "did:web:example.com", "credentialSubject": { "ageOver": 18 }, "proof": { }, "rvpEvidence": { "protocol": "RVP", "verification_chain": [ "rvp:sha256:4f2e8a...", "rvp:sha256:7c9d1b...", "rvp:sha256:b3d1e2..." ], "chain_length": 3, "chain_confidence_min": 0.87, "chain_confidence_max": 0.94, "methods_used": ["L2a_face", "L3_device_nfc", "L6_airlock"], "last_verified": "2026-03-18T14:30:00Z", "continuous": true } } van de Meent & AI Expires 19 September 2026 [Page 24] Internet-Draft RVP March 2026 9.2. Credential Issuance from RVP Evidence A credential issuer can use an RVP evidence chain as the basis for issuing a Verifiable Credential: User RVP Engine Issuer | | | |-- request 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) | 9.3. 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: van de Meent & AI Expires 19 September 2026 [Page 25] Internet-Draft RVP March 2026 Holder RVP Engine Verifier | | | |-- present credential --->| | | | | | 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. 9.4. Age Verification Use Case A common W3C VC use case is age verification. RVP enables continuous age verification without revealing exact age: Step 1: Initial verification (one-time) - NFC tap on passport/ID -> 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 van de Meent & AI Expires 19 September 2026 [Page 26] Internet-Draft RVP March 2026 9.5. Digital Passport / Digital ID (eIDAS 2.0) The European Digital Identity Wallet (EUDIW), mandated by [EIDAS2] 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 [RFC8259], 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 10. Local-First Architecture 10.1. 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 van de Meent & AI Expires 19 September 2026 [Page 27] Internet-Draft RVP March 2026 * Require a centralized server for cascade evaluation * Store profiles in cloud storage * Depend on network connectivity for basic verification 10.2. Edge Verification For scenarios requiring cross-device verification (e.g., a terminal at an airport, a point-of-sale system), RVP supports edge verification: User device Edge node Service | | | |-- RVP token + VC ------>| | | | | | 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. 10.3. 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: Online: L1 + L2 + L3 + L4 + L5 + L6 -> full confidence Offline: L1 + L2 + L6 -> reduced but functional Degraded: L1 + L6 -> minimal but non-zero confidence van de Meent & AI Expires 19 September 2026 [Page 28] Internet-Draft RVP March 2026 10.4. Latency Requirements RVP verification overhead MUST NOT degrade user experience. Target latency budgets: Context Budget Measured (reference) ------------------------ ---------- -------------------- Interactive CLI/UI < 50ms 0.3ms (TIBET/UPIP) API call augmentation < 10ms 0.3ms (TIBET/UPIP) Background continuous < 200ms N/A (passive) NFC document read < 500ms ~300ms (typical) Biometric capture < 1000ms ~200ms (typical) 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. 11. Transport Considerations 11.1. 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). 11.2. 6G Preparedness Projected 6G specifications ([ITU-IMT2030]): * Sub-0.1ms latency * 50-200 Gbps throughput * Native AI/ML integration van de Meent & AI Expires 19 September 2026 [Page 29] Internet-Draft RVP March 2026 * 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 11.3. 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) 11.4. I-Poll Transport For AI-to-AI verification and Flare rescue, RVP uses I-Poll [IPOLL] as its messaging transport. I-Poll provides: * HTTP-based push/pull messaging * Agent addressing via AINS (.aint domains) [AINS] * Message types: PUSH, PULL, SYNC, TASK, ACK * Trust scoring per agent (FIR/A) van de Meent & AI Expires 19 September 2026 [Page 30] Internet-Draft RVP March 2026 RVP verification tokens are transported as I-Poll messages with metadata type "rvp_verification": { "from_agent": "user_device.aint", "to_agent": "service_edge.aint", "poll_type": "PUSH", "content": "RVP verification token", "metadata": { "rvp_verification": true, "token_hash": "rvp:sha256:...", "chain_length": 47 } } 12. Security Considerations 12.1. 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. 12.2. Biometric Data Protection RVP implementations MUST comply with biometric data protection requirements: * Biometric templates MUST be stored only on-device van de Meent & AI Expires 19 September 2026 [Page 31] Internet-Draft RVP March 2026 * 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 [GDPR] Article 9 (special categories of personal data), [EU-AI-ACT] requirements for biometric identification systems, and [EIDAS2] data minimization principles. 12.3. 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) 12.4. 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. van de Meent & AI Expires 19 September 2026 [Page 32] Internet-Draft RVP March 2026 Multi-layer cascade is the primary defense: spoofing one layer is feasible; spoofing four or more simultaneously is exponentially harder. 12.5. 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 12.6. 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. 13. Regulatory Alignment 13.1. EU AI Act The [EU-AI-ACT] 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) van de Meent & AI Expires 19 September 2026 [Page 33] Internet-Draft RVP March 2026 * 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. 13.2. eIDAS 2.0 / EUDIW The European Digital Identity Wallet regulation ([EIDAS2]) 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. 13.3. NIS2 Directive [NIS2] 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 13.4. GDPR RVP is designed for [GDPR] compliance: * Article 5(1)(c) - Data minimization: only hashes transmitted * Article 9 - Biometric data: processed locally only van de Meent & AI Expires 19 September 2026 [Page 34] Internet-Draft RVP March 2026 * 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 13.5. DORA The Digital Operational Resilience Act ([DORA]) 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 13.6. W3C Verified Credentials RVP is designed as a complementary protocol to W3C Verifiable Credentials [VC-DATA-MODEL]. 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. 14. IANA Considerations This document defines the following protocol identifiers: Protocol prefix: "rvp:" -- Identifies RVP verification tokens Hash format: "rvp:sha256:" -- SHA-256 hash of verification token Token ID format: "rvp-" -- 12-character hexadecimal identifier MIME type (registration requested): "application/rvp+json" -- RVP van de Meent & AI Expires 19 September 2026 [Page 35] Internet-Draft RVP March 2026 verification token in JSON I-Poll metadata type: "rvp_verification" -- Identifies I-Poll messages carrying RVP verification tokens 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . 15.2. Informative References [TIBET] van de Meent, J. and R. AI, "TIBET: Transaction/ Interaction-Based Evidence Trail", Work in Progress, Internet-Draft, draft-vandemeent-tibet-provenance-00, January 2026, . [UPIP] van de Meent, J. and R. AI, "UPIP: Universal Process Integrity Protocol with Fork Tokens for Multi-Actor Continuation", Work in Progress, Internet-Draft, draft- vandemeent-upip-process-integrity-00, March 2026, . [JIS] van de Meent, J. and R. AI, "JIS: JTel Identity Standard", Work in Progress, Internet-Draft, draft-vandemeent-jis- identity-00, January 2026, . [FLARE] van de Meent, J. and R. AI, "Flare Rescue Protocol for API Failover", tibet-triage v0.5.0, https://pypi.org/project/tibet-triage/, March 2026. [IPOLL] van de Meent, J. and R. AI, "I-Poll: AI-to-AI Messaging Protocol", brain-api, 2025. van de Meent & AI Expires 19 September 2026 [Page 36] Internet-Draft RVP March 2026 [AINS] van de Meent, J. and R. AI, "AINS: AInternet Name Service", brain-api, 2025. [VC-DATA-MODEL] Sporny, M., Noble, G., Longley, D., Burnett, D., Zundel, B., and K. Den Hartog, "Verifiable Credentials Data Model v2.0", W3C Recommendation, March 2024. [EIDAS2] European Parliament, "Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework", April 2024. [EU-AI-ACT] European Parliament, "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", June 2024. [NIS2] European Parliament, "Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union", December 2022. [GDPR] European Parliament, "Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation)", Regulation (EU) 2016/679, April 2016. [DORA] European Parliament, "Regulation (EU) 2022/2554 on digital operational resilience for the financial sector", December 2022. [FIDO2] FIDO Alliance, "FIDO2: Web Authentication (WebAuthn)", W3C Recommendation, 2019. [ITU-IMT2030] ITU-R, "Framework and overall objectives of the future development of IMT for 2030 and beyond", Recommendation ITU-R M.2160, November 2023. Appendix A. Verification Token JSON Schema { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "RVP Verification Token", "type": "object", "required": [ "protocol", "version", "token_id", "timestamp", "subject", "cascade", "evidence", "token_hash" ], van de Meent & AI Expires 19 September 2026 [Page 37] Internet-Draft RVP March 2026 "properties": { "protocol": { "type": "string", "const": "RVP" }, "version": { "type": "string", "pattern": "^[0-9]+\\.[0-9]+$" }, "token_id": { "type": "string", "pattern": "^rvp-[a-f0-9]{12}$" }, "timestamp": { "type": "string", "format": "date-time" }, "subject": { "type": "object", "required": ["profile_hash", "device_hash"], "properties": { "profile_hash": { "type": "string", "pattern": "^sha256:[a-f0-9]{8,64}$" }, "device_hash": { "type": "string", "pattern": "^sha256:[a-f0-9]{8,64}$" } } }, "cascade": { "type": "object", "required": [ "layers_activated", "layer_results", "accumulated_confidence", "threshold", "resolution" ], "properties": { "layers_activated": { "type": "array", "items": { "type": "string", "enum": ["L1", "L2", "L2a", "L2b", "L2c", "L3", "L4", "L5", "L6"] } }, "layers_skipped": { "type": "array", van de Meent & AI Expires 19 September 2026 [Page 38] Internet-Draft RVP March 2026 "items": {"type": "string"} }, "layer_results": { "type": "object", "additionalProperties": { "type": "object", "required": ["confidence", "signal_category"], "properties": { "confidence": { "type": "number", "minimum": -1.0, "maximum": 1.0 }, "signal_category": { "type": "string", "enum": ["nominal", "minor", "significant", "critical", "contradiction"] } } } }, "accumulated_confidence": { "type": "number", "minimum": -1.0, "maximum": 1.0 }, "threshold": { "type": "number", "minimum": 0.0, "maximum": 1.0 }, "resolution": { "type": "string", "enum": ["GO", "SOFT_VERIFY", "HALT"] } } }, "airlock": { "type": "object", "properties": { "prediction_hash": {"type": "string"}, "delta": {"type": "number", "minimum": 0.0}, "deviation_class": { "type": "string", "enum": ["nominal", "minor", "significant", "critical"] } } }, van de Meent & AI Expires 19 September 2026 [Page 39] Internet-Draft RVP March 2026 "evidence": { "type": "object", "required": ["telemetry_hash", "cascade_path", "time_elapsed_ms"], "properties": { "telemetry_hash": {"type": "string"}, "cascade_path": {"type": "string"}, "time_elapsed_ms": {"type": "integer", "minimum": 0} } }, "previous_token": { "type": "string", "pattern": "^rvp-[a-f0-9]{12}$" }, "chain_length": { "type": "integer", "minimum": 1 }, "tibet": { "type": "object", "properties": { "erin": {"type": "string"}, "eraan": {"type": "array", "items": {"type": "string"}}, "eromheen": {"type": "object"}, "erachter": {"type": "string"} } }, "token_hash": { "type": "string", "pattern": "^rvp:sha256:[a-f0-9]{8,64}$" } } } Appendix B. Cascade Configuration Schema { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "RVP Cascade Configuration", "type": "object", "properties": { "threshold": { "description": "Minimum confidence for GO resolution", "type": "number", "default": 0.85, "minimum": 0.0, "maximum": 1.0 }, van de Meent & AI Expires 19 September 2026 [Page 40] Internet-Draft RVP March 2026 "minimum_confidence": { "description": "Below this, HALT regardless of layers", "type": "number", "default": 0.0 }, "halt_on_contradiction": { "description": "Confidence value that triggers hard stop", "type": "number", "default": -0.5 }, "layers": { "type": "array", "items": { "type": "object", "required": ["id", "type", "weight"], "properties": { "id": {"type": "string"}, "type": { "type": "string", "enum": ["keystroke", "biometric_face", "biometric_finger", "biometric_iris", "device", "vocal", "behavioral", "airlock"] }, "weight": {"type": "number", "minimum": 0.0}, "enabled": {"type": "boolean", "default": true}, "timeout_ms": {"type": "integer", "default": 100}, "config": {"type": "object"} } } }, "freshness_window_seconds": { "description": "Max age of token for verifier acceptance", "type": "integer", "default": 10 }, "offline_threshold_reduction": { "description": "Reduce threshold by this in offline mode", "type": "number", "default": 0.15 } } } van de Meent & AI Expires 19 September 2026 [Page 41] Internet-Draft RVP March 2026 Appendix C. Use Case Examples C.1. Age Verification at Point of Sale A 19-year-old purchases alcohol at a self-checkout terminal. 1. Terminal requests age verification 2. User taps phone (NFC) -> 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. C.2. Continuous Developer Authentication A developer works on a production system for 4 hours. van de Meent & AI Expires 19 September 2026 [Page 42] Internet-Draft RVP March 2026 09:00 Login via hardware key + face RVP token #1: confidence 0.97 -> 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 C.3. Child on Parent's Device Jasper's 7-year-old son Storm uses his laptop. van de Meent & AI Expires 19 September 2026 [Page 43] Internet-Draft RVP March 2026 Storm starts typing: "hallloooow storrm hier" RVP cascade: L1 KEYSTROKE: - Speed: 15 wpm (profile: 80 wpm) -> 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. C.4. VPN Anomaly Detection An attacker obtains Jasper's credentials and connects via VPN. van de Meent & AI Expires 19 September 2026 [Page 44] Internet-Draft RVP March 2026 RVP cascade: L1 KEYSTROKE: - Speed: 120 wpm (profile: 80 wpm) -> 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. Appendix D. Comparison with Existing Standards Feature RVP FIDO2 OAuth2 eIDAS SAML -------------------- ------- ------- ------- ------ ------ Continuous verify Yes No No No No Behavioral biom. Yes No No No No Predictive airlock Yes No No No No Local-first Yes Yes No Mixed No Evidence production Yes No No Audit No Cascade fallback Yes No No No No Offline capable Yes Yes No Yes No VC integration Yes Partial No Yes No AI agent support Yes No Yes No No Zero-knowledge age Yes No No Yes No Session-free Yes No No No No TIBET provenance Yes No No No No Open protocol Yes Yes Yes Yes Yes van de Meent & AI Expires 19 September 2026 [Page 45] Internet-Draft RVP March 2026 RVP is NOT a replacement for these standards, including [FIDO2]. 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. Authors' Addresses Jasper van de Meent Humotica Den Dolder Netherlands Email: jasper@humotica.com URI: https://humotica.com Root AI Humotica Email: root_ai@humotica.nl URI: https://humotica.com van de Meent & AI Expires 19 September 2026 [Page 46]