Кратко

  • Редакция 01 индивидуального Internet-Draft уточняет: детерминированное представление обнаруживает расхождение между подписанным действием и заявленным экраном, но не доказывает, что показал человеку недоверенный дисплей.
  • Проверка квитанции авторизации и проверка доказательства представления должны оставаться разными результатами. Ни один успешный результат сам по себе не разрешает действие.
  • Daniel Kade предлагает запись решения о представлении, связывающую технические проверки с регистрацией ключа, полномочием человека, корнями доверия, остаточным риском и локальной политикой. Это редакционное предложение, а не требование черновика.

В новой версии стало меньше обещаний и больше точности

Ключевое изменение видно в сравнении редакций 00 и 01. Из текста убрана мысль, будто проверяющая сторона способна доказать, что именно было показано человеку. В редакции 01 доказуемо лишь соответствие заявленного представления байтам подписанного действия.

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

Второе уточнение касается субъекта. Первая версия говорила об идентифицированном человеке, новая — о зарегистрированном ключе, создавшем подтверждённую пользователем подпись. Криптография видит ключ. Личность его владельца, актуальность трудовых отношений, предел поручения и право на конкретное действие устанавливаются отдельными источниками.

Datatracker фиксирует обновление 12 сентября 2026 года как активный индивидуальный Internet-Draft. У документа нет рабочей группы, потока IETF, ответственного Area Director и записанного целевого статуса RFC. Публикация не является принятием, консенсусом или одобрением IETF.

Повторяемое представление закрывает только один разрыв

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

Так можно обнаружить подмену суммы, адресата или правила между подписанным объектом и заявленным экраном. Биди-управление, управляющие символы, визуально похожие последовательности и чрезмерная длина должны обрабатываться детерминированно. Если безопасный вывод невозможен, визуализатор обязан отказаться, а не молча обрезать значение.

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

Новый раздел 6.1 поэтому требует независимо оценивать квитанцию и доказательство представления, используя отдельно выбранные входы доверия. Действительная квитанция не должна автоматически становиться принятым представлением. Действительное доказательство экрана не должно автоматически становиться авторизацией.

Аппаратная защита не отменяет описание доверия

Черновик называет Android Protected Confirmation примером возможного отдельного профиля, но сам его не определяет. Официальная документация ConfirmationPrompt описывает проверку аттестованного открытого ключа, ожидаемого корня, свежего nonce и точного текста подтверждения. Там же сказано, что нужны специальные аппаратные возможности и функция доступна не всегда.

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

Публичная эталонная реализация, о которой сообщает черновик, также имеет ограниченную доказательную силу. Негативные тесты могут показать, что конкретный код отклоняет несоответствие или опасную строку. Они не подтверждают независимый аудит, распространённость, целостность устройства или полномочие человека. В редакции 01 нет запросов к IANA; регистрация идентификаторов оставлена на будущее.

Зафиксировать, кто превратил доказательство в последствие

Daniel Kade предлагает запись решения о представлении, которую ведёт организация, полагающаяся на результат. В неё входят хеш действия, профиль и результат квитанции; профиль и версия визуализатора, язык, существенные поля и хеш представления; результат дисплейной аттестации; клиент, цепочка, корень доверия и класс экранного тракта; основание связи ключа с человеком; его роль, пределы и срок полномочия; остаточный риск; независимая политика авторизации, решение и обоснование; проверяющий, время, истечение, отказ или запасной путь и условия повторной оценки.

Это не универсальный пропуск. Необратимый перевод может требовать защищённого экрана и второго канала. Обратимое изменение сети может допускать детерминированный вывод и проверку двумя специалистами. Общим остаётся минимальный проверяемый пакет; порог и последствия принадлежат локальной власти.

Minimum Initial Specification Heng Lu поддерживает такое разделение: узкая общая поверхность без централизации будущих решений. The Policy Mirror требует сохранять точный масштаб утверждения каждого субъекта. Why BTW Media Exists задаёт границу новости: индивидуальный черновик существенно уточнил свои притязания; стандартизация, внедрение и доказанная безопасность не установлены.

Источники

  1. Карточка Datatracker
  2. История документа
  3. API Datatracker
  4. Редакция 01
  5. Редакция 00
  6. Официальное сравнение
  7. Authorization Receipts
  8. Authorization Receipts, редакция 13
  9. RFC 8785
  10. Android ConfirmationPrompt
  11. Android Protected Confirmation
  12. Android Key Attestation
  13. The Policy Mirror
  14. Minimum Initial Specification
  15. Why BTW Media Exists