Кратко

  • 1 сентября IESG объявила обще-IETF Last Call по редакции -19 SD-JWT VC. Рабочая группа OAuth просит опубликовать документ как Proposed Standard; комментарии принимаются до 15 сентября, решения ещё нет.
  • Обязательный vct задаёт основной тип. Эмитент может перечислить дополнительные типы в aka_vcts, а extends связывает документы Type Metadata отношением наследования.
  • Эти механизмы нужны для сопоставления и повторного использования правил. Проект прямо запрещает считать их доказательством того, что эмитент уполномочен выпускать известный тип.
  • У Publisher метаданных есть собственная проблема полномочий: успешная загрузка и проверка целостности не показывают, что именно он вправе определять данный тип.
  • Экосистемный протокол полномочий может отдельно связать тип с основанием для эмитента и Publisher, не превращая IETF во всемирный реестр доверия.

Last Call — это проверка, а не готовый стандарт

Объявление IETF от 1 сентября касается draft-ietf-oauth-sd-jwt-vc-19. Рабочая группа OAuth передала его в IESG и просит статус Proposed Standard. Срок Last Call заканчивается 15 сентября. На момент сбора доказательств Datatracker показывал «In Last Call»: дата telechat отсутствовала, проверка IANA требовалась, окончательного решения IESG не было.

IESG называет Last Call в обычной ситуации заключительным этапом открытого обсуждения сообществом. Это возможность проверить аргументы и текст, а не предварительная публикация RFC. Следующая редакция, возврат в рабочую группу или одобрение остаются разными возможными исходами.

Технической основой служит RFC 9901. Эмитент подписывает JSON, где часть утверждений видна непосредственно, а часть заменена хешами. Держатель затем открывает выбранные сведения конкретному проверяющему. Тот проверяет подпись эмитента, соответствие раскрытий и, если политика требует, криптографическую привязку к ключу держателя.

SD-JWT VC превращает этот механизм в формат цифрового удостоверения. Обязательный vct — чувствительный к регистру, устойчивый к коллизиям идентификатор типа. Сам проект не определяет ни одного конкретного значения. Семантику типов, правила claims и дополнительные правила выдачи и проверки задают внедряющие экосистемы.

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

Родство типов не образует цепочку делегирования

Свойство extends находится в Type Metadata. Оно сообщает, что один тип расширяет другой. Consumer сначала обрабатывает родительские метаданные, затем дочерние. Унаследованные правила claims сохраняются: дочерний тип не вправе сделать необязательным поле, обязательное у родителя, или ослабить фиксированное правило выборочного раскрытия.

aka_vcts устроен иначе. Это необязательный список дополнительных типов, который сам эмитент включает в удостоверение. Если проверяющий запросил общий тип, а получил специализированный, список помогает выполнить сопоставление. Type Metadata для этого не обязательны; порядок значений ничего не означает; связь через extends между ними не требуется.

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

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

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

Авторитет Publisher нельзя получить по HTTPS

В проекте появляется ещё одна роль — Publisher. Он публикует Type Metadata или вспомогательные ресурсы и может не совпадать с эмитентом. Это может быть орган стандартизации, сообщество, орган конкретной экосистемы или иная сторона, описывающая тип.

Документ задаёт названия, claims, визуальное представление и отношения наследования. Consumer может загрузить его по HTTPS и сверить значение целостности. Однако эти проверки говорят, какую версию он получил и была ли она изменена. Они не объясняют, почему Publisher имеет право определять тип.

Раздел 7.8 требует не считать Type Metadata точными или значимыми, пока Publisher не признан авторитетным для данного типа. Экосистемам рекомендуется определить управление или аккредитацию: кто может публиковать метаданные каких типов и при каких условиях им можно доверять.

Отсюда следуют две отдельные линии полномочий. Первая связывает эмитента с законом, договором, аккредитацией, реестром или trust list, разрешающими выдачу. Вторая связывает Publisher с основанием определять или описывать тип. Даже одна организация может утратить одну роль, сохранив другую, или иметь разные сроки и территориальный охват.

Подпись доказывает владение ключом, а не мандат

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

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

Концепция Heng Lu о легализации мандата описывает момент подмены. Техническая оболочка начинает восприниматься как источник полномочий, на который она всего лишь указывает. В кошельке путь короток: знакомый тип, действительная подпись, отметка «проверено». Если отметка не раскрывает предмет проверки, контроль ключа читается как право выдачи.

Достоинство редакции -19 в том, что этот переход остановлен нормативным текстом. Теперь операционные журналы и интерфейсы не должны снова соединить разорванные звенья.

Протокол полномочий для внешней политики

Центральный всемирный список IETF для этого не нужен. Каждая экосистема может вести небольшой версионируемый протокол полномочий для принимаемых пар «эмитент — тип».

Он фиксирует точный vct, принятые aka_vcts и обработанную цепочку extends. Затем указывает идентификатор эмитента, метод обнаружения и проверки ключа и внешнее основание выдачи: реестровую запись, аккредитацию, норму закона, договор или trust list.

Отдельный блок называет Publisher Type Metadata, версию и ссылку целостности документа, а также основание, позволяющее ему определять этот тип. Сфера действия, юрисдикция или экосистема, срок, версия политики проверяющего и время решения обеспечивают воспроизводимость. Явная оговорка сообщает, что подпись, совпадение, alias, наследование и целостная загрузка по отдельности не устанавливают институциональную компетенцию.

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

Этот протокол — редакционная рекомендация статьи, а не требование редакции -19. Он сохраняет решение внешней политики, которое общий формат разумно оставил за пределами токена.

Не следует возвращать управление внутрь формата

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

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

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

Источники

  1. IETF — Last Call по SD-JWT VC -19
  2. IETF Datatracker — карточка SD-JWT VC
  3. IETF — SD-JWT VC, редакция -19
  4. RFC 9901 — Selective Disclosure for JSON Web Tokens
  5. IESG — руководство по Last Call
  6. IETF — устав рабочей группы OAuth
  7. Heng Lu — Mandate Laundering