Данный материал является переводом этой статьи.

В этой статье рассматриваются основные концепции децентрализованной идентификации, эволюция идентификации в Интернете, послойный обзор стека инфраструктуры идентификации web3 и соответствующие разработки примитивов конфиденциальности. Доказательство личности, соответствие требованиям и прикладной уровень будут рассмотрены в этой статье.

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

• Идентификатор: уникальный набор символов или цифр, который идентифицирует субъекта (например, номер паспорта, идентификатор Twitter, идентификатор студента).

• Данные, связанные с этим предметом (например, история путешествий, твиты и подписки, академические достижения)

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

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

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

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

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

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

Основные концепции децентрализованной идентификации

Децентрализованные идентификаторы (DID) и аттестации являются основными строительными блоками децентрализованной идентификации. DID выдаются и хранятся в реестрах поддающихся проверке данных (VDR), которые действуют как автономные «пространства имен», которые не управляются централизованно. В дополнение к блокчейнам в качестве VDR могут выступать децентрализованная инфраструктура хранения и P2P-сети.

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

Данные об идентичностях записываются в виде аттестаций — «утверждений», которые одна идентичность делает о другой (или о себе). Проверка заявлений выполняется с использованием криптографических подписей, которые стали возможными благодаря PKI.

Децентрализованные идентификаторы имеют 4 основных свойства:

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

• Постоянный: навсегда назначается объекту после его создания. (Хотя некоторые DID предназначены для эфемерных идентификаторов)

• Позволяемый: может использоваться для раскрытия дополнительной информации о рассматриваемом объекте.

• Поддающийся проверке. Субъекты могут доказать право собственности на DID или заявления, сделанные в отношении него (проверяемые учетные данные), не полагаясь на третьи стороны, благодаря криптографическим подписям и доказательствам.

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

Консорциум World Wide Web (W3C) — это международное сообщество организаций, сотрудников и общественности, работающих вместе над разработкой веб-стандартов. Спецификация DID W3C определяет 4 основных компонента:

• Схема. Префикс «did» сообщает другим системам, что он взаимодействует с DID, а не с другими типами идентификаторов, такими как URL-адрес, адрес электронной почты или штрих-код продукта.

• Метод DID: указывает другим системам, как интерпретировать идентификатор. На веб-сайте W3C перечислено более 100 методов DID, часто связанных с его собственным VDR и с различными механизмами создания, разрешения, обновления и деактивации идентификаторов.

• Уникальный идентификатор: уникальный идентификатор, специфичный для метода DID. Например, адрес в определенной цепочке блоков.

• Документ DID: 3 приведенные выше части превращаются в документ DID, который содержит способы, с помощью которых объект может аутентифицировать себя, любые атрибуты/заявления, сделанные в отношении объекта, и указатели («конечные точки службы»), где находятся дополнительные данные об объекте.

Влияние криптографии

Хотя инфраструктура открытых ключей (PKI) существует уже давно, криптография ускорила свое внедрение благодаря механизмам стимулирования в сетях токенов. То, что когда-то преимущественно использовалось технологами, заботящимися о конфиденциальности, теперь является необходимым условием для участия в новой экономике. Пользователям необходимо было создавать кошельки для самостоятельного хранения своих активов и взаимодействия с веб-приложениями. Благодаря буму ICO, DeFi лета, мании NFT и токенизированных сообществ в руках пользователей находится больше ключей, чем когда-либо прежде. Наряду с этим появилась динамичная экосистема продуктов и услуг, которая делает управление ключами проще и безопаснее. Crypto технология была идеальным троянским конем для децентрализованной инфраструктуры идентификации и внедрения.

Давайте возьмем кошельки в качестве отправной точки. В то время, как кошельки, по-прежнему, в первую очередь рассматриваются в контексте управления активами в финансовом смысле, токенизация и история сети позволили нам представлять наши интересы (коллекция NFT), работу (Kudos, 101) и мнения (голосования). Потеря закрытых ключей все меньше похожа на потерю денег и больше похожа на потерю паспорта или учетной записи в социальной сети. Криптовалюта стирает грань между тем, чем мы владеем, и тем, кто мы есть.

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

• Как мы идентифицируем и аутентифицируем себя в сетях и экосистемах?

• Как мы можем доказать что-то о себе (репутация, уникальность, соответствие), сохраняя при этом конфиденциальность?

• Как мы предоставляем, управляем и отзываем доступ к нашим данным?

• Как мы взаимодействуем с приложениями в мире, где мы контролируем свою личность и данные?

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

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

Стек идентификации Web3

Блокчейны как реестры поддающихся проверке данных

Распределенный и неизменный характер блокчейнов делает их подходящими для использования в качестве проверяемых реестров данных, на которых можно выдавать DID. И действительно, существуют методы W3C DID для различных общедоступных блокчейнов, таких как:

• Ethereum, где did:ethr:<открытый ключ> представляет учетные записи Ethereum как личность

• Cosmos, где did:cosmos::: представляет собой актив, совместимый с межсетевыми цепочками Cosmos.

• Биткойн, где did:btcr: представляет идентификатор транзакции, закодированный TxRef, со ссылкой на позицию транзакции в блокчейне биткойнов на основе UTXO.

Примечательным является did:pkh: — независимый от реестра, генеративный метод DID, разработанный для взаимодействия между сетями блокчейнов. — это идентификатор учетной записи в соответствии со стандартом CAIP-10 для выражения пары ключей в цепочках.

Fractal — это протокол предоставления и проверки личности, разработанный для приложений, требующих уникальных и различных уровней пользователей, прошедших KYC. После завершения проверки живучести и/или KYC, Fractal DID выдается на соответствующий адрес Ethereum и добавляется в соответствующий список. Реестр DID Fractal — это смарт-контракт на Ethereum, по которому контрагенты могут искать DID Fractal и их уровень проверки.

Kilt, Dock и Sovrin — это блокчейны для конкретных приложений, обеспечивающие суверенную идентичность. На момент написания они в основном использовались предприятиями для выдачи удостоверений и учетных данных конечным пользователям. Для участия в сети узлы должны размещать собственные токены для обработки таких транзакций, как DID/выдача учетных данных, определение схем учетных данных и выполнение обновлений отзыва.

Децентрализованное хранилище данных

Хотя блокчейны общего назначения также могут служить источником данных для неизменяемых пользовательских данных, таких как данные о владении активами и истории транзакций (например, для средств отслеживания портфеля и приложений «Оценка DeFi»), они, вероятно, не подходят для хранения большинства данных о пользователях, которые пишут и регулярно обновление больших объемов информации является дорогостоящей операцией и ставит под угрозу конфиденциальность, поскольку данные видны по умолчанию.

При этом существуют блокчейны для конкретных приложений, такие как Arweave*, которые предназначены для постоянного хранения. Arweave выплачивает вознаграждение за блок и комиссию за транзакции майнерам в обмен на репликацию информации, хранящейся в сети. Майнеры должны предоставить «Proof-of-Access» для добавления новых блоков. Часть сборов также уплачивается в бессрочный фонд, который будет выплачиваться майнерам в будущем, когда расходы на хранение не покрываются инфляцией и сборами.

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

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

IPFS позволяет пользователям хранить и передавать проверяемые данные с контентной адресацией в одноранговой сети. Пользователи могут сохранять нужные им данные на своих собственных узлах IPFS, использовать выделенные группы узлов или использовать сторонние службы «закрепления», такие как Pinata, Infura или web3.storage. Данные существуют в сети до тех пор, пока один узел их хранит и может предоставить другим по запросу. Поверх IPFS находятся криптоэкономические уровни, такие как Filecoin и Crust Network, предназначенные для стимулирования хранения данных для сети путем создания распределенного рынка для долгосрочного хранения данных.

Для информации, позволяющей установить личность (PII), разрешенная IPFS может использоваться для соблюдения права на забвение GDPR / CCPA, поскольку это позволяет пользователям удалять свои данные, хранящиеся в сети. Идентификационный кошелек Nuggets принял этот подход, еще больше децентрализовав его, заставив продавцов и партнеров запускать выделенные узлы.

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

Мутация данных и компонуемость

Блокчейны общего назначения, Arweave и IPFS гарантируют неизменность, полезное свойство для таких данных, как статические изображения NFT и постоянные записи. Однако наше взаимодействие с большинством приложений сегодня постоянно обновляет наши данные. Протоколы Web3, предназначенные для изменяемых данных, были созданы именно для этого, используя нижележащий уровень децентрализованного хранения.

Ceramic — это протокол для децентрализованного изменения и компоновки данных, который работает, беря неизменяемые файлы из IPFS или постоянных сетей хранения данных, таких как Arweave, и превращая их в динамические структуры данных. В Ceramic эти «потоки данных» похожи на собственный изменяемый реестр. Частные данные могут храниться вне сети с их схемой, проиндексированной на Ceramic, прикрепленной к хранилищу данных DID, которое перенаправляется во внешнее частное хранилище.

Когда пользователь обновляет свой профиль в приложении на основе Ceramic, протокол проверяет эти обновления в потоке, чтобы преобразовать его в новое состояние, отслеживая при этом предыдущие изменения состояния. Каждое обновление в Ceramic проверяется с помощью DID, который может сопоставляться с несколькими адресами, что позволяет пользователям обновлять свои данные без серверов.

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

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

ComposeDB on Ceramic — это децентрализованная база данных графов, которая позволяет разработчикам приложений находить, создавать и повторно использовать компонуемые модели данных с помощью GraphQL. Узлы в графе — это либо учетные записи (DID), либо документы (потоки данных). Границы в графе представляют отношения между узлами.

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

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

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

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

Обновления в сети и вне сети обрабатываются смарт-контрактом, который указывает на сеть Tableland с использованием baseURI и tokenURI. В Tableland метаданные NFT можно изменять (с помощью элементов управления доступом), запрашивать (с помощью SQL) и компоновать (с другими таблицами в Tableland).

Подобно тому, как стандарты смарт-контрактов, такие как ERC-20 и ERC-721, предоставили децентрализованным приложениям общий язык для того, как мы создаем и передаем токены, стандарты моделей данных дают приложениям общее понимание таких данных, как профили, репутация, предложения DAO и социальные графы. Благодаря открытым реестрам, доступ в которые имеет любой желающий, эти данные могут повторно использоваться несколькими приложениями.

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

Кошельки
Вообще говоря, кошельки состоят из интерфейса и базовой инфраструктуры для управления ключами, связи (обмена данными между держателем, эмитентом и верификатором), а также представления и проверки претензий.

Стоит различать криптокошельки (MetaMask, Ledger, Coinbase Wallet и т. д.) и кошельки для идентификации. Криптокошельки хранят криптографические ключи, специфичные для сети блокчейн, и предназначены для отправки/получения токенов и подписания транзакций. Идентификационные кошельки хранят идентификационные данные и позволяют пользователям создавать и предъявлять претензии, чтобы они могли представлять идентификационные данные в приложениях и службах.

Примеры идентификационных кошельков включают ONTO, Nuggets и Polygon ID Wallet. Некоторые кошельки для идентификации, такие как Fractal, имеют проверки жизнеспособности и KYC как часть их процесса адаптации, поэтому пользователи могут предъявлять претензии приложениям, которые имеют такие требования. Это гораздо менее распространено для криптокошельков. Идентификационные кошельки также с большей вероятностью будут поддерживать признанные W3C реализации DID, проверяемых учетных данных и DIDComm, а также варианты использования за пределами web3.

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

Аутентификация

Аутентификация подтверждает личность пользователя на основе одного или нескольких факторов аутентификации. Фактором может быть что-то, что принадлежит пользователю (цифровая подпись, удостоверение личности, токен безопасности), что-то, что он знает (пароль, PIN-код, секретный ответ) или биометрические данные (отпечаток пальца, голос, сканирование сетчатки глаза).

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

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

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

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

Sign-In with Ethereum (SIWE) — это стандарт аутентификации, созданный Spruce, ENS и Ethereum Foundation. SIWE стандартизирует формат сообщений (похожий на jwt), чтобы пользователи могли входить в службы с использованием учетной записи на основе блокчейна. Sign-In with X (CAIP-122) основывается на этом, чтобы сделать SIWE ориентированной на Ethereum реализацией SIWx, обобщающей стандарт для работы в разных блокчейнах.

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

В среднесрочной перспективе возможность использовать криптокошельки для входа в децентрализованные приложения и другие сервисы web2 послужит улучшению UX для пользователей web3. Однако это оставляет пользователей открытыми для корреляции и проблем с отслеживанием, которые стали настолько пагубными в web2. Аутентификация через одноранговые DID или самосертифицирующиеся идентификаторы может служить здесь альтернативным решением.

В отличие от «ванильных» DID, описанных выше, одноранговые DID предназначены для использования между 2 или N известными сторонами. Их можно использовать в качестве уникального идентификатора для каждой услуги и/или взаимодействия. Адреса криптокошельков в рамках этой цифровой идентификации могут храниться в VC в качестве доказательства проверки при каждом взаимодействии с продавцом или сервисом.

Авторизация и контроль доступа

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

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

С появлением токенизированных сообществ появились продукты для токенов web3, такие как Collab.Land, Guild и Tokenproof. Основное использование этих инструментов было для контроля доступа к каналам Discord только для участников и более детального доступа на основе ролей и репутации. Вместо того, чтобы раздавать доступ вручную, сообщества могут программно предоставлять доступ на основе токенов, действий в сети или социальной проверки.

Lit* — это децентрализованный протокол управления ключами и контроля доступа, который использует технологию MPC для распределения «долей» закрытого ключа между узлами сети Lit. Пары открытый/закрытый ключ представлены PKP (Programmable Key Pair) NFT, владелец которого является единственным контролером пары ключей. Затем владелец PKP может инициировать сеть для объединения общих ключей для расшифровки файла или подписи сообщений от их имени при выполнении произвольно определенных условий.

В контексте контроля доступа Lit позволяет пользователям определять условия в сети, которые предоставляют доступ к ресурсам вне сети. Например, DAO может загрузить файл в Arweave или AWS, зашифровать его с помощью Lit и определить набор условий (например, владение NFT). Подходящие кошельки подписывают и передают сообщение на узлы протокола, которые проверяют цепочку блоков, чтобы убедиться, что подписывающая сторона соответствует условиям, и объединяют доли ключей, чтобы подписывающая сторона могла расшифровать файл, если это так. Эту же инфраструктуру можно использовать для разблокировки возможностей web2, таких как скидки Shopify, комнаты Zoom с токенами и пространства Gathertown, прямые трансляции и доступ к Google Диску.

Kepler организует данные вокруг контролируемых пользователями хранилищ данных («Орбиты»), которые представляют собой список назначенных хостов для данных в виде смарт-контракта, которым могут управлять только их ключи. Эти хранилища данных могут управляться доверенными сторонами, механизмами консенсуса между хостами, владельцами ресурсов и действительностью разрешений. Любой, кто использует SIWE, может немедленно использовать частное хранилище данных для хранения своих предпочтений, цифровых учетных данных и личных файлов. Благодаря поддержке «Принеси собственное хранилище» для нескольких серверных хранилищ пользователи могут самостоятельно размещать или использовать размещенные версии.

Некоторые примеры того, как приложения могут использовать комбинацию ранее упомянутых строительных блоков:

• Orbis — это приложение для социальных сетей («web3 Twitter/Discord»), которое использует Ceramic для хранения и обновления данных, DM сначала шифруются с помощью Lit перед сохранением.

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

• Kepler может использовать керамические документы в качестве маяка для маршрута к частному хранилищу

• Создайте Lit PKP, который «владеет» потоком Ceramic для приложения, и предоставьте Lit Actions (код в IPFS) возможность подписывать и обновлять базу данных при выполнении произвольных условий.

CACAO — это стандарт для представления независимой от цепочки возможности объекта (OCAP), созданный с использованием Sign-in-With X. Он определяет способ записи результата операции подписи SIWx в виде возможности объекта на основе IPLD (OCAP), создавая не только квитанция о событии аутентификации, но также компонуемую и воспроизводимую квитанцию об авторизации для проверяемых авторизаций.

Методы авторизации позволяют пользователям предоставлять приложениям детализированную, ограниченную и поддающуюся проверке возможность просматривать/обновлять свои данные. Кроме того, это может быть основано на сеансе, так что им не нужно подписывать сообщения при каждом обновлении, а вместо этого они имеют много взаимодействий в приложении и подписывают один раз в конце сеанса.

Аттестации и полномочия

Здесь мы достигаем вершины стека инфраструктуры децентрализованной идентификации, как показано здесь.

Немного терминологии:

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

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

Подтверждаемые учетные данные (VC) — это стандартная модель данных и формат представления для криптографически проверяемых цифровых учетных данных, как определено в спецификации W3C поддающихся проверке учетных данных:

• Эмитенты — это стороны, выдающие удостоверение личности (например, университет).

• Владельцы владеют учетными данными (например, студент)

• Верификаторы проверяют учетные данные (например, потенциального работодателя)

• Верифицируемые презентации — это когда пользователи делятся своими данными с третьими лицами, которые могут проверить, действительно ли учетные данные были подписаны выдавшей стороной.

Обратите внимание, что термины «Эмитент», «Держатель» и «Верификатор» здесь относительные. У каждого есть свой DID и свой набор учетных данных.

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

Несмотря на то, что не все проекты, нативные для веб-бейджинга и доказательства X, соответствуют стандартам W3C VC, мы можем провести параллели с системой, описанной выше.

• Самый простой пример — непередаваемые NFT, которые могут чеканиться только кошельками, которые завершили некоторую деятельность в сети. Поскольку вся история транзакций находится в сети, ее можно проверить и защитить от несанкционированного доступа. DegenScore количественно оценивает ваше “дегенство”, объединяя ваши взаимодействия с протоколами DeFi и выводит оценку с использованием правил, написанных на смарт-контракте. Вы можете отчеканить это и рассматривать как «учетные данные DeFi», хранящиеся в вашем криптокошельке. Если был Degen DAO, ограниченный теми, кто набрал определенный балл, вы можете представить этот NFT DAO, протокол токен-гейта может подтвердить, что вы его держите, и вперед — Proof of Degen.

• POAP* подтверждают, что вы посетили определенное мероприятие или встретили кого-то. IRL — Proof of Attendance / Proof of Encounter

• Otterspace позволяет DAO решать, что представляет собой значимая работа, и выдает за нее своим членам значок ntNFT. Proved требует от DAO «подписать» заявку, прежде чем разрешить своим членам чеканить для нее специальные значки NFT для DAO — Proof of Contribution

• 101 выпускает ntNFT после того, как учащийся проходит тест в конце своих онлайн-курсов — Proof of Learning

• Kleoverse выдает пользователям значки компетенций Typescript, Rust или Solidity на основе данных Github — Proof of Skill

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

Здесь возникает 2 вопроса: какие из этих точек учетных данных имеют смысл и как их агрегировать для репутации?

Orange Protocol предлагает одно решение этой проблемы: объединить эти точки данных в четко определенные схемы с помощью поставщиков моделей. В Orange MPs — это, как правило, платформы, в системах которых есть меры для оценки репутации. «Поставщики данных» позволяют использовать свои данные в качестве входных данных для моделей, разработанных поставщиками моделей. Затем депутаты добавляют метод расчета и присвоения маркеров репутации различным объектам и делают эти модели доступными для использования другими. Dapps могут курировать и подключать эти модели репутации для своего варианта использования.

На данный момент Aave, Gitcoin, Snapshot, DAOHaus и другие предоставили свои данные в Orange. Эти данные были смоделированы ими и другими проектами, такими как Dework, TalentDAO и Crypto Sapiens, чтобы предоставить участникам ntNFT, которые открывают широкий спектр возможностей от улучшенного разрешения Discord с использованием CollabLand и Guild до взвешенного по репутации управления в Snapshot.

Конфиденциальность

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

Гарантии конфиденциальности помогают нам избежать отрицательных внешних эффектов, возникающих в результате создания заслуживающих доверия заявлений с использованием полностью прозрачных данных. Без этих гарантий третьи стороны могут инициировать взаимодействие, выходящее за рамки, не связанное с исходной транзакцией (например, реклама, домогательства). Используя криптографию и технологию zk, мы можем создавать системы идентификации, в которых взаимодействия и обмен данными «изолированы» в четко определенных контекстно-зависимых областях.

«Ванильные» проверяемые учетные данные часто бывают в формате JSON-JWT или JSON-LD, каждый из которых имеет внешние или встроенные доказательства (цифровые подписи), которые делают их защищенными от несанкционированного доступа и поддающимися проверке, поскольку они созданы Эмитентом.

Zk-доказательства и новые схемы подписи улучшают VC W3C с такими свойствами сохранения конфиденциальности, как:

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

• Выборочное раскрытие. Делитесь только необходимыми атрибутами из VC и прячьте остальные. Как для учетных данных JSON-JWT, так и для учетных данных JSON-LD LD-Signature требуется, чтобы владелец делился всеми учетными данными с верификаторами — «частичного» общего доступа не существует.

• Составные доказательства: объединяйте атрибуты из нескольких VC в одно доказательство, не обращаясь к издателю и не создавая новый VC.

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

Одним из многообещающих подходов является схема подписи BBS, первоначально предложенная MATTR в 2020 году. Это предложение позволяет использовать подписи BBS с форматом JSON-LD, обычно используемым венчурными капиталистами. Владелец может выборочно раскрывать заявления из первоначально подписанных учетных данных. Доказательства, сгенерированные схемой, являются доказательствами подписи с нулевым разглашением, что означает, что верификатор не может определить, какая подпись использовалась для создания доказательства, что устраняет общий источник корреляции.

Iden3 — это собственный протокол идентификации zk, который предлагает программируемую структуру zk и библиотеки с открытым исходным кодом для примитивов zk-identity, аутентификации и генерации доказательств для утверждений. Протокол генерирует пары ключей для каждого удостоверения с использованием эллиптической кривой Baby Jubjub, которая предназначена для эффективной работы с zk-SNARK, используемыми для подтверждения права собственности на удостоверение и требований с сохранением конфиденциальности. В настоящее время PolygonID использует протокол для своего кошелька идентификации.

Прикладной zkp — это активная область исследований и экспериментов, которая за последние несколько лет вызвала большой интерес у криптосообщества. В web3 мы уже видим его использование в таких приложениях, как:

• Частные аирдропы: Stealthdrop

• Сохраняющие конфиденциальность, но заслуживающие доверия аттестации: Sismo (право собственности), Semaphore (членство)

• Анонимные сообщения: heyanon

• Анонимный опрос/голосование: Melo

Вывод

Некоторые общие выводы из этого исследования.

• Подобно тому, как криптография стала катализатором разработки и внедрения DPKI, компонуемая репутация, которая предоставляет привилегии доступа в Интернете/IRL, станет катализатором для децентрализованной инфраструктуры идентификации. Протоколы выдачи учетных данных (доказательство х) в настоящее время раздроблены по вариантам использования и сетям блокчейна. В 2023 году мы увидим, как уровень агрегации для них (например, профилей) станет зрелым и получит признание в качестве объединяющего интерфейса, особенно если его можно будет использовать для разблокировки возможностей, выходящих за рамки криптографии, таких как доступ к событиям или скидки в электронной коммерции.

• Управление ключами остается точкой трения, уязвимой для отдельных точек отказа. Неуклюжий опыт для большинства криптонативов и совершенно недоступный для большинства потребителей. Федеративная идентификация была усовершенствованием UX парадигмы Web 1.0, позволяющей использовать единый вход вместо имен пользователей и паролей для каждого приложения. Хотя UX аутентификации web3 улучшается, он по-прежнему предлагает худший UX, требующий начальных фраз, и предлагает ограниченное обращение за помощью в случае потери ключей. Мы увидим улучшение здесь по мере того, как такие вещи, как технология MPC, будут развиваться и набирать обороты среди отдельных лиц и организаций.

• Крипто инфраструктура встречает пользователей там, где они находятся, в web2. Примитивы Web3 начинают интегрироваться с приложениями и сервисами Web2, чтобы донести до масс децентрализованную идентификацию, например, интеграция Collab.Land с Nuggets, позволяющая пользователям Reddit укреплять свою репутацию VC для разблокировки доступа. Промежуточное ПО аутентификации и авторизации Auth0 интегрировало SIWE в качестве поставщика удостоверений, их база из 2000 корпоративных клиентов теперь может предлагать вход в кошелек в дополнение к SSO.

• Механика курирования должна быть проверена по мере демократизации данных. Подобно тому, как протокол индексации The Graph использует сеть кураторов и делегаторов, чтобы сигнализировать о наиболее полезных подграфах (API для сетевых данных), модели данных вокруг пользователя и репутации в таких протоколах, как Ceramic и Orange, потребуют времени и участия сообщества, чтобы созреть.

• Соображения конфиденциальности. Проекты должны тщательно учитывать последствия публичного или постоянного хранения при выборе стека. «Чистые» ntNFT с общедоступными данными, вероятно, будут подходить для ограниченного набора вариантов использования (например, абстракция для некоторой активности в сети) по сравнению с комбинацией сохраняющих конфиденциальность VC, эфемерных и одноранговых DID и ZKP вкл / выкл. - активность в сети, которая предлагает такие функции, как выборочное раскрытие, чередование ключей, антикорреляцию и возможность отзыва.

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

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

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

От автора:

If you are building in this realm or have additional thoughts on the topic, would love to hear from you.

*denotes 1kx portfolio companies

Many thanks to Joel Thorstensson, David Sneider, Humpty Calderon, Seema Khinda Johnson, Alastair Johnson, the PolygonID team, pet3rpan, Accel XR, Robert Koschig, and Dmitriy Berenzon for reviewing drafts of this.