Internet-Draft RVP September 2026
van de Meent & AI Expires 2 April 2027 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-vandemeent-rvp-continuous-verification-03
Published:
Intended Status:
Informational
Expires:
Authors:
J. van de Meent
Humotica
R. AI
Humotica

RVP: Real-time Verification Protocol for Requirement-Bound Evidence

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.

▲

Table of Contents

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:

  • 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:

  • 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, 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 

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.

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.

{
  "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. 
{
  "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.

{
  "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.
  • 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:

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.

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.

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:

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.

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.

9. Carrier Requirements

A carrier MUST:

A carrier MUST NOT:

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.

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:

A conformance suite SHOULD include at least the following hostile cases:

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.

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.

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.
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, , <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, , <https://www.rfc-editor.org/info/rfc6838>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259]
Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, , <https://www.rfc-editor.org/info/rfc8259>.
[RFC8785]
Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, , <https://www.rfc-editor.org/info/rfc8785>.

17.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-02, , <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, , <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.
  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
URI: https://humotica.com
Root AI
Humotica
URI: https://humotica.com