Традиционните системи за идентичност спират на организационните граници. Ето какво ги преодолява.

Стандартните инструменти за идентичност са създадени за отделни организации. Междуорганизационното доверие в мащаб изисква различна основа — изборът на швейцарското здравеопазване.

Обсъдете тази архитектура за Вашата организация — без ангажимент

Четири структурни ограничения на стандартните инструменти за самоличност

OAuth (Open Authorization) и инфраструктурата за публични ключове (PKI) са отлични инструменти — в границите на една организация. Това не са недостатъци. Това са архитектурни ограничения, които стават видими, когато доверието трябва да обхване множество организации.

Доверие в токени

Ограничение на OAuth / PKI

На OAuth токените се вярва в рамките на границите на техния издател. При комуникация между организации тази граница се разрушава — получаващата организация няма начин да верифицира правомощието на издаващата организация.

Решение с DKMS / Verimesh

DKMS установява криптографска идентичност, която е самосертифицираща — идентичността на всяка организация може да бъде проверена от всяка друга организация без зависимост от общ сертифициращ орган.

Гранулираност на достъпа

Ограничение на OAuth / PKI

OAuth обхватите са груби — предназначени за разрешения на ниво приложение. Ресурсно-точното съгласие през организационни граници изисква различен модел.

Решение с DKMS / Verimesh

Policy-Engine на Verimesh (Open Policy Agent, OPA) позволява програмируем, гранулиран контрол на достъпа, който работи през организационните граници на доверие.

Проверимост

Ограничение на OAuth / PKI

OAuth регистрите са специфични за организацията. Междуорганизационните одитни следи — кой какво е достъпил, кога, упълномощен от кого — изискват криптографска връзка, която OAuth не предоставя.

Решение с DKMS / Verimesh

KERI (Key Event Receipt Infrastructure) осигурява защитени от манипулация одитни следи. Всяко събитие за идентичност е криптографски свързано и независимо верифицируемо, създавайки междуорганизационна проверимост.

Архитектура на доверието

Ограничение на OAuth / PKI

OAuth предполага централен орган — доставчик на идентичност, на когото всички се доверяват. Разпределеното институционално доверие между суверенни организации не може да зависи от един-единствен орган.

Решение с DKMS / Verimesh

DKMS позволява суверенно управление на идентичността — всяка организация контролира собствените си криптографски корени. Доверието се установява двустранно, а не се делегира на централен координатор.

OAuth за локални токени, DKMS за мащабируемо институционално доверие

KERI identity infrastructure architecture diagram showing key event log, witnesses, watchers, and cross-organizational trust establishment
KERI инфраструктура за самоличност — самосертифициращи се идентификатори, разписки за ключови събития и двустранно доверие без централен орган

Това е еволюция, не замяна. OAuth (Open Authorization) е правилният инструмент за локална автентикация в рамките на границите на една организация. DKMS (Decentralized Key Management System) е правилният инструмент за институционално доверие в мащаб — между суверенни организации, които нямат общ доставчик на идентичност. Verimesh комбинира и двете, използвайки всяко там, където е подходящият инструмент.

В съответствие с националната програма за eID на Швейцария

Swiyu е националната швейцарска програма за електронна самоличност, която в момента се разработва. Тя е изградена върху същия модел на Self-Sovereign Identity (SSI) и децентрализирано доверие, залегнал в основата на Verimesh и SEAL. Това не е съвпадение — същите архитектурни принципи, които решават институционалното доверие в мащабна експлоатация, сега се възприемат на национално ниво.

Vereign участва в консултационния процес по Swiyu от най-ранните му етапи. Georg Greve бе член на Swiyu Technical Advisory Council, допринасяйки с практически опит от внедряването на DKMS в експлоатационен мащаб в швейцарското здравеопазване. Това пряко участие гарантира, че архитектурата на Vereign остава съобразена с развиващата се регулаторна и идентификационна инфраструктура на Швейцария.

За организации, внедряващи Verimesh днес, съобразяването със Swiyu означава, че инфраструктурата им на доверие е подготвена за бъдещето по отношение на регулаторната посока на Швейцария. Архитектурните решения са съвместими — организациите не изграждат само за днешните изисквания, а за средата на доверие, която Швейцария създава.

Verimesh реализира тази архитектура

Verimesh (бившият проект Stargate) е експлоатационната реализация на описаната по-горе архитектура на доверието, базирана на DKMS. Комбинира OAuth за локално удостоверяване с KERI-закотвен DKMS за междуорганизационно доверие, програмируема машина за политики на базата на OPA, семантична оперативна съвместимост чрез Overlays Capture Architecture (OCA) и проверима комуникация чрез SEAL.

SEAL, компонентът за проверима комуникация на Verimesh, вече обработва над 800 000 проверени съобщения месечно в швейцарското здравеопазване. Пълното внедряване на Verimesh се осъществява през 2026 г. — избрано от швейцарското здравеопазване като бъдеща инфраструктура на доверието.

Разгледайте Verimesh

Един корен — от приложението чак до кабела

Мрежата на Verimesh работи върху WireGuard, а ключът на тунела споделя същия корен като самоличността на приложението. Curve25519 ключовете за тунела на всяка организация се извличат от нейния собствен материал за Decentralized Key Management (DKMS) — никой централен орган не ги издава и няма пролука между самоличността на мрежово ниво и тази на ниво приложение. Смяната на ключове се координира с DKMS (предварителната ротация е изградена върху KERI), а всяко установяване на тунел е проверимо спрямо Key Event Log-а. Никой посредник не притежава потока от данни.

Безшумен по замисъл

Неудостоверените пакети не получават отговор. Мрежата е невидима за сканиране на портове — няма публична повърхност за атака, която да бъде сондирана.

Около 4 000 реда, които можете да прочетете

WireGuard е около 4 000 реда код срещу около 100 000 за OpenVPN и 400 000 за IPsec. Проверимостта сама по себе си е свойство за сигурност.

Без преговори, без понижаване

Фиксирани съвременни примитиви — Curve25519, ChaCha20-Poly1305, BLAKE2s, ръкостискането Noise_IKpsk2. Перфектна права секретност с подновяване на ключовете на около две минути и скриване на самоличността са вградени, а не конфигурирани.

Суверенитет до самия кабел

Open Source от край до край, самостоятелно хостван, без SaaS контролна равнина по пътя. Суверенитетът се простира от приложението чак до самия транспорт.

Изпитана, доказана инфраструктура

В основното ядро на Linux от 2020 г. — същият протокол, който препоръчват доставчици на сигурност като Palo Alto Networks. Той носи внедряването на Verimesh с HIN днес.

Готов за квантовата миграция

Pre-shared-key слоят на WireGuard вече предпазва днешния трафик от атаки от типа „съхрани сега, дешифрирай по-късно“. А тъй като ключовете за тунела се извличат от DKMS, преминаването към post-quantum алгоритми е рутинна key rotation върху съществуващия Key Event Log — а не еднократна подмяна на всички ключове наведнъж.

Вижте пълния жизнен цикъл на връзката

Прилагането на съгласието е основното предназначение на DKMS

Член 71(8) от EHDS създава структурно ограничение, което никой централен орган не може да изпълни: когато дадено лице оттегли съгласието си за вторична употреба, това оттегляне трябва да достигне до всяка институция, която притежава или е извлякла данни от оригиналния източник. Никой certificate authority не може да ко-подпише оттеглянето; никой identity provider не може да каскадира отмяната. Това ограничение е архитектурно несъвместимо с централизирана идентичност.

DKMS удовлетворява пет инварианта, изисквани от член 71 на EHDS: идентификатори, обвързани с лицето, които оцеляват при повторна регистрация; верифицируеми, времево-маркирани записи за оттегляне, закрепени в Key Event Log; обратимост без повторна идентификация; cross-controller разпространение без двустранни споразумения между всяка двойка институции; и невъзможност за свързване на записа за съгласие с данните, които покрива.

След като данните са разкрити — споделени в болнична мрежа, изследователски консорциум или верига от платци — последващото оттегляне на съгласието трябва да достигне до всеки downstream контролер. DKMS key event log-овете разпространяват отмяната криптографски: KEL-ът на всеки контролер е append-only и удостоверен, така че отмяна, добавена на личния edge, става верифицируема при всяка институция, която притежава производен запис.

Прочетете тезата за архитектурата на съгласието

Доказано в швейцарското здравеопазване — избрано за внедряване в национален мащаб

HIN — Health Info Net — е швейцарската мрежа за здравна информация, свързваща болници, общопрактикуващи лекари и специалисти отвъд кантоналните граници. SEAL, компонентът за проверима комуникация, изграден върху тази архитектура на доверието, вече обработва над 800 000 проверени съобщения месечно. Пълното внедряване на Verimesh със структуриран обмен на данни се осъществява през 2026 г.

HIN — Health Info Net

800 000+

проверени съобщения месечно

850+

шлюза в швейцарското здравеопазване

30 000+

лекарски кабинети и здравни заведения

Trust архитектура — често задавани въпроси

Какво е DKMS?
DKMS (Decentralised Key Management) е категорията identity инфраструктура, в която криптографският trust е закрепен на организационния край, а не в централен certificate authority. Всяка организация контролира собствения си key material и собствения си append-only Key Event Log (KEL). Vereign е co-founder на DKMS Alliance с цел формализиране на DKMS като категория наред с PKI и OAuth.
По какво DKMS е различен от PKI?
PKI закрепва trust в централни Certificate Authority-та — една компрометирана CA засяга всеки subject, който е подписала. DKMS закрепва trust в собствения Key Event Log на всяка организация: отказът остава ограничен до един controller, key rotation-ът е native и атомарен чрез pre-rotation commitments, а cross-jurisdiction trust-ът не изисква CA-to-CA договори за признаване. DKMS е PKI в edge-а, без single point of failure.
DKMS замества ли OAuth?
Не. OAuth е правилното решение за локални token flows в рамките на една организация и трябва да продължи да се използва там. DKMS решава проблем, за който OAuth никога не е бил проектиран: установяване на verifiable trust между организации без споделен посредник. Двете са допълващи се — OAuth за локални token-и, DKMS за мащабируем институционален trust.
DKMS post-quantum ready ли е?
Да. DKMS третира key rotation като first-class операция. Когато са необходими post-quantum алгоритми, миграцията се превръща в рутинна key rotation върху съществуващия Key Event Log, вместо в еднократно преиздаване на сертификати. Pre-rotation свойството на KERI означава, че следващият ключ може да бъде произволен алгоритъм, към който controller-ът се обвързва — включително post-quantum схеми — без да се прекъсват съществуващите trust relationships.
Кой поддържа DKMS?
DKMS е отворена спецификация. DKMS Alliance — co-founded от Vereign — координира спецификацията. Референтната имплементация на KERI (протоколът в основата на DKMS) се поддържа като open source от по-широката KERI общност. Verimesh и SEAL на Vereign са AGPLv3+ имплементации на DKMS слоя, внедрени в продукция в швейцарското здравеопазване.
DKMS изисква ли блокчейн?
Не. DKMS използва hash-свързани Key Event Log-ове (KEL) за append-only интегритет, но няма consensus слой, няма token, няма distributed ledger. Решението да се избегне блокчейн е целенасочено — регулираната инфраструктура изисква детерминистична верификация, не вероятностна финалност.

Резервирайте архитектурен преглед — картирайте Вашите граници на доверие.

Тази архитектура е внедрена в швейцарското здравеопазване в национален мащаб. Независимо дали оценявате алтернативи на централизираната самоличност или планирате междуорганизационен обмен на данни, ще го картираме за Вашата среда в 30-минутен разговор.

Резервирайте архитектурен преглед
Швейцарска защита на данните GDPR съвместимост Open Source AGPLv3+ Швейцарски хостинг
Вижте как архитектурата работи стъпка по стъпка