< Назад к новостям

Появились подпись Идентичности SSP и аутентификация запросов

·5 мин. чтения·Автор: SSP Editorial Team
Обложка с отпечатком пальца, щитом с галочкой, замком и ключом над заголовком «Подпись Идентичности SSP и аутентификация запросов».

Между v1.29.0 2025-12-27 и v1.30.0 2026-01-02 SSP выпустил два релиза, которые выглядят маленькими в журнале изменений и большими в архитектурной диаграмме. v1.29.0 добавил аутентификацию запросов — кошелёк проверяет источник и целостность каждого запроса dApp, который он получает. v1.30.0 добавил SSP Identity Signing — кошелёк может доказать собственную идентичность удалённому сервису, а не только подписать транзакцию. Вместе они укрепляют поверхность запросов dApp, открывшуюся с WalletConnect, и превращают исходную функцию Identity в примитив первого класса, который сервисы могут оспаривать.

Аутентификация запросов прибывает (v1.29.0)

Запрос dApp — подпиши это, одобри то, переключись на эту цепочку — поступает в кошелёк через транспорт. С WalletConnect этот транспорт — сессия, переданная через реле; с inpage-провайдером — это сообщение расширения Chrome. У каждого есть как минимум один пробел доверия: реле можно подменить, страница может быть фишинговым клоном, сообщение можно подделать.

Аутентификация запросов закрывает эти пробелы со стороны кошелька. Прежде чем SSP отрисует экран подтверждения, он проверяет, кто спрашивает и о чём. Источник, заявленный запросом, сверяется с транспортом, который его доставил. Полезная нагрузка проверяется на целостность — кошелёк не подписывает запрос, изменённый при передаче. И запрос сверяется с состоянием сессии, которое кошелёк уже держит, чтобы воспроизведённый запрос из другой сессии не проскользнул с чужим сопряжением.

Ничто из этого не меняет того, что вы видите, когда легитимный dApp просит вас подписать. Экран подтверждения выглядит так же. Меняется то, что путь между dApp и этим экраном теперь имеет ограждения, которые кошелёк обеспечивает сам, вместо того чтобы доверять транспорту в честности о том, для кого он осуществляет доставку.

За ним следует Identity Signing (v1.30.0)

Через неделю v1.30.0 пошёл в обратном направлении. До этого SSP Identity могла подписывать сообщения — строки, доказывающие, что пользователь контролирует ключ. v1.30.0 добавляет возможность подписывать как идентичность: удалённый сервис может выпустить вызов, называющий ожидаемую SSP Identity, и кошелёк возвращает подпись, которая привязывает ответ к этой идентичности так, что сервис может это проверить.

Разница тонкая и несущая. Подпись сообщения доказывает, что ключ что-то контролирует. Подпись идентичности доказывает, что ключ контролирует именованную идентичность — стабильный дескриптор, который сервис уже связал с разрешениями, балансами или подписками. Для сервисов, которым нужно знать не только «есть ли там пользователь», но и «тот же ли это пользователь, что заводил аккаунт», подпись идентичности замыкает круг. v1.30.0 также отполировал обработку всплывающих окон запросов — меньше мерцания, меньше потерянных всплывающих окон, более быстрый возврат фокуса.

Почему это важно для dApps

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

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

Как это сочетается с WalletConnect

WalletConnect открыл дверь к тысячам dApp. v1.29.0 добавил к этой двери замок, а v1.30.0 — звонок. Оба ложатся на одну и ту же поверхность: поток запросов. Аутентификация запросов гарантирует, что запрос, который видит кошелёк, — это тот, который отправил dApp. Подпись идентичности гарантирует, что ответ, который видит dApp, — это тот, что отправил ваш кошелёк, подписанный идентичностью, которую dApp ожидал. Пара превращает сессию WalletConnect из «двух конечных точек, обменивающихся блобами» в «две конечные точки, которые могут доказать друг другу, кто они».

От Identity к Identity-Signing

Исходная функция SSP Identity дала кошельку стабильную поверхность идентичности — производный адрес для обмена сообщениями и доказательств, отдельный от транзакционных адресов, с которых вы тратите. Это было введение. v1.30.0 — продолжение: та же идентичность, теперь пригодная как учётные данные, которые сервис может запросить по имени и проверить на своей стороне.

Так выглядит, когда кошелёк становится примитивом идентичности первого класса, а не просто хранителем ключей. v1.29.0 делает входы заслуживающими доверия; v1.30.0 делает выходы проверяемыми. Большинство пользователей никогда не увидят разницы напрямую. Однако dApps и сервисы, интегрирующиеся с этой поверхностью, обнаружат, что SSP теперь может доказать, кто он есть, и проверить, кто спрашивает — каждый раз.

Поделиться статьёй

Похожие статьи