Охватывает ли децентрализованные идентификаторы децентрализованную PKI

Я узнаю о децентрализованных идентификаторах (DID). Спецификация DIDs говорит, что:

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

Насколько я понимаю, две концепции (DID и DPKI) имеют некоторые сходства. Например, оба требуют децентрализованного реестра, такого как блокчейн (или DLT). Также оба говорят, что открытые ключи должны контролироваться субъектом. Так,

Мой вопрос: Децентрализованные Идентификаторы покрывают Децентрализованную PKI. Другими словами, в чем разница или символы между DID и DPKI?

2 ответа

В спецификации DID:

Поскольку DID находятся в распределенном регистре, каждый объект может выступать в качестве своего собственного корневого органа - архитектуры, называемой DPKI (децентрализованная PKI).

DPKI предписывает, как ключи должны храниться, считываться, получать доступ, извлекаться конкретно только на уровне инфраструктуры управления ключами.

Насколько мне известно, пока не ведется работа по стандартизации dpki.

Вот несколько ресурсов по этому вопросу, которые могут оказаться полезными для вас.

DID в DPKI (децентрализованная инфраструктура открытых ключей)

Этот документ призван служить отправной точкой для соединения двух миров DPKI (появившегося в первом RWOT) с DID (появившегося во втором RWOT).

Протокол Sidetree: масштабируемый DPKI для децентрализованной идентификации

Протокол Sidetree сам по себе не является методом DID, он представляет собой композицию компонентов уровня кода, которые включают детерминированную логику обработки, абстракцию хранилища с адресацией содержимого и процедуры проверки состояния, которые могут быть развернуты поверх децентрализованных систем реестра уровня 1 (например, общедоступных блокчейнов). для создания неразрешенных сетей DID уровня 2. Протокол можно использовать для создания отдельных сетей L2 DID в разных цепочках путем объединения его основных компонентов с адаптером для конкретной цепочки, который обрабатывает чтение и запись в базовый L1. Почти весь код реализации протокола Sidetree остается неизменным независимо от целевой системы L1, к которой он применяется.

Я думаю, что реальный ответ может заключаться в том, что акцент сместился с DPKI на DKMS.

Децентрализованное управление ключами

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

В этом каталоге я нахожу DKMS Design and Architecture V3 на основе NIST SP 800-130.

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

Еще одним важным достижением в этой области является KERI (Инфраструктура приема ключевых событий ) .

Кери Дизайн

Первичная операция управления ключами — ротация ключей (передача) с использованием новой схемы предварительной ротации ключей. Дизайн был основан на двух основных модальностях доверия: прямом (один к одному) режиме и косвенном (один к любому) режиме. Косвенный режим зависит от засвидетельствованных журналов получения ключевых событий (KERL) в качестве вторичного корня доверия для проверки событий. Это приводит к аббревиатуре KERI для ключевой инфраструктуры приема событий. В прямом режиме контроллер идентификации устанавливает управление посредством проверенных подписей управляющей пары ключей. Косвенный режим расширяет эту доверительную основу с помощью журналов регистрации ключевых событий (KERL) для проверки событий. Гарантии безопасности и подотчетности косвенного режима обеспечиваются алгоритмом соглашения KA2CE или KERI для установления контроля среди набора свидетелей.

Подход KA2CE может быть гораздо более производительным и масштабируемым, чем более сложные подходы, которые зависят от распределенного согласованного регистра общего порядка. Тем не менее, KERI может использовать распределенный реестр консенсуса, когда другие соображения делают его лучшим выбором. Подход KERI к DKMI допускает более детальную композицию. Более того, поскольку KERI является потоковой передачей событий, он позволяет DKMI работать синхронно с приложениями потоковой передачи событий данных, такими как Web 3.0, IoT и другими, где производительность и масштабируемость более важны. Базовый механизм KERI не зависит от идентификатора. Это делает KERI кандидатом на роль универсального портативного DKMI.

История открытых стандартов SSI — Драммонд Рид/Эверним — Вебинар 1
У этого есть некоторая предыстория ^^^

Другие вопросы по тегам