RVP: Real-time Verification Protocol for Requirement-Bound Evidence
draft-vandemeent-rvp-continuous-verification-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jasper van de Meent , Root AI | ||
| Last updated | 2026-09-29 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Humotica - Protocol authors
Reference implementation: tibet-triage Python package tibet-core on PyPI tibet-triage 0.5.0 on PyPI |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vandemeent-rvp-continuous-verification-03
Internet Engineering Task Force J. van de Meent
Internet-Draft R. AI
Intended status: Informational Humotica
Expires: 2 April 2027 29 September 2026
RVP: Real-time Verification Protocol for Requirement-Bound Evidence
draft-vandemeent-rvp-continuous-verification-03
Abstract
This document defines RVP, a protocol for asking a bounded
verification question, carrying that question through one of several
possible verification mechanisms, and producing evidence that is
bound to the exact question. RVP separates five concerns that are
often collapsed: the consumer policy that decides whether evidence is
needed, the frozen evidence requirement, the lifecycle of the
question, the carrier that obtains a response, and the later act of
consuming the evidence.
RVP does not grant authority, establish admission, or replace account
authentication and session policy. A successful result means only
that the presented evidence satisfied the referenced requirement for
the referenced question. The consumer and target system remain
responsible for deciding what, if anything, may happen next.
The protocol supports local biometric checks, signed companion-device
responses, WebAuthn, authenticated-session evidence, recovery
standing, and future carriers without assigning ceremony semantics or
authority to those carriers. It is transport-independent and can
operate locally without a central identity provider.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 April 2027.
van de Meent & AI Expires 2 April 2027 [Page 1]
Internet-Draft RVP 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 6
3.1. Ownership Boundaries . . . . . . . . . . . . . . . . . . 6
3.2. Independent State Axes . . . . . . . . . . . . . . . . . 7
3.3. One Window, One Question . . . . . . . . . . . . . . . . 8
4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Evidence Requirement . . . . . . . . . . . . . . . . . . 8
4.2. Verification Request . . . . . . . . . . . . . . . . . . 9
4.3. Evidence Response . . . . . . . . . . . . . . . . . . . . 10
4.4. Consumption Binding . . . . . . . . . . . . . . . . . . . 11
4.5. Canonicalization and Digests . . . . . . . . . . . . . . 12
5. Question Commitment . . . . . . . . . . . . . . . . . . . . . 12
6. Verification Lifecycle . . . . . . . . . . . . . . . . . . . 13
6.1. Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Request . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Response and Terminal Outcomes . . . . . . . . . . . . . 14
6.4. Bind . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.5. Blocking and Non-Blocking Offers . . . . . . . . . . . . 15
7. Time and Freshness Model . . . . . . . . . . . . . . . . . . 15
8. Evidence Classes and Methods . . . . . . . . . . . . . . . . 16
8.1. Fresh Human Presence . . . . . . . . . . . . . . . . . . 16
8.2. Authenticated Session . . . . . . . . . . . . . . . . . . 16
8.3. Recovery Standing . . . . . . . . . . . . . . . . . . . . 16
8.4. Local Scores . . . . . . . . . . . . . . . . . . . . . . 16
9. Carrier Requirements . . . . . . . . . . . . . . . . . . . . 17
10. Provenance and Causal Records . . . . . . . . . . . . . . . . 17
11. Interoperability Requirements . . . . . . . . . . . . . . . . 18
12. Local-First Operation . . . . . . . . . . . . . . . . . . . . 19
van de Meent & AI Expires 2 April 2027 [Page 2]
Internet-Draft RVP September 2026
13. Transport Considerations . . . . . . . . . . . . . . . . . . 19
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
15. Security Considerations . . . . . . . . . . . . . . . . . . . 20
15.1. Evidence Laundering and Class Confusion . . . . . . . . 20
15.2. Question Substitution . . . . . . . . . . . . . . . . . 20
15.3. Replay and Late Responses . . . . . . . . . . . . . . . 20
15.4. Response-Bind Confusion . . . . . . . . . . . . . . . . 20
15.5. Carrier Liveness . . . . . . . . . . . . . . . . . . . . 21
15.6. Key Continuity . . . . . . . . . . . . . . . . . . . . . 21
15.7. Provenance Is Not Authority . . . . . . . . . . . . . . 21
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
17.1. Normative References . . . . . . . . . . . . . . . . . . 22
17.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Migration from RVP Version 1 . . . . . . . . . . . . 23
Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
Security systems frequently use one word, such as "verification" or
"presence", for several different facts. An account may be
authenticated, a session may still be valid, a human may be freshly
present, a device may be enrolled, and a recovery key may permit
repair. These facts can all be useful, but they are not
interchangeable.
RVP represents verification as a question with a bounded lifecycle.
A consumer freezes the evidence requirement, opens a request, and
selects or offers one or more carriers. A carrier obtains a
response. RVP verifies whether that response satisfies the frozen
requirement. A consumer binds the result only when it actually uses
the evidence. Policy and admission remain outside RVP.
This separation permits both high-friction and low-friction policies.
One deployment can accept an OAuth-authenticated session with MFA for
a workday, require fresh human presence after a pause, and require a
stronger device-bound method for a sensitive transition. Another
deployment can require fresh evidence for every transition. RVP
carries the evidence for either policy; it does not choose between
them.
1.1. Problem Statement
Existing verification integrations commonly fail in one or more of
the following ways:
van de Meent & AI Expires 2 April 2027 [Page 3]
Internet-Draft RVP September 2026
* A session is treated as proof of fresh human presence.
* A recovery credential is treated as if it were a fresh biometric
measurement.
* A transport challenge is treated as the question itself.
* A response is recorded as consumed before any consumer uses it.
* A reference or record address is treated as authority.
* A local confidence score is interpreted as a portable policy
decision.
* Carrier-specific failures silently become ceremony outcomes.
* A valid signature is accepted for a different operation, target,
actor, requirement, or deadline than the one shown to the signer.
1.2. Design Principles
Evidence is not authority: RVP describes what was measured. It does
not grant, admit, or authorize.
The requirement is frozen: The exact requirement, including its
version and digest, is bound before a response is accepted.
The lane owns the question: The verification lane owns the request
lifecycle and terminal vocabulary. A carrier only carries the
question and response.
Response is not consumption: A matching response can remain
unconsumed. The consumer records a separate bind when it uses
that evidence.
Different state axes stay different: Authentication, session
standing, presence, device state, recovery standing, and admission
MUST NOT be inferred from one another unless an explicit consumer
policy says how they compose.
Local-first operation: A deployment can verify evidence locally and
offline. Central identity providers and network services MAY
supply evidence, but are not required by the protocol.
1.3. Scope
This document defines:
van de Meent & AI Expires 2 April 2027 [Page 4]
Internet-Draft RVP September 2026
* A requirement-bound verification lifecycle.
* The boundary between a lane and its carriers.
* Canonical request, response, and consumption records.
* Terminal outcomes and fail-closed handling.
* Question commitment, freshness, and replay requirements.
* How RVP evidence relates to sessions, recovery, policy, and
provenance.
This document does not define:
* Account enrolment or account authentication protocols.
* Biometric matching algorithms or portable confidence formulas.
* Authorization, admission, role assignment, or grants.
* A required transport or user-interface flow.
* A universal duration for a carrier wait, challenge, evidence
freshness period, session, or standing.
2. Conventions and 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] when, and only when, they appear in all
capitals, as shown here.
Consumer The component that decides whether evidence is required and
later decides whether to consume a result. A consumer is not
necessarily the target of the requested operation.
Evidence Requirement An immutable, versioned description of the
evidence needed for one purpose. It is referenced by identifier,
version, and digest.
Verification Lane The scoped lifecycle that owns one verification
question and its terminal outcome.
Carrier A mechanism that presents a question and obtains a response,
van de Meent & AI Expires 2 April 2027 [Page 5]
Internet-Draft RVP September 2026
such as a local fingerprint reader, WebAuthn, or a signed
companion-device exchange. A carrier does not own policy,
authority, or the lane lifecycle.
Window A bounded carrier opportunity associated with exactly one
request. A window reference is an address, not a permission.
Challenge A one-time value used to prevent replay within a carrier
exchange. A challenge is not the whole question.
Question Commitment A digest over the canonical security-relevant
fields of the exact question shown to the responder.
Evidence Response A signed or otherwise verifiable response to a
request. A response is not yet consumed and does not grant
authority.
Bound Evidence A successful response that a named consumer has
actually consumed for a named purpose and binding reference.
Session Standing A policy fact established by an authentication
system, such as an OAuth, OpenID Connect, SSH, or local login
session. Session standing is not fresh human-presence evidence.
Recovery Standing A fact that permits a recovery or repair
procedure. Recovery standing is not fresh human-presence evidence
and does not itself restore ordinary admission.
Admission A target-local decision about whether an actor or request
may proceed. Admission is outside RVP.
3. Protocol Architecture
3.1. Ownership Boundaries
van de Meent & AI Expires 2 April 2027 [Page 6]
Internet-Draft RVP September 2026
consumer policy
| decides WHETHER evidence is required
v
frozen evidence requirement
| states WHAT evidence satisfies this purpose
v
verification lane
| owns request, lifetime, and terminal outcome
v
carrier
| presents the exact question and returns evidence
v
RVP evaluator
| verifies the response against the frozen requirement
v
consumer bind
| records actual consumption
v
target policy / admission
decides what may happen next
An implementation MAY combine these components in one process, but it
MUST preserve their semantic boundaries. In particular, a carrier
success MUST NOT directly produce admission, and a lane MUST NOT
infer a terminal outcome from an unmapped carrier-specific result.
3.2. Independent State Axes
The following facts are independent and MUST be represented
separately:
* Account authentication and session standing.
* Fresh human-presence evidence.
* Device enrolment and device-binding state.
* Substrate or hardware attestation.
* Recovery standing.
* Authorization or admission.
* Causal continuation and provenance.
van de Meent & AI Expires 2 April 2027 [Page 7]
Internet-Draft RVP September 2026
A policy MAY require any conjunction or disjunction of these facts.
For example, a policy can require a valid workday session and fresh
presence after a pause. The policy MUST state that composition; RVP
MUST NOT infer it from method strength or a scalar score.
3.3. One Window, One Question
A carrier window MUST carry exactly one request. Attaching the same
window to a second request, including a request in another lane, MUST
fail. A responder and verifier MUST reject a response if the window
or challenge resolves to zero or more than one request.
Multiple carriers MAY be offered for one request. Their responses
still terminate the same lane, and a terminal lane MUST reject later
responses as stale.
4. Data Model
RVP records are JSON objects as defined by [RFC8259]. Deployments
MAY use another serialization if it preserves every field and defines
an equivalent canonical representation. The examples in this section
omit deployment-specific signatures and provenance fields for
readability. The kind identifiers and assurance labels in these
examples are illustrative; an interoperable profile MUST define the
meaning of any assurance labels it uses. Draft revision -03 and
record version 2 identify different version spaces.
4.1. Evidence Requirement
An evidence requirement is immutable after publication. A reference
MUST contain all of:
* evidence_requirement_id: a stable local or globally scoped
identifier;
* evidence_requirement_version: an immutable revision;
* evidence_requirement_digest: a digest of the canonical requirement
bytes.
A requirement body SHOULD state its purpose, evidence class, accepted
method or assurance constraints, freshness rule, and an explicit
statement that satisfying the requirement grants nothing.
van de Meent & AI Expires 2 April 2027 [Page 8]
Internet-Draft RVP September 2026
{
"kind": "org.example.rvp.evidence-requirement.v1",
"evidence_requirement_id": "admin_ctx_entry_presence",
"evidence_requirement_version": 1,
"purpose": "admin.enter",
"evidence_class": "fresh_human_presence",
"accepted_assurance": ["H1", "H2"],
"freshness": {"type": "inside_request_window"},
"grants": "nothing"
}
Figure 1: Example Evidence Requirement
A bare identifier that can silently resolve to a newer version MUST
NOT be used in a request. A digest mismatch makes the requirement
unresolved and the request unanswerable.
4.2. Verification Request
A request MUST contain:
* A protocol and request format version.
* A unique request_id and scoped lane_ref.
* The frozen window_ref and challenge_ref.
* The operation and target.
* The subject whose evidence is requested.
* The actor or role, when distinct from the subject.
* The consumer and purpose.
* The complete evidence-requirement reference.
* The creation time and request deadline.
* A question-commitment version and digest.
van de Meent & AI Expires 2 April 2027 [Page 9]
Internet-Draft RVP September 2026
{
"protocol": "RVP",
"version": 2,
"kind": "org.example.rvp.request.v2",
"request_id": "pr-8a41b7c2",
"lane_ref": "presence:admin-entry:17",
"window_ref": "win-f04ac811",
"challenge_ref": "cid-ef86b3d0",
"op": "admin.enter",
"target": "box:raint-a46acdf5",
"subject": "jasper.aint",
"actor": "jasper-admin.aint",
"on_behalf_of": "jasper.aint",
"consumer": "iab-admin",
"purpose": "admin.enter",
"evidence_requirement": {
"evidence_requirement_id": "admin_ctx_entry_presence",
"evidence_requirement_version": 1,
"evidence_requirement_digest": "sha256:..."
},
"created_at": "2026-09-25T10:00:00Z",
"deadline": "2026-09-25T10:00:45Z",
"question_commitment": {
"version": 2,
"algorithm": "sha-256",
"digest": "sha256:..."
}
}
Figure 2: Example Verification Request
The on_behalf_of field, when present, names the principal on whose
behalf the actor operates. It MUST NOT be used in the reverse
direction. Absent optional identity fields MUST be represented as
explicit null values in the question commitment.
4.3. Evidence Response
A successful response MUST identify the request, lane, window,
challenge, evidence method and class, subject or presenter, issue
time, expiry or freshness boundary, requirement digest, and question
commitment. It MUST contain or reference cryptographic evidence that
covers these fields.
van de Meent & AI Expires 2 April 2027 [Page 10]
Internet-Draft RVP September 2026
{
"protocol": "RVP",
"version": 2,
"kind": "org.example.rvp.evidence-response.v2",
"response_id": "re-19d1e4c7",
"request_id": "pr-8a41b7c2",
"lane_ref": "presence:admin-entry:17",
"window_ref": "win-f04ac811",
"challenge_ref": "cid-ef86b3d0",
"subject": "jasper.aint",
"presenter": "device:phone-7",
"evidence_class": "fresh_human_presence",
"method": "passkey-smartphone",
"assurance": "H2",
"issued_at": "2026-09-25T10:00:12Z",
"expires_at": "2026-09-25T10:00:45Z",
"evidence_requirement_digest": "sha256:...",
"question_commitment": {
"version": 2,
"digest": "sha256:..."
},
"signature": {
"key_ref": "jis:phone-7.aint#ed25519",
"suite": "ed25519",
"value": "base64url:..."
},
"grants": "nothing"
}
Figure 3: Example Evidence Response
A local biometric carrier MAY use a locally attested result instead
of a portable signature, but it MUST bind the result to the same
request and question commitment. A claim that a biometric check
occurred is not equivalent to a measured biometric result.
4.4. Consumption Binding
A matching response does not mean that any consumer used it. When a
consumer uses a successful response, it MUST write or return a
separate binding containing:
* The request and response references.
* The consumer and purpose.
* The exact target object, transition, or artifact digest to which
the evidence was applied.
van de Meent & AI Expires 2 April 2027 [Page 11]
Internet-Draft RVP September 2026
* The bind time.
* A statement that the binding itself grants nothing.
A response MUST NOT be bound more than once unless the requirement
explicitly permits multiple named consumers. Such a requirement MUST
list those consumers and each consumption MUST produce its own
binding. The permitted purposes and target scopes for each consumer
MUST also be frozen in the requirement; consumers MUST NOT add a new
purpose after the response. Consumption MUST be serialized or
otherwise made atomic so concurrent consumers cannot bypass these
limits.
Before binding, the consumer MUST check that the evidence remains
usable under the frozen freshness rule and that the referenced target
transition is still current. Expiry, revocation, or replacement of
the target state MUST NOT be hidden by a historical match. A profile
MUST define how these checks are coordinated with consumption and how
a retry identifies an existing binding without consuming again.
4.5. Canonicalization and Digests
JSON-based profiles of RVP SHOULD use the JSON Canonicalization
Scheme [RFC8785] before hashing or signing. A profile that uses
another canonicalization MUST identify it in the signed data. Digest
and signature algorithm identifiers MUST be explicit.
5. Question Commitment
A transport challenge proves freshness only for that challenge. It
does not prove what operation or target was shown to the responder.
RVP therefore requires a question commitment for every signed
response.
Question commitment version 2 covers at least:
* A domain separator identifying RVP and the commitment version.
* request_id, lane_ref, window_ref, and challenge_ref.
* op, target, subject, actor, and on_behalf_of, including explicit
null values.
* The consumer and purpose.
* The evidence-requirement identifier, version, and digest.
* The request creation time and deadline.
van de Meent & AI Expires 2 April 2027 [Page 12]
Internet-Draft RVP September 2026
The window and challenge references MUST be allocated before the
commitment is frozen. Multiple carriers offered for that request
MUST bind to this same question; carrier-specific challenges, if any,
MUST be verifiably bound to it by the carrier profile. A profile
MUST define the exact commitment object, its canonical bytes, domain
separator, and digest construction. The commitment digest itself and
response signature are not inputs to that commitment.
For human approval, the responder MUST derive both the commitment and
an unambiguous rendering from the same frozen question fields. An
automated evidence carrier MUST bind to those same fields without
claiming that human approval occurred. The verifier MUST recompute
it from its own request record. A mismatch MUST terminate the lane
without binding.
A verifier that requires question commitment version 2 MUST NOT
silently accept a version 1 response that signs only a challenge.
Version negotiation MUST happen before the question is presented, and
a downgrade MUST be visible to the consumer.
6. Verification Lifecycle
6.1. Arm
An implementation MAY arm a scoped lane before a request arrives.
Arming states that a verification path is prepared; it does not state
that a human is present, that a request has been made, or that a
carrier is reachable.
The canonical lifecycle event name for this phase is presence.arm
when the evidence class is human presence. Other evidence classes
SHOULD use an equally scoped event name rather than overloading
presence.
6.2. Request
The consumer creates a request after freezing the requirement and
question commitment. The request enters the proposed state. The
canonical human-presence event name is presence.request.
Creating or persisting a request does not prove that any carrier is
serving it. A system that tells a human that a question is
answerable SHOULD measure that at least one selected carrier is
serving the same window and request.
van de Meent & AI Expires 2 April 2027 [Page 13]
Internet-Draft RVP September 2026
6.3. Response and Terminal Outcomes
A lane reaches exactly one of the following terminal outcomes:
match Evidence was received and satisfies the frozen requirement.
This outcome is eligible for later consumption; it is not yet a
bind.
no_match_in_this_lane Evidence was measured but did not match the
subject or constraint for this lane.
refused The responder explicitly declined the question.
timed_out No terminal carrier response arrived before the request or
carrier window closed.
unreachable The selected carrier could not present the question or
return a response.
superseded A newer request explicitly replaced this request.
stale While the lane was pending, a response was evaluated as
outside the relevant freshness boundary. A response arriving
after an existing terminal outcome is rejected as stale without
changing that outcome.
cancelled The request was explicitly withdrawn. A profile MUST
distinguish this from a policy choice not to require evidence.
Carrier-specific outcomes MUST be mapped explicitly into this set.
An unknown carrier or unmapped carrier outcome MUST fail closed.
Only match is eligible for binding. The canonical human-presence
response event is presence.response, and it records the typed
terminal outcome.
A lane terminal outcome is immutable. Implementations MUST arbitrate
competing responses and deadline events so only one terminal outcome
is committed. Rejected late responses MAY be recorded separately but
MUST NOT replace an earlier match, refusal, or other terminal result.
6.4. Bind
A consumer binds a matched response only when it actually applies the
evidence to its named purpose. The canonical human-presence event is
presence.bind. A lane closure with any other outcome MUST NOT emit a
bind.
van de Meent & AI Expires 2 April 2027 [Page 14]
Internet-Draft RVP September 2026
A bind does not imply admission. For example, fresh human presence
can satisfy the evidence requirement for entering a read context.
Access to protected information still requires the applicable read
authorization; the evidence does not create that authorization.
6.5. Blocking and Non-Blocking Offers
Interactive and headless operation MAY share one request and one
carrier window. An interactive caller can wait for the terminal
result; a headless caller can return while the same request remains
pending. These are caller behaviors, not different ceremonies.
A persisted window is not proof that its carrier service survived a
process or system restart. An implementation that resumes a
persisted request MUST re-establish and measure the carrier for the
same window, or report the carrier as unreachable. It MUST NOT
create a second question merely to restart transport.
7. Time and Freshness Model
RVP separates the following time domains:
* Carrier wait: how long an implementation waits for a reader,
network peer, or user interaction.
* Request window: how long this question remains answerable.
* Challenge validity: how long a one-time challenge is accepted.
* Evidence freshness: how long a successful result can satisfy a
requirement.
* Session lifetime: how long an authentication system keeps session
standing.
* Standing lifetime: how long a previously established non-session
fact remains usable under policy.
These durations answer different questions and MUST NOT be derived
from one another without an explicit profile rule. RVP defines no
universal default duration. A process timeout such as the time spent
waiting for a fingerprint reader is not, by itself, an evidence-
freshness policy.
Implementations SHOULD use a monotonic clock for local waiting and an
authenticated or causally ordered record for protocol events. Wall-
clock timestamps are useful for interchange but MUST NOT be the only
replay defense.
van de Meent & AI Expires 2 April 2027 [Page 15]
Internet-Draft RVP September 2026
8. Evidence Classes and Methods
Evidence class describes what a result means. Method describes how
the result was obtained. Assurance and anchoring describe additional
properties. These fields MUST remain separate.
8.1. Fresh Human Presence
Fresh human-presence evidence states that a qualifying measurement
associated a human with this request inside the required window.
Local fingerprint matching, a hardware-backed authenticator with user
verification, and a signed companion-device approval can be methods
for this class when the frozen requirement accepts their measured
properties. A device signature alone MUST NOT be treated as evidence
that a human acted during the request window.
Being root, holding a process position, setting an environment
variable, or possessing an unsigned record is not a human-presence
method.
8.2. Authenticated Session
An authenticated session can be evidence that an account completed a
login ceremony and remains inside a policy-defined session. OAuth,
MFA, SSH, and local login systems can establish such standing. This
evidence MAY satisfy requirements designed for session standing. It
MUST NOT be relabelled as fresh human presence.
8.3. Recovery Standing
A recovery key or recovery procedure can establish the right to
address an unresolved binding or restore state. It does not prove
fresh presence and does not necessarily grant ordinary operation. A
consumer MAY require recovery standing together with fresh presence
or session evidence.
8.4. Local Scores
An implementation MAY use numeric scores to select or evaluate local
methods. Such scores are method- and deployment-specific metadata.
They MUST NOT be added across unrelated evidence classes, interpreted
as portable admission decisions, or compared between deployments
unless a profile defines the complete calibration and semantics.
A requirement SHOULD prefer explicit accepted methods, assurance
classes, anchoring properties, and freshness rules over an
unqualified scalar threshold.
van de Meent & AI Expires 2 April 2027 [Page 16]
Internet-Draft RVP September 2026
9. Carrier Requirements
A carrier MUST:
* Identify the request and window it serves.
* Preserve the security-relevant question fields and, when human
approval is requested, present an unambiguous human-readable
rendering derived from them.
* Bind its response to the complete question commitment.
* Return a carrier-specific result that has an explicit lane
mapping.
* Reject expired, already-consumed, unknown, or mismatched
challenges.
A carrier MUST NOT:
* Choose the evidence requirement or admission policy.
* Treat possession of a request reference as authority.
* Report a request as answerable merely because a persisted window
record exists.
* Create a second request when resuming service for an existing
request.
* Convert an unknown carrier result into a successful lane outcome.
10. Provenance and Causal Records
RVP lifecycle events can be recorded in a provenance system such as
TIBET [TIBET]. A typical sequence is:
presence.arm
presence.request
presence.response outcome=match|refused|timed_out|...
presence.bind only after successful consumer consumption
The provenance writer can serialize, hash-chain, sign, and durably
append these records. That mechanical inscription does not decide
the evidence result or grant authority. A chain hash proves record
integrity and ordering; it is not a substitute for the responder's
signature or the target's admission decision.
van de Meent & AI Expires 2 April 2027 [Page 17]
Internet-Draft RVP September 2026
Missing history MUST NOT be rewritten as a successful history. A
deployment that imports a pending request created before lifecycle
recording existed can describe its opening as unrecorded and still
record an honest later closure.
11. Interoperability Requirements
Two implementations conform to this document for a profile only if
they agree on:
* The record versions and canonicalization.
* The evidence-requirement reference and digest.
* The question-commitment version and covered fields.
* The carrier result to lane-outcome mapping.
* The signature or local-attestation verification method.
* The relevant freshness and replay boundaries.
* Consumption atomicity, retry behavior, and target-state binding.
A conformance suite SHOULD include at least the following hostile
cases:
* One window attached to two questions.
* A response delivered to another lane or consumer.
* An expired or replayed challenge.
* A changed operation, target, subject, actor, requirement, or
deadline with an otherwise valid signature.
* A changed server-side request record.
* A response after a terminal outcome, without changing that
outcome.
* Concurrent responses or consumption attempts.
* A matched response consumed after its freshness boundary or after
the referenced target state was replaced.
* A second consumer or purpose absent from the frozen requirement.
van de Meent & AI Expires 2 April 2027 [Page 18]
Internet-Draft RVP September 2026
* An unknown carrier and an unmapped carrier outcome.
* A match recorded as bound before consumption.
* A session token presented for a fresh-presence requirement.
* A recovery credential presented as ordinary admission.
Test reporting MUST distinguish a verified measurement harness from
protocol conformance. A harness can operate correctly while exposing
a contract gap; this is not full conformance.
12. Local-First Operation
RVP does not require a central verifier. Requirements, request
records, enrolled device keys, local biometric results, and consumer
bindings can all remain under the target operator's control.
Offline operation does not mean weakening an unresolved requirement.
If the required carrier or validation material is unavailable, the
lane terminates as unreachable or remains pending according to
policy. It MUST NOT silently become a match.
Raw biometric data SHOULD be processed on the measuring device and
SHOULD NOT appear in an RVP response. The response should contain
the minimum method, assurance, anchoring, and result data needed to
verify the requirement.
13. Transport Considerations
RVP is transport-independent. Records can be carried over local IPC,
HTTP, QR-mediated companion-device exchanges, message queues,
removable media, or other transports. The transport MUST preserve
the bytes covered by question commitments and signatures.
Transport reachability is not evidence. TLS authenticates and
protects a channel, but it does not by itself satisfy an RVP evidence
requirement. Likewise, an HTTP success response does not imply that
the lane bound the result.
14. Privacy Considerations
Continuous collection can become continuous surveillance. RVP does
not require continuous telemetry. A deployment SHOULD request
evidence only at policy-defined transitions and SHOULD disclose the
purpose before the responder acts.
van de Meent & AI Expires 2 April 2027 [Page 19]
Internet-Draft RVP September 2026
Implementations MUST minimize evidence records. Raw fingerprints,
facial images, voice recordings, keystrokes, and behavioral traces
MUST NOT be included merely to make a response independently
auditable. Local verifiers should instead attest the result and
retain only what the requirement and incident policy need.
Stable subject, device, lane, and key identifiers enable correlation.
Profiles SHOULD support scoped or pairwise identifiers where global
linkage is unnecessary. Retention periods for requests, failed
outcomes, and bindings SHOULD be independently configurable.
15. Security Considerations
15.1. Evidence Laundering and Class Confusion
A strong method does not make every evidence class true. A passkey
can establish a signed device response and user verification, but it
does not prove a local fingerprint was measured. A recovery key can
permit repair, but it does not become fresh presence. Verifiers MUST
compare the evidence class and requirement, not only an assurance
label.
15.2. Question Substitution
If a responder signs only a challenge, a compromised or buggy server
can show one operation and apply the signature to another. The
complete question commitment in Section 5 is REQUIRED to prevent this
attack.
15.3. Replay and Late Responses
Challenges MUST be one-time, windows MUST carry one question, and a
terminal lane MUST reject later responses. Expiry is necessary but
not sufficient: replay protection also requires durable consumption
or closure state.
15.4. Response-Bind Confusion
Binding at response time creates authority leakage: evidence can be
recorded as used even when the consumer rejected or never observed
it. Implementations MUST keep match and bind as separate state
transitions.
van de Meent & AI Expires 2 April 2027 [Page 20]
Internet-Draft RVP September 2026
15.5. Carrier Liveness
A persisted carrier window can outlive the process serving it.
Implementations SHOULD probe the service against the same request or
otherwise prove that it serves that exact window. Starting a process
and recording its process identifier is not sufficient proof that it
successfully bound a socket or can verify the request.
15.6. Key Continuity
Key rotation SHOULD preserve a relationship only when a verifiable
continuity link connects the old and new keys, as described by JIS
[JIS]. A new key without such a link is a new or forked identity,
not a silent rotation. Even a valid rotation can trigger a policy
requirement for fresh evidence; RVP carries that evidence but does
not mandate the policy.
15.7. Provenance Is Not Authority
A hash chain, causal tick, signed receipt, or durable append can
prove what was recorded and in what order. None of these facts alone
decides who may act. Implementations MUST verify responder evidence
and target policy separately from provenance integrity.
16. IANA Considerations
This document requests registration of the application/rvp+json media
type in the Standards Tree using the procedure in [RFC6838]. This is
a registration request; publication of this Internet-Draft does not
itself register the media type.
Type name: application
Subtype name: rvp+json
Required parameters: none
Optional parameters: none
Encoding considerations: binary; the representation is a JSON object
encoded as UTF-8
Security considerations: See Section 15.
Interoperability considerations: See Section 11 and Section 4.5.
Published specification: This document.
van de Meent & AI Expires 2 April 2027 [Page 21]
Internet-Draft RVP September 2026
Applications that use this media type: Verification consumers, local
presence services, companion-device carriers, and provenance
systems.
Fragment identifier considerations: none
Additional information: Magic number(s): none; File extension(s):
.rvp.json; Macintosh file type code(s): none
Person and email address to contact for further information: Jasper
van de Meent, jasper@humotica.com
Intended usage: COMMON
Restrictions on usage: none
Author: Jasper van de Meent
Change controller: IETF
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
17.2. Informative References
van de Meent & AI Expires 2 April 2027 [Page 22]
Internet-Draft RVP September 2026
[TIBET] van de Meent, J. and R. AI, "TIBET: Transaction/
Interaction-Based Evidence Trail", Work in Progress,
Internet-Draft, draft-vandemeent-tibet-provenance-02, June
2026, <https://datatracker.ietf.org/doc/html/draft-
vandemeent-tibet-provenance-02>.
[JIS] van de Meent, J. and R. AI, "JIS: JTel Identity Standard",
Work in Progress, Internet-Draft, draft-vandemeent-jis-
identity-02, June 2026,
<https://datatracker.ietf.org/doc/html/draft-vandemeent-
jis-identity-02>.
Appendix A. Migration from RVP Version 1
RVP version 1 tokens can contain a method, scalar confidence,
threshold, resolution, and transport challenge without committing to
the complete question. Such a token MUST NOT be accepted where a
version 2 requirement demands operation and target binding.
A deployment can retain version 1 records as historical evidence. It
SHOULD label them as not carrying question commitment version 2. A
version 2 verifier MUST NOT manufacture missing fields from its local
state and then claim that the signer approved them.
Appendix B. Changes from -02
1. Replaced the mandatory five-layer cascade and portable
confidence sum with a requirement-bound evidence model.
2. Removed the claim that every interaction is a verification
moment and that trusted sessions do not exist. Session standing
and fresh evidence are now separate composable facts.
3. Separated consumer policy, frozen requirements, lane lifecycle,
carriers, evidence evaluation, consumption, and admission.
4. Defined the arm, request, response, and bind lifecycle,
including eight typed terminal outcomes.
5. Specified that only a matching response can later bind, and that
a response is not consumption.
6. Added question commitment version 2 covering operation, target,
subject, actor, requirement, window, challenge, and deadline.
7. Added explicit handling for login sessions, fresh human
presence, recovery standing, device state, attestation, and
admission as independent axes.
van de Meent & AI Expires 2 April 2027 [Page 23]
Internet-Draft RVP September 2026
8. Separated carrier wait, request window, challenge validity,
evidence freshness, session lifetime, and standing lifetime.
9. Recast numeric confidence as optional local method metadata
rather than an interoperable policy or admission decision.
10. Added hostile interoperability cases and separate harness and
conformance verdicts.
11. Expanded privacy guidance to avoid continuous telemetry and
cross-context correlation.
12. Updated the media-type registration and companion-draft
references.
Acknowledgements
The authors thank Codex (codex.aint) for the implementation
crosswalk, hostile protocol analysis, and architecture rewrite that
informed this revision. The separation between policy, requirements,
lanes, carriers, evidence, and binding was refined through
implementation and testing in AInternet-in-a-box.
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 2 April 2027 [Page 24]