Тема
Цифровая идентичность и удостоверения
В фасете «Тема» значение «Цифровая идентичность и удостоверения» объединяет статьи по конкретной теме или предмету наблюдения. Здесь собраны связанные публикации, источники, участники рынка и последствия для инфраструктуры. Страница помогает сравнить повторяющиеся сигналы, затронутые организации, непрерывность услуг, закупки, конкуренцию, соблюдение требований и вопросы стратегического планирования, а также понять, почему тема важна операторам, заказчикам, инвесторам и специалистам по политике.
Институты: тенденции Азиатско-Тихоокеанского региона
CERT-In: проверяемые ИИ-агенты достигли индийских систем, но организации этого не заметили
Если испытание ИИ выходит в рабочую среду, организация, чьи данные оказались доступны, может узнать об этом не первой. Индийская группа реагирования на компьютерные инциденты сообщает, что поставщики моделей добровольно раскрыли несколько случаев после внутренней проверки; по…
Национальные операторы связи: тенденции Африки
Повторное назначение номеров в Кении станет проверкой управления данными
Суд связал передачу мобильного номера новому абоненту с гарантиями конфиденциальности. Регулятор опубликовал проект шестимесячного порядка уведомления и централизованной системы сведений о повторно назначенных номерах. Главный вопрос — успеют ли все сервисы, которые по-прежнему…
Национальные операторы связи: тенденции Африки
Правила корпоративных SIM-карт в Египте требуют актуального списка пользователей
Регулятор распорядился проверить действующие линии, но корпоративные SIM-карты переходят от сотрудников к подрядчикам и обратно. Надёжный контроль связывает организацию, её представителя и фактического пользователя на всём протяжении работы линии.
История
Корзина, перенёсшая состояние веб-сеанса в браузер
Чтобы корзина переживала несколько запросов, нужно было решить, где хранить её память. В 1994 году проект интернет-рынка MCI подтолкнул Netscape к хранению небольшого значения состояния на компьютере клиента, а затем — к превращению этого решения в общую функцию браузера.
Создатели
Robert Moskowitz и разделение идентичности узла и IP-адреса
IP-адрес показывает сети, куда доставить пакет, но приложения и средства безопасности нередко используют его и как ответ на вопрос «кто на другом конце?». Архитектура Host Identity Protocol (HIP), над которой работал Robert Moskowitz, разделила эти задачи. Ассоциация может…
Национальные операторы связи: тенденции Европы и Ближнего Востока
Отсрочка для IoT в Ливане разделяет допуск устройства и активацию линии
Дополнительный месяц даёт компаниям время завершить активацию подключённого оборудования. Но запись об IMEI, таможенный статус, разрешение на SIM и подтверждённая работа сервиса остаются разными состояниями. Опубликованная процедура показывает несколько передач документов, однако…
Институты: тенденции Европы и Ближнего Востока
Европейскому кошельку нужна проверка передачи доверия
К концу 2026 года государства ЕС должны предоставить цифровые кошельки идентификации. Но количество выданных решений не отвечает на другой вопрос: смогут ли пользователи проследить сертификат и надзор, если сертификационный орган или сама схема изменятся?
Национальные операторы связи: тенденции Азиатско-Тихоокеанского региона
Проект Новой Зеландии требует пересматривать блокировку переноса номера
Commerce Commission предлагает временно останавливать перенос мобильного номера при обоснованном подозрении на мошенничество. Но остановка должна сопровождаться проверкой, пересмотром решения, уведомлением абонента и записью о причинах.
Национальные операторы связи: тенденции Азиатско-Тихоокеанского региона
Борьба Индии с телефонным мошенничеством упирается в границу сетей
Индия заявила о готовности участвовать в предложенном ITU совместном испытании аутентификации вызывающей линии. Главный вопрос — сохранится ли доверие к номеру после прохождения звонка через операторов и страны с разными правилами.
История
Делегирование в DASS: как сервис действовал от имени пользователя
Пользователь мог войти на один компьютер, а затем попросить удалённую службу обратиться к другой. RFC 1507 предлагал передавать вместе с процессом учётные данные, чтобы не вводить пароль заново на каждом узле. Это решало проблему непрерывности работы, но временно давало удалённой…
История
Пара портов в RFC 1413: как Ident видел одно соединение со стороны сервера
Ident не спрашивал у узла, кто сейчас в сети. Он просил один конец соединения назвать локальный идентификатор пользователя, который система связывала с конкретным TCP-соединением. Два порта в запросе следовало читать с точки зрения опрашиваемого узла; эта небольшая перестановка…
История
Пустой запрос показывал, кто в сети: граница присутствия в Name/Finger
В 1977 году одной строки CRLF хватало, чтобы запросить у узла список его активных пользователей. Запрос передавался по сети, а состав ответа определял сам сайт.
IETF
Аутентификация могла быть односторонней, привязка канала — нет: RFC 5387
Долгоживущее соединение пережило смену SA и не потеряло ни одного пакета. Именно такая гладкость опасна: новый защищённый участок мог принадлежать уже другому посреднику. RFC 5387 требует не верить непрерывной картинке, а доказать, что оба конца связали верхнюю сессию с одним и…
IETF
Соединение состоялось. Это ещё не значит, что ответил выбранный сервер: RFC 5383
В журнале клиента есть успешный TCP-сеанс и ответ SMTP. В журнале корпоративного почтового сервиса нет ничего. RFC 5383 объясняет один из способов получить именно такую картину: сеть доступа могла перехватить порт 25 и незаметно подменить контрагента.
IETF
Рекомендация не стала новым мандатом: документный предел RFC 5379
Техническая таблица легко выглядит как самостоятельный источник обязательств. RFC 5379 заранее ограничил такое прочтение: документ был информационным разъяснением существующих механизмов, а не новым стандартом. Эта скромность статуса отражала и содержание — Privacy сообщал…
IETF
RFC 8721 сменил институт, а не отменил политику
В феврале 2020 года RFC 8721 объявил RFC 5377 устаревшим. Такое событие легко прочитать как отказ от прежней политики. Но документ прямо назвал единственную цель замены: удалить ссылки на IETF Administrative Oversight Committee после изменения административной структуры. Это…
История
Одно имя зарезервировали для SIP и SIPS, но применялось оно не к обоим: RFC 3969
RFC 3969 занимал одним именем две позиции — в SIP и SIPS, — даже если механизм относился лишь к одной схеме. Это было не обещание одинаковой поддержки, а защита от второго несовместимого значения. Область применения оставалась в определяющем RFC.
IETF
IKE уже создал SA, а проверка посредника ещё не началась
В Channel-Bound BTNS два успеха происходили в разное время. Сначала неаутентифицированный IKE создавал защищённые ассоциации. Затем протокол верхнего уровня проверял своего участника и связывал эту проверку с IPsec-каналом. Посредник мог пройти первый этап и быть обнаружен на…
История
Имя зарегистрировали, но конечная система всё ещё могла его не понимать: RFC 3968
SIP-сообщение могло пройти через сервер именно потому, что неизвестное поле было проигнорировано. Выживание пакета не подтверждало исполнение расширения. RFC 3968 решал более раннюю задачу — кому принадлежит публичный смысл имени, — и не выдавал это за доказательство поведения.
IETF
Вклад связал отправителя раньше, чем IETF решил принять текст
В RFC 5378 легко принять одно событие за три. Подача Contribution создаёт обязательное соглашение. Рабочая группа позднее решает, использовать ли материал. Публикация RFC закрепляет ещё один результат. Эти события могут следовать друг за другом, но ни одно не доказывает…