О dPKI

Распределнная инфрастуктура публичных ключей необходима для достижения следующих свойств в распределенных системах:

• Децентрализация, отсуствие CA или единой точки компроментации/отказа
• Гарантия пожизненной неизменности данных (с поправкой на криптостойкость, про это отдельным постом)
• Гарантия отсутствия цензуры, запрета доступа

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

1) DPKI фреймворк (ION, Sovrin, Veres, Remme?) агрегирует DID документы — от 1 до сотен тысяч
2) Операции записываются в адресуемое хранилище (например IPFS)
3) Агрегированный (через например Multihash) указатель записывается в публичную или приватную цепочку (Bitcoin, Ethereum, Hyperledger, whatever)
4) Любая другая нода (пользователь) мониторит публичную (или приватную) цепочку на предмет обновлений
5) Как только она находит интересующую операцию, парсит согласно правилам протокола и находит значение в изначальном CAS хранилище
6) Для гарантии последовательности изменений в документах и их аутентичности протоколы вроде Sidetree используют логику векторных часов (Lamport timestamps) для создания децентрализованного оракула, отвечающего за детерминированную и линейную последовательность операций (как именно это работает тут: https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

В текущем алгоритме речь идёт об инфраструктурном уровне. Сверху на это должны прицепляться механизмы работы с ключами, их проверки, отзыва и восстановления. В следующих постах расскажу об абсолютно крутейших идеях в этом напралении — social key recovery, CRUK (create, read, update, revoke).