Кратко

  • vCon overview revision 02 и core revision 04 остаются рабочими Internet-Draft. Создатель выбирает границы разговора, а любой из четырёх основных разделов контейнера может отсутствовать.
  • JWS доказывает целостность payload и, при заданной политике доверия, владение ключом подписи. Сам по себе этот результат не подтверждает полный захват разговора, личность стороны, актуальное согласие или точность анализа.
  • Цепочка amended сохраняет последовательность подписанных состояний. Для решения нужен ещё и реестр, который связывает каждое утверждение с источником, охватом, целью и уполномоченным субъектом.

На экране контроля всё зелёное. Первая версия vCon содержит запись, вторая — расшифровку, третья — исправленное имя участника и оценку тональности. Все JWS валидны, новые версии ссылаются через amended на UUID предыдущих, SHA-512 доступного аудио совпадает с content_hash.

Но второй канал записи возвращает 403. Имя исправила компания, выполнявшая транскрибацию, а не система аутентификации. В объекте анализа есть vendor, но нет версии модели, языка и настроек. Согласие охватывало запись и контроль качества, а не кадровое решение на основе эмоциональной оценки.

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

draft-ietf-vcon-overview-02 датирован 30 сентября 2026 года, draft-ietf-vcon-vcon-core-04 — 7 сентября. Оба документа подготовлены рабочей группой IETF Virtualized Conversations и остаются Internet-Draft, а не RFC или завершёнными стандартами. Они описывают JSON-контейнер для перемещения разговорных данных между платформами связи, сервисами анализа и доменами безопасности. Такая переносимость полезна только при точном разделении видов доверия.

За одним словом «проверено» скрыты пять решений

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

JWS непосредственно решает первую задачу и помогает во второй. Структура vCon способна нести свидетельства для третьей. Четвёртая и пятая требуют решения вне payload. Ложное утверждение можно безупречно подписать; точное утверждение можно использовать без права.

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

Границы разговора задаёт составитель

Overview признаёт, что разговор не всегда обладает естественными границами. Один vCon может представлять одну запись, другой — путь от сообщения через звонок к письму. В SMS кто-то должен решить, какие сообщения относятся к одной сессии.

Разделы parties, dialog, attachments и analysis опциональны. Запись без списка сторон может быть корректным vCon. Core различает recording, recording-set, text, transfer и incomplete, допускает placeholder. Один объект записи способен описывать только один участок вызова или часть каналов и не перечислять всех участников.

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

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

Overview называет диалог “ground truths”. Это подчёркивает первичность перед производным анализом, а не всеведение сенсора. Подлинная запись может быть неполной или приписанной не тому человеку.

Поля Party Object не равны установленной личности

Party Object может содержать имя, телефон, email, SIP URI, DID, UUID и местоположение. validation описывает способ проверки, не раскрывая сами проверочные данные. Это полезная приватностная граница, но оценку метода выполняет получатель.

Если подписанный объект сообщает «проверено учётными данными», подпись устанавливает автора заявления. Она не раскрывает, какие данные, когда и с каким уровнем assurance проверялись, кому теперь принадлежит аккаунт и достаточно ли метода для текущего решения.

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

Постоянный UUID также имеет смысл в namespace выдавшей системы. Он способен коррелировать оператора внутри организации, но не становится глобальной идентичностью после экспорта. Если amendment заменяет псевдоним гражданским именем, надо проверить полномочия на изменение идентичности, а не только валидность ключа.

Hash переживает объект, на который он указывает

Диалог, вложение и анализ могут находиться внутри контейнера или по HTTPS URL. content_hash и SHA-512 позволяют сравнить полученные байты с теми, которые закреплены подписанным vCon.

Core прямо оставляет за пределами документа безопасное хранение, контроль доступа и обмен credentials для внешних данных. URL может вернуть 403, 404 или истечь по retention. Hash останется правильным, хотя доказательство уже нельзя исследовать.

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

Если на годы сохранить только vCon и hash, останется обязательство относительно когда-то существовавших байтов, но не возможность перепроверки. Руководство должно выбрать архивирование самих данных, устойчивый контролируемый доступ или явный срок утраты доказательной способности.

Происхождение анализа не означает его точность

Analysis Object поддерживает транскрипт, перевод, сводку, тональность и отчёт. Core не унифицирует все форматы, требует vendor и допускает product и schema. Overview отмечает различия в качестве и интерпретации реализаций.

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

Производному утверждению нужен собственный receipt: индексы и hashes входов, vendor, product, schema, версия модели или правил, конфигурация, locale, hash результата, смысл confidence, ручная проверка и допустимая цель. Такой реестр — предложение Daniel Kade, а не нормативное требование drafts.

Подпись надёжно сохраняет, что система выдала. Она не превращает происхождение в качество, а качество — в разрешение действовать.

У согласия есть цель и часы

Overview рассматривает согласие и происхождение как контекст. Privacy primer и draft о lawful basis исследуют уведомление, цель и юрисдикцию. Они не превращают подпись vCon в универсальный сертификат правомерности.

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

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

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

Amendment хранит историю, но не назначает победителя

Прямая правка подписанного vCon разрушает подпись. Поэтому создаётся новая instance version — глубокая копия прежней с дополнениями или исправлениями, связанная через amended с UUID, а иногда URL и hash предшественника. Разные домены могут подписывать последовательные этапы.

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

Redaction показывает ту же границу. Core выносит метод за пределы спецификации и относит assurance к создателю подписанной redacted-версии. Тот может честно подписать результат и пропустить персональные данные в attachment, analysis или незнакомом extension.

«Последняя подписанная версия» не должна автоматически означать «авторитетная версия». Сервис анализа может добавлять transcript, не имея права переименовывать сторону.

Неизвестный extension оценивается относительно операции

Extensions добавляют поля, меняют семантику или выводят параметры из употребления. Несовместимые перечисляются в critical; неподдерживающий processor должен отказать или сообщить проблему, а не продолжить.

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

Следует фиксировать список extensions, critical, версии registry и ПО, операцию и обоснование игнорирования или отказа. Успешный JSON parse не доказывает понимание смысла.

Реестр доказательств стоит рядом с контейнером

Каждое решение связывает UUID, payload hash и форму vCon; охват и пробелы; системы и домены; подписанта, статус сертификата и policy; идентификационные доказательства; покрытие записи; внешний доступ; входы и конфигурацию анализа; разрешённую цель; способности extensions; предшественника и diff; ответственного и путь отмены.

Наблюдения отделяются от переносимых утверждений. «SHA-512 полученных байтов совпала» — наблюдение. «Личность проверена credentials» — утверждение payload до связи с событием. «Допустимо для качества до даты X» — локальное решение.

Порядок: охват -> получение -> байты -> подписант -> полномочия -> extensions -> lineage -> утверждения -> цель -> запись зависимости -> отзыв.

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