Кратко

  • В редакции 03 RVP обязательная пятиступенчатая проверка с накоплением общего балла заменена доказательством, относящимся к одному зафиксированному вопросу.
  • Токены старого формата можно хранить как исторические записи, но нельзя считать подпись одного транспортного вызова подтверждением операции и цели, которых в ней не было.

Получателю удобно видеть зелёный результат проверки. Однако без сохранённого вопроса он не знает, какой именно факт проверен. Подпись устройства под случайным вызовом может быть подлинной, но не означает, что человек видел запрос на изменение прав в конкретной системе. Обновлённый 29 сентября проект RVP переносит акцент с универсального рейтинга уверенности на границы конкретного вопроса.

В редакции 02 каждая операция рассматривалась как момент проверки. Пять слоёв — от поведенческих признаков до контекста устройства — могли последовательно накапливать оценку до порога. Решение о блокировке или допуске и тогда оставалось за местными правилами; это не новшество редакции 03. Новым стало исключение обязательной каскадной модели и перенос выбора момента проверки к политике потребителя. Действующий сеанс, недавнее присутствие человека, состояние устройства, право на восстановление и допуск теперь различаются как отдельные факты.

Требование к доказательству получает идентификатор, неизменяемую версию и хеш канонического содержимого. Сам запрос фиксирует действие, цель, проверяемое лицо, другого исполнителя при необходимости, потребителя, назначение, окно, вызов и срок. Обязательство по вопросу охватывает всё это вместе. Переносчик может доставить запрос и получить ответ, но его собственный вызов не заменяет смысл показанного вопроса. Проверяющая сторона пересчитывает обязательство по своему экземпляру запроса.

Приложение о миграции не требует стирать старые данные. Они могут оставаться свидетельством прежних проверок. Но если новая политика требует связи с действием и целью, токен первой версии не подходит. Запрещено брать отсутствующие поля из текущего состояния системы и объявлять, будто их когда-то подписал отвечавший. Также нельзя незаметно понизить проверку с полного обязательства второй версии до старого ответа, связанного только с вызовом.

Дальнейшая судьба подходящего ответа тоже разделена. Итог match говорит лишь о соответствии доказательства замороженному условию. Когда названный потребитель действительно применяет его к назначению и текущему переходу состояния цели, он отдельно фиксирует bind. При этом вновь проверяются срок и актуальность цели, а конкурентное использование не должно обходить ограничения. Повторное применение несколькими потребителями возможно только тогда, когда их имена, цели и пределы заранее содержатся в требовании. Решение о допуске принимает целевая система.

Daniel Kade предлагает при смене формата вести краткую ведомость: версия токена, реально подписанные поля, хеш требования, действие и цель, потребитель, факт использования и лицо, ответственное за финальный допуск. Это редакционная рекомендация, а не утверждённая форма протокола. Она мешает заменить вопрос «что было подписано?» более удобным «насколько высоким был старый балл?».

Datatracker относит редакцию 03 к действующим индивидуальным Internet-Draft, без назначенного потока RFC. Упомянутый в тексте запрос на регистрацию application/rvp+json не означает завершённой регистрации. Источники не доказывают внедрения или реальной атаки. Установленный факт — авторы существенно сузили значение, которое может нести результат проверки.

Источники