Кратко

  • Редакция -01 проекта Wallet State Attestation вышла 27 сентября 2026 года как индивидуальная заявка. Она не является RFC, одобрением IETF или свидетельством внедрения.
  • В JSON на верхнем уровне подписаны id, pass, results и attestedAt. Адрес может присутствовать в конкретном условии, но подписанный объект не всегда называет кошелёк в целом.
  • expiresAt передаётся вне подписи JSON. Дополнительный JWT подписывает sub и exp; его заявления требуют самостоятельной проверки, даже когда рядом уже есть проверенный JSON.

Старый ответ может оставаться подлинным

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

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

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

Чей именно ответ?

Другая граница возникает при пересылке. Верхний подписанный объект JSON состоит из id, pass, results и attestedAt; отдельного обязательного поля с адресом кошелька в нём нет. Иногда адрес включён в evaluatedCondition, тогда он защищён внутри results. Но из формы ответа вообще это не следует. Инициатор знает, какой адрес послал эмитенту. Следующая служба, получившая только аттестацию, может не иметь этого знания. Подлинный pass сам по себе не связывает результат с учётной записью, которую служба собирается открыть.

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

Правило выбора ключа в новой версии жёстче. Если kid не передан или его нет в доступном JWKS, итог — «невозможно проверить», а не «подпись опровергнута». Неудачная проверка под тем ключом, на который указывает kid, — уже второй случай. В обоих случаях принимать ответ нельзя. При устаревшем кеше JWKS можно обновить набор и попробовать снова; подставить первый ключ из списка в качестве догадки проект запрещает. Разделение причин отказа позволяет понять, нужна ли синхронизация ключей или расследование иного несоответствия.

JWT нельзя проверять чужой подписью

Если запрошен JWT, эмитент присылает отдельный подписанный токен. sub в нём обозначает кошелёк, для которого действительно оценивалось условие; exp задаёт подписанный срок, а kid помещён в защищённый заголовок. Получатель, использующий эти поля, должен проверить сам JWT. Когда представлены и JWT, и JSON, документ предусматривает сверку соответствующих значений и отклонение всего ответа при неверном или несовместимом токене. При этом сверка не охватывает sub как поле JSON: универсального поля кошелька там нет. Доказательство адреса в JWT основано на собственной подписи токена.

Дополнительное доказательство Меркла возможно лишь для поддерживаемых условий и цепочек. Там, где оно доступно, получатель может проверять наблюдаемое значение более независимо от эмитента, но может раскрыться сырой баланс, который простое «да» скрывало. Не следует выдавать необязательную проверку за повсеместную или бесплатную с точки зрения приватности.

По словам автора, подписи, выпущенные по редакции -00, продолжают проверяться по новой. Поэтому нельзя представлять неподписанное expiresAt или отсутствие общего адресного поля как нововведение, созданное сентябрьским текстом. Новое — более точное описание области подписи, альтернативной схемы, добавочной подписи и ветвей отказа. Datatracker показывает активный индивидуальный Internet-Draft без потока RFC со статусом IESG I-D Exists и предупреждает, что размещение не означает одобрения IETF. Перечисленные автором применения не служат здесь независимо проверенным свидетельством эксплуатации.

Источники