Кратко

  • В RFC 9796 verified=true означает, что сторона, добавившая конкретное поле Call-Info, успешно проверила представленную в нём информацию. Получателю всё равно нужна аутентифицированная доверительная связь с этой стороной.
  • Метка относится к своему полю. Она не подтверждает автоматически все сведения о вызывающем, заявленную причину, законность разговора или итог.
  • integrity может связать полученные байты с объявленным хешем. Происхождение, свежесть, доступность, показ, внимание человека и легитимность требуют отдельных свидетельств.

Самая опасная потеря в цепочке доверия происходит не тогда, когда проверка не выполнена, а тогда, когда выполненная проверка превращается в безымянный результат. На экране остаётся «проверено», а проверяющий, объект проверки и политика исчезают. RFC 9796 даёт возможность избежать этой потери.

Стандарт описывает Rich Call Data в SIP Call-Info и вводит параметры call-reason, verified, integrity, а также назначение jcard. Значение verified=true утверждает, что сторона, включившая это поле, успешно проверила информацию, которую поле представляет. Получатель может положиться на это лишь в пределах доверительных отношений со стороной, от которой пришёл запрос.

Это не печать под всей сессией. Это аттестация определённого объекта определённым участником.

На границе UNI меняется непосредственный источник доказательства

RFC 9795 защищает Rich Call Data и дайджесты ресурсов в PASSporT. Сам PASSporT задан в RFC 8225 и использует семейство подписанных токенов, связанное с RFC 7519. RFC 8224 помещает механизм идентичности STIR в SIP.

Терминирующий провайдер способен проверить подпись, сертификатный путь и claims. Абонентское устройство может не уметь проверять PASSporT. RFC 9796 позволяет провайдеру перенести выбранные принятые результаты в Call-Info и передать их аутентифицированному устройству на доверительном пользовательско-сетевом интерфейсе.

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

Поэтому журнал должен различать: предложение RCD; наличие PASSporT; проверку подписи и сертификата; сравнение claims и дайджестов; решение локальной политики; перевод результата названным участником; созданное поле; аутентификацию peer на UNI; загрузку ресурса; совпадение хеша; решение отрисовать; фактический показ; действие пользователя; последующее подтверждение личности и цели; результат услуги.

Если verified отсутствует, получатель должен исходить из того, что соответствующая информация не была получена и проверена по процедурам RFC 9795. Это отсутствие конкретной квитанции, а не доказательство мошенничества.

У элементов карточки разные пути хранения

RFC 3261 задаёт SIP и заголовок Call-Info. Обычное отображаемое имя в From не становится достоверным от самого присутствия и может быть заменено по пути. RFC 9796 даёт более точный способ выразить происхождение проверки выбранных данных.

jCard определена в RFC 7095 на основе синтаксиса JSON из RFC 8259. Профиль RCD допускает один объект entity и требует согласованности пересекающихся имён, фотографий, логотипов, From, P-Asserted-Identity и значков. Согласованность нужна именно потому, что карточка собирается из нескольких представлений.

jCard можно встроить в URI data:, поместить в MIME-часть, адресуемую схемой cid: из RFC 2392, либо получить из источника с проверяемой целостностью — например, по HTTPS, связанному с валидированным доменом. Встроенный объект, часть сообщения и внешний ресурс имеют разных хранителей и разные точки отказа.

Пустой data: URI вместе с purpose=jcard может кратко передать проверенность отображаемого имени. Краткость не устраняет автора утверждения. Напротив, его нужно сохранить отдельно, потому что сам объект почти ничего о происхождении не несёт.

Совпавший хеш не объясняет изображение

integrity связывает алгоритм и дайджест с ресурсом по URI. Реализации обязаны поддерживать SHA-256, SHA-384 и SHA-512. Совпадение подтверждает равенство полученных байтов объявленному значению.

Оно не подтверждает, кто управлял ресурсом, актуален ли он, был ли доступен во время звонка, разрешила ли политика показ, увидел ли его человек и законен ли разговор. Байтовая целостность — не биография ресурса и не доказательство намерения.

У call-reason другая форма того же ограничения. Поле необязательно, должно быть коротким, может быть обрезано, а его отображение не гарантируется. Как вызывающий формирует причину, спецификация не решает. Текст «служба безопасности банка» остаётся сообщённой причиной, а не доказанной ролью.

RFC 7852, описывающий пространство SIP Resource-Priority, показывает общий принцип: протокольная отметка имеет ограниченную семантику внутри системы авторизации. Официальное название не переносит на неё всю власть окружающей системы.

Переписанная карточка больше не является проверенным объектом

RFC 9796 требует представлять одну согласованную версию RCD-связанных Call-Info. Последующие участники не должны менять её или добавлять конфликтующие поля. Без STIR либо другой защиты обнаружение изменений в недоверенных объединённых сетях нельзя считать гарантированным.

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

Публичные материалы подтверждают состояние стандарта, но не внедрение. Нормативный текст доступен в текстовом и XML виде. Информационная страница, errata и история IETF показывают состояние документа. Реестр параметров SIP IANA фиксирует имена. Эти записи ничего не доказывают о конкретном операторе, шлюзе или телефоне.

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

RFC 9796 полезен потому, что позволяет сложной инфраструктуре помочь простому устройству. Граница ответственности сохраняется, если вместе с результатом остаётся имя того, чьё решение устройство приняло.

Источники