Эрик Чжан завершает трио аутентификации Neo с помощью NEP-33

Соучредитель Neo Эрик Чжан опубликовал NEP-33, третье предложение по усовершенствованию Neo, которое он выдвинул за две недели. Стандарт определяет транспортный механизм на основе URI, который позволяет собственным приложениям вызывать приложения кошелька для аутентификации, завершая трехуровневый стек, который стандартизирует вход пользователей в систему с помощью своего кошелька Neo.

NEP-33 следует за NEP-20, который установил правила криптографической аутентификации, и NEP-21, который определил единый интерфейс для dApps для связи с поставщиками кошельков. Там, где эти два стандарта обрабатывают логику аутентификации и возможности кошелька, NEP-33 обращается к точке входа: как одно приложение передает запрос аутентификации кошельку и получает результат.

Что это дает

До NEP-33 не существовало стандартизированного способа для мобильного или настольного приложения вызвать кошелек Neo для аутентификации.

Каждый кошелек и приложение реализовали свой собственный формат вызова и обратного вызова, создавая фрагментацию. В NEP-33 представлен neoauth://, специальная схема URI, которая предоставляет собственным приложениям универсальную точку входа «Войти с помощью Neo». Операционная система направляет запрос на совместимый кошелек, который возвращает результат через URI обратного вызова.

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

Кроме того, NEP-33 был разработан с учетом прямой совместимости. В комментарии к запросу на GitHub, содержащемуся в предложении, Чжан задал вопрос о том, должны ли существовать отдельные схемы URI для разных версий сети Neo:

Поскольку форматы адресов N3 и N4 одинаковы, различать их нет необходимости. И это всего лишь протокол транспортного уровня. В NEP-20 существует сетевой процесс переговоров.

В проекте схема neoauth:// не зависит от сети, а выбор сети осуществляется на уровне NEP-20.

Как работает НЭП-33

Приложение создает URI запроса, используя схему neoauth://, внедряя полезную нагрузку запроса NEP-20, закодированную в URL-адресе, и идентификатор dApp. Операционная система направляет это в зарегистрированное приложение кошелька, которое может быть общей целью (делегирование выбора кошелька ОС или пользователю) или конкретной реализацией кошелька.

Кошелек декодирует и проверяет полезную нагрузку, отображает данные аутентификации (включая запрашивающий домен) пользователю и требует явного одобрения. Если пользователь одобряет, кошелек генерирует полезную нагрузку ответа NEP-20 и возвращает ее через URI обратного вызова, используя схему dapp://. Если пользователь отклоняет запрос или возникает ошибка, кошелек возвращает структурированный ответ об ошибке через тот же механизм обратного вызова.

Вся проверка аутентификации соответствует криптографическим правилам NEP-20, что означает, что запрашивающее приложение должно проверить возвращенную подпись, а не доверять самому URI обратного вызова в качестве доказательства аутентификации.

NEP-33 не дает нового определения того, что такое аутентификация или как она работает, скорее, он привносит эту возможность в поток взаимодействия между dApps и кошельками.

Модель безопасности

Поскольку пользовательские схемы URI не гарантируют конфиденциальность или идентичность приложения, безопасность NEP-33 полностью зависит от проверки подписи NEP-20.

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

NEP-33 предназначен исключительно для одноразовых потоков аутентификации. Его не следует использовать для подписания транзакций, передачи активов, вызова смарт-контрактов или авторизации на основе сеанса.

Полный анонс можно найти по ссылке ниже: https://x.com/erikzhang/status/2042931327943741471