Тема
Цифровая идентичность и удостоверения
В фасете «Тема» значение «Цифровая идентичность и удостоверения» объединяет статьи по конкретной теме или предмету наблюдения. Здесь собраны связанные публикации, источники, участники рынка и последствия для инфраструктуры. Страница помогает сравнить повторяющиеся сигналы, затронутые организации, непрерывность услуг, закупки, конкуренцию, соблюдение требований и вопросы стратегического планирования, а также понять, почему тема важна операторам, заказчикам, инвесторам и специалистам по политике.
IETF
Сертификат истекал в 9999 году. Привязку к документу могли не проверить.
Сертификат одной подписи предназначен для одного документа, одного закрытого ключа и одной операции. Предлагаемое расширение сужает область применения, однако успешная обычная проверка подписи не доказывает ни сравнение документа с привязкой, ни уничтожение ключа, о котором…
IETF
Составная подпись прошла проверку. Конверт назвал другой алгоритм.
Composite ML-DSA объединяет постквантовую и классическую подписи в один интерфейс. Но в CMS одного ответа «верно» недостаточно: дайджест, идентификаторы алгоритмов, подписанные атрибуты и точная последовательность байтов должны согласоваться во всём конверте.
История
Контрольная сумма назвала снимок. Сохранение всё ещё требовало архива: RFC 3188
Финский сборщик мог превратить MD5 захваченного файла в локальную часть NBN и отличить этот снимок от другой сетевой версии той же книги. Но контрольная сумма не была хранилищем. RFC 3188 оставлял за кадром работу, без которой имя переживает объект: захват, хранение, миграцию и…
IETF
Издатель подписал оболочку, но не получил права заменить ключ агента
В AIC-JWT 02 подписанное принципалом делегирование помещается внутрь удостоверения, подписанного издателем. Такая конструкция отделяет доставку полномочия от права менять его носителя.
История
Ошибочный ISBN исправили. Его след нельзя было стереть: RFC 3187
Издатель мог по ошибке напечатать на второй книге номер первой. Каталог затем связывал неверный ISBN с правильным, но бумажные экземпляры, цитаты и старые записи уже продолжали жить. RFC 3187 допускал честный ответ — несколько библиографических записей и явную поправку — вместо…
IETF
Агент подписал вызов. Вложенный ключ всё ещё не был полномочием.
В OpenA2A AIP версии 03 математически верная подпись отделена от установленной личности. Предъявленный ключ доказывает владение секретом; право этого ключа представлять агента должно прийти из реестра или разрешённого DID-документа.
IETF
Агент замолчал. Оценка наказала то, чего не увидел проверяющий.
NBTP предлагает превращать пропущенные heartbeat, окна oracle и совместное молчание в затухание доверия и состояния SUSPECT или QUARANTINED. Механизм полезен лишь тогда, когда отсутствие остаётся утверждением о поверхности наблюдения, а не становится характеристикой агента.
История
Сообщение расшифровалось. Это не назвало отправителя и не доказало свежесть: RFC 3185
Получатель нашёл старый ключ, вывел новый и получил осмысленный открытый текст. Даже такой успех отвечал не на все вопросы. RFC 3185 прямо предупреждал: правильная ссылка на ключ не аутентифицирует отправителя и не препятствует повтору. Более того, старый ключ мог оставить доступ…
История
Внутри домен узнал человека. Снаружи получатель видел лишь домен: RFC 3183
Подписывающий узел организации мог достоверно установить, какой сотрудник отправил письмо, и всё же не передать внешнему получателю проверяемое имя этого сотрудника. RFC 3183 провёл границу между внутренней аутентификацией и внешней атрибуцией: домен свидетельствовал о выпуске…
История
Имя вошло в RSVP. Власти ещё предстояло решить, что оно означает: RFC 3182
Среди ошибок RFC 3182 была `IDENTITY_CHANGED` — «идентичность изменилась». Уже это название разрушало удобную иллюзию постоянства. Идентичность в сигнальном сообщении была состоянием, которое проверяли, заменяли, выбирали и иногда отвергали. Имя могло указывать на политику, билет…
IETF
Две стороны платежа совпали. Запись о доставке всё ещё пуста.
Два агента могут хранить совпадающие свидетельства движения денег, а доказательство обещанной встречной поставки при этом останется на отдельной, пустой дорожке.
IETF
Доказательство пакета прошло. Сколько токенов действительно попало в запас?
Пакетная выдача Privacy Pass сокращает число обменов и распределяет стоимость доказательства между несколькими токенами. Но она не ведёт локальный склад: корректная криптография, успешный ответ, финализация, долговременная запись и последующее погашение остаются разными…
IETF
Реестр может назвать контрольный вопрос. Сделать его приемлемым он не может.
Общий идентификатор помогает системам сообщить, какой метод использовался, но не придаёт этому методу надёжность, разрешение или уровень гарантии.
IETF
Заказ ACME указал профиль. Сертификату всё равно пришлось доказать соответствие
ACME Profiles переносит выбор политики выпуска в явное поле заказа. Это делает автоматизацию чище, но имя профиля не доказывает состав сертификата, его установку и принятие клиентом.
IETF
Метод AML сработал. Это не означает, что клиент прошёл проверку.
Переносимый код метода способен подтвердить запуск проверки, но не заменяет доказательства и локальное решение о клиенте или операции.
IETF
Контейнер разговора подписан. Но что именно этим доказано?
vCon предлагает переносить участников, диалог, вложения и машинный анализ в одном контейнере. Подпись защищает конкретное состояние данных, но не устанавливает автоматически полноту записи, личность собеседников, действительность согласия, качество вывода или полномочия…
IETF
Метод сработал. Метка `ivm` всё ещё не является доказательством.
Трёхбуквенный код способен согласовать работу систем, но не способен сделать разные случаи проверки личности равноценными.
IETF
Токен KYAPay может идентифицировать агента. Решение остаётся за получателем.
Подписанное утверждение делает автоматический запрос более подотчётным, но не превращает эмитента в распорядителя чужой точки доступа.
IETF
Кто вправе поручиться за OAuth-клиента? Одной записи в метаданных недостаточно
Издатель клиента может назвать допустимого аттестатора, но не может приказать серверу авторизации доверять ему. Новый проект показывает, почему подпись, источник ключей, право доступа и прекращение доступа требуют разных решений.
IETF
Дочерний токен был действителен. Но полномочие должна была доказать вся цепочка.
Безупречная подпись дочернего OAuth-токена подтверждает действие одного ключа, а не право на операцию. Это право возникает только тогда, когда доверенный корень, каждый переход, каждое сужение, актуальный статус и локальная политика ресурсного сервера образуют один непрерывный…