Summary

  • RVP revision 03 replaces the previous mandatory five-layer verification cascade and accumulated confidence score with evidence tied to one frozen question.
  • Its migration rule forbids treating an older challenge-only token as if it signed the operation and target required by the new question commitment.

A score travels easily. That is precisely the problem when two systems mean different things by “verified.” An operator might read a high confidence number as proof that a person approved a sensitive transition, although the underlying response only answered a device challenge. On 29 September, the authors of the individual RVP Internet-Draft rewrote the proposal so that a result is about a specified question rather than a portable level of trust.

The difference from revision 02 is unusually large. That version described continuous verification at every interaction, an ordered five-layer cascade and a token recording accumulated confidence against a threshold. It already left enforcement to local policy; revision 03 does not invent the distinction between evidence and enforcement. Instead it removes the mandatory cascade and portable confidence sum, accepts that a login session can have standing, and lets a consumer decide when fresh evidence is needed. A workday session and a fresh human-presence check can coexist, but policy must say how they compose.

The new evidence requirement cannot silently change after the question is asked. Section 4.1 requires an identifier, immutable version and digest of its canonical bytes. A request then names the operation, target, subject, actor if different, consumer, purpose, window, challenge and deadline. The question commitment covers those fields, including the requirement identity and digest. A carrier such as a passkey or companion device returns evidence for that exact question; its own challenge is not a substitute for the question. The verifier recomputes the commitment from its request record.

This has a pointed migration consequence. Appendix A allows first-generation RVP tokens to remain as historical evidence, but they may contain only a method, confidence, threshold, result and transport challenge. Where a version 2 requirement demands operation and target binding, the old token must not be accepted. A verifier cannot fill in absent fields from its own database and then claim that the original signer saw and approved them. The new text also rejects a silent downgrade from the full version 2 commitment to a version 1 challenge-only response.

Even a fully matching response is not an access decision. Revision 03 gives the verification lane one terminal outcome; match only means that the evidence satisfied the frozen requirement. The consumer records a separate bind when it actually uses that match for a named purpose and current target transition. Reuse by several consumers is possible only if the frozen requirement listed them and their purposes in advance; consumption must be atomic, with freshness and target state checked at the point of use. Admission remains the target system's decision. This is a state transition discipline, not evidence of a deployed security feature.

For a system migrating from the older model, Daniel Kade would keep a short transition register: token version, signed fields, requirement digest, operation and target, named consumer, actual bind record and the separate admission decision. That is an editorial control proposal, not a form specified by RVP. It prevents an attractive but false audit statement: “the old score was good, so the new action was authorized.”

Datatracker lists revision 03 as an active individual Internet-Draft with no RFC stream. The text is work in progress, and the draft's request to register an application/rvp+json media type is not itself a registration. There is no evidence here of adoption, interoperability or an actual exploit. The verifiable news is the document's change of unit: from a cumulative confidence claim to an answer that remains attached to the exact question asked.

Sources