Кратко

  • В редакции 20 проекта RATS появилось приложение с примером получения подтверждений и эталонных значений. Постоянный URL запроса работает как неявный указатель и ключ кеша.
  • Подпись поставщика связывает набор данных с байтами запроса и временем истечения. Проверяющий сопоставляет его со свежим свидетельством устройства по собственной политике оценки.

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

Устройство выдаёт Evidence о своём состоянии; проверяющему нужен признак, позволяющий судить о свежести этой записи. Подтверждающие материалы и эталонные значения могут использоваться многократно, пока поставщик не заменит их. Архитектура RATS разделяет роли устройства, поставщика, проверяющего и стороны, принимающей решение на основе результата. Частота запросов у этих участников различается.

Документ, обновлённый 28 октября, остаётся рабочим проектом группы RATS с намерением выпустить предлагаемый стандарт. Новое приложение B описывает пример взаимодействия. Если добавлять в каждый запрос уникальный идентификатор, два одинаковых вопроса станут для кеша разными. Поставщику придётся обрабатывать каждый повторный запрос, а проверяющему — ждать ответа от исходного сервера даже тогда, когда справочные данные не менялись.

Отдельный проект CoSERV исключает из запроса временные метки и другие изменчивые поля. Одинаковые идентификаторы среды и выбор утверждений дают одинаковую кодированную последовательность байтов и URL. Этот URL становится ключом HTTP-кеша. Кеш отвечает на повторный запрос, пока результат остаётся в пределах срока, установленного поставщиком.

Новое приложение называет GET-адрес неявным указателем. attEnvIDs и claimSelection образуют запрос по среде; в примере URL обозначает начало эпохи. Поставщик формирует подписанный набор подтверждающих материалов и эталонных значений. Подпись связывает этот набор с байтами запроса и временем истечения. Дата закрывает период использования именно этого ответа. Для задания границы предполагается надёжный источник времени; одним из примеров названа Epoch Bell. Проверяющий может сопоставить подписанный запрос с тем, который отправил, а затем проверить срок результата.

В CoSERV каждому набору результатов задан срок; после него потребитель обязан прекратить считать набор действительным. Срок свежести, заявленный HTTP-кешем, не может быть длиннее. Если ответ проходит через посредника, которому проверяющий не доверяет, подпись позволяет заметить подмену: она связывает полученные данные с исходным запросом. Если исходный эталон прошивки изменился, а кеш всё ещё выдаёт истёкший ответ как актуальный, проверяющий сравнит устройство с устаревшей целью. Запрос Cache-Control: no-cache позволит получить текущий ответ от источника.

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

Источники: RATS -20; RATS -19; Datatracker; CoSERV -07; Epoch Markers -06; RFC 9334.