Кратко

  • Проект рабочей группы ACE от 2 ноября разрешает серверу авторизации передавать токен серверу ресурсов за клиента и сообщать результат. Документ остается Internet-Draft.
  • Новый раздел 10.1 предполагает журналы с отметками времени для запросов, доставки и жизненного цикла токенов. Сервер ресурсов ведет свои записи в пределах доступных памяти, вычислений и энергии.
  • Операционные секреты записывать запрещено. При передаче журналов внешним управляющим системам выделенная точка хранения должна по рекомендации скрывать адреса и идентификаторы, позволяющие следить за устройствами; для специально уполномоченных получателей есть исключение.

Курьеру достается и квитанция

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

При такой доставке сервер авторизации видит больше событий. Редакция -09, опубликованная 2 ноября, добавила отсутствовавший в -08 раздел об эксплуатации. Он предполагает отметки времени для запроса и выпуска токена, результата отправки, истечения срока, отзыва и регистрации клиентов и серверов ресурсов. Сервер ресурсов по возможности отмечает прием, отказ, хранение, удаление токена и неудачные обращения к защищенному ресурсу. Его память и питание могут ограничивать подробность. Для оператора разница существенна: выдать токен еще не значит доставить его.

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

Срок хранения и детализацию определяют приложение и оператор.

Запрет на секреты записан как MUST NOT, сокрытие метаданных перед внешней передачей — как SHOULD. Документ не дает статистики внедрений или случаев слежки. Он ставит перед владельцем системы прямой вопрос: кому нужен результат отправки, а кому позволено видеть узнаваемую историю устройства?

Первоисточники