Кратко

  • Варианты Base64 с пометкой sloppy в RFC 9741 пропускают проверку нулевых неиспользуемых битов. Оператор .json ограничивает декодированное значение, а не единственную текстовую сериализацию.
  • Влияние альтернативной записи на разрешения, кеш или расчёты определяется реальными ключами и связями сервиса. Совпадение байтов само по себе не доказывает обход проверки или ошибочное списание.
  • Допустимые представления, деловая идентичность и криптографический вход требуют отдельных правил. После изменения состояния особенно важно сохранить ограниченный, но достаточный след исходного представления и его контекста.

Спор нельзя восстановить по одному утверждению «данные одинаковые»

Представим обращение клиента: два запроса, одна и та же информация и два начисления. Техническая команда подтверждает равенство декодированных данных. Финансовая команда видит две строки с разными текстовыми ключами. Ни одна из этих позиций ещё не объясняет, что именно продавал сервис и какое действие было разрешено.

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

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

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

Вариант записи может находиться за пределами полезных битов

RFC 9741, подготовленный Carsten Bormann, опубликован в марте 2025 года в рамках стандартного трека IETF и добавляет в CDDL средства преобразования и обработки текста. .b64u и .b64u-sloppy относятся к Base64url без заполнения, .b64c и .b64c-sloppy — к классическому Base64 с заполнением. Варианты sloppy не проверяют, равны ли дополнительные неиспользуемые биты нулю; остальные правила от этого не отменяются. .json также не ограничивает незначащие пробелы или порядок сериализации элементов отображения. Статус RFC не доказывает реализацию конкретным инструментом.

Пара Zg и Zh показывает разницу на одном байте. Первые восемь битов в обоих случаях — 01100110, то есть 0x66. Оставшиеся четыре бита второй шестибитной группы равны соответственно 0000 и 0001. Это ручной вывод из расположения битов, а не выполненный тест соответствия валидатора CDDL. Для одного контрольного значения, допускающего этот байт, существенное различие строгого и sloppy-варианта находится именно в этих неиспользуемых битах. В классическом представлении с заполнением соответствующая пара — Zg== и Zh==.

RFC 4648, раздел 3.5, требует нулевых битов заполнения от соответствующих кодировщиков и объясняет выбор отказа декодером в зависимости от ссылающейся спецификации. Четыре переменных бита дают шестнадцать записей с одинаковыми полезными битами в этой однобайтовой схеме. Это не универсальное число вариантов для токена любой длины.

Строгий вход может отвергнуть неканоническую запись. Ограниченный вход совместимости может её принять. Но слово sloppy не разрешает игнорировать любой пробел, смешивать алфавиты или восстанавливать обрезанный текст. Такое расширение уже было бы иной политикой, которую нельзя приписать RFC.

Проверка формы не выдаёт стабильный деловой ключ

Более привычный пример использует JSON:

{"account":"team-a","units":1}

{ "units": 1, "account": "team-a" }

Здесь сохранены одни и те же фиксированные строки и малое целое число 1; дублирующихся имён нет. Меняются только порядок членов объекта и незначащие пробелы. RFC 8259 описывает синтаксис JSON. RFC 7493 об I-JSON исключает, среди прочего, повторяющиеся имена и указывает, что порядок членов не меняет смысл сообщения.

Оператор .json использует преобразование JSON в CBOR по умолчанию из RFC 8949, раздел 6.2. Он описывает полученное значение, а не единственный текстовый вывод. Если разрешение ищут по полной строке формы, а исполнение — по декодированному значению, успешная проверка формы не гарантирует правильную связь этих записей.

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

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

Кеш может забыть различие, которое подпись обязана сохранить

Текстовая разница может не интересовать хранилище и одновременно входить в доказательство подлинности. В обычном JWS с нагрузкой, закодированной в Base64url, RFC 7515 определяет подписываемый вход через закодированный защищённый заголовок, точку и закодированную нагрузку. Равенство после разбора JSON не даёт права заменить этот вход новой сериализацией.

Приложение может явно выбрать каноническое представление модели для криптографических операций. JCS из RFC 8785 даёт детерминированное представление в пределах своих входных ограничений, но это информационный RFC независимого потока, а не скрытое требование .json. Здесь правила обычного JWS не распространяются на расширения с незакодированной нагрузкой или все другие оболочки подписи.

Следовательно, указание «нормализовать перед использованием» не задаёт достаточной процедуры. Перед каким использованием и после сохранения какого входа? Правило индекса ресурсов не уполномочивает изменять данные, нужные выбранной схеме проверки подлинности. Исходная запись может быть именно тем, что удостоверил отправитель.

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

Два начисления могут быть обоснованными, а два учтённых ресурса — нет

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

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

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

Область клиента, цели, операции, версии профиля и идентичности запроса важна и для расследования, и для профилактики. Глобальное слияние по содержимому может объединить записи, которые должны быть изолированы. Дедупликация ресурса не заменяет разделение прав между клиентами.

Общая техническая проверка не должна подменять полномочия

Lu Heng в рассуждении о минимальной общей спецификации отделяет детерминированные общие правила от деловых договорённостей и последующих решений операторов. Здесь это аналитическая перспектива: точно описать приём, не превращая отметку соответствия в решение о цене и разрешении. Это не его рецензия на RFC 9741 и не требование IETF к расчётам.

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

RFC 8610, раздел 5, уже предостерегает от зависимости только от корректности спецификации CDDL и её механизма сопоставления без других защит. Чем яснее связь текста со значением, тем легче увидеть оставшиеся вопросы. Совместимость может экономить работу клиента, но не становится бесплатной, если внутреннее сопоставление и разбор споров остаются без ответственного.