От DNS заявка до верифициран обмен на данни, за милисекунди.
Verimesh трансформира имейл инфраструктурата от зависима от доверие към верифицирана по доверие. Всеки обмен на съобщения между организации разрешава криптографска идентичност, установява съгласие по политики и създава одитируема следа, без допълнително натоварване на работните процеси или промени в начина на работа на крайните потребители.
Резервирайте 30-минутен архитектурен прегледНастоящите системи за доверие принуждават организациите да зависят от централни органи за всяка проверка на самоличност и всеки обмен на данни. Архитектурата на Vereign елиминира тези зависимости, като позволява на всяка организация да контролира собствената си криптографска идентичност и да верифицира другите директно. Ето как работи на практика: от управлението на ключове до верифицирания обмен на данни.
Какво се случва, когато изпратите съобщение
Следната 7-стъпална последователност е пътят на всяко Verimesh-активирано съобщение: от момента, в който DNS клиентът ви изпраща заявка, до момента, в който данните пристигат верифицирани и одитирани на местоназначението.
Стъпка 1: DNS прокси прихваща заявката
Когато приложението ви разрешава домейна на насрещна страна (напр. bolnica-b.bg), Verimesh DNS проксито прихваща заявката преди да достигне до upstream резолвера ви. Това е входната точка: не се изискват промени в приложния код. Проксито работи прозрачно на мрежово ниво.
Стъпка 2: Identity Agent проверява статуса на насрещната страна
Identity Agent-ът прави заявка към публикувания от Verimesh идентификационен запис на насрещната страна. Два изхода: насрещната страна е Verimesh-съвместима (продължаваме с пълна криптографска верификация) или не е (стандартна доставка, съобщението се маркира като неверифицирано). Така Verimesh постига обратна съвместимост: съобщенията към не-Verimesh партньори никога не се блокират.
Стъпка 3: WireGuard тунел, установен с DKMS-деривирани ключове
Ако насрещната страна е Verimesh-съвместима, се установява WireGuard VPN тунел с ключове, деривирани от DKMS идентификационните записи на двете организации. Тези ключове не са издадени от централен сертификационен орган: те са деривирани от собствения KERI key event лог на всяка организация. Тунелът е двустранен: всяка страна е независимо автентикирана пред другата.
Стъпка 4: Policy Engine оценява съгласието
Преди каквото и да е движение на данни, policy engine-ът на Verimesh (Open Policy Agent, OPA) оценява дали този обмен на данни е разрешен по политиките на двете страни. За здравни данни FHIR Resolver-ът проверява съгласието на ниво ресурс: пациентски съгласия, организационни разрешения и секторни наредби (EHDS, швейцарски DSG) се оценяват в реално време. Данни, неразрешени от политиките, не се преместват. Същата проверка на политиките обхваща и делегирания обхват: получаващата страна може да потвърди, че дадено лице, роля или агент действа в рамките на правомощията, предоставени от организацията му, проверено спрямо собствената верига от credentials на тази организация, а не спрямо централен регистър.
FHIR-over-Verimesh е архитектурно решение: production deployment-ът зависи от onboarding-а на болниците; най-ранната реалистична дата е края на 2026 г.
Прочетете защо тази архитектура е необходима, а не само по-добра →
Стъпка 5: Токенът се превежда локално
Съществуващите ви OAuth токени и X.509 сертификати остават валидни. Compatibility bridge-ът на Verimesh превежда KERI-закотвените credentials в JWT или X.509 формат на страната на получателя, локално, без да се свързва с външен орган. Вашата идентификационна инфраструктура не се променя. Verimesh я разширява за работа отвъд организационните граници.
Стъпка 6: Обмен на данни по криптирана mesh мрежа
С потвърдено съгласие по политики и установен криптиран WireGuard тунел, обменът на данни протича. SEAL (Secure Edge Application Layer) обвива всяко съобщение с верифицируем слой за автентичност: приемащата организация може да докаже кой е изпратил данните, кога са изпратени и че не са модифицирани при транзита. Това заменя зависимостта на S/MIME от трети сертификационни органи с двустранна DKMS-деривирана верификация.
Стъпка 7: Одитна следа, записана в KEL/TEL
Всеки обмен създава запис в KERI Key Event Log (KEL) и Transaction Event Log (TEL). Тези логове правят всяка манипулация откриваема и са независимо верифицируеми от всяка страна, не само от централен лог сървър. За регулирани сектори това означава криптографски надеждни, между-организационни одитни следи, достъпни без централизирана инфраструктура.
Пет слоя на инфраструктурата за доверие
Trust stack-ът на Verimesh е проектиран на слоеве. Всеки слой прави едно нещо добре и предава чисто на следващия. Съществуващата инфраструктура се свързва към compatibility слоя: нищо не се изтегля.
Какво остава. Какво се променя.
Verimesh не е проект за замяна. Той е разширение на инфраструктурата, която вече експлоатирате. Таблицата по-долу показва какво запазвате и какво добавя Verimesh.
443 нарушения на GDPR, докладвани ежедневно в Европа, с кумулативни глоби над 1,2 милиарда EUR (DLA Piper GDPR Fines and Data Breach Survey)
Какво остава
- ✓OAuth 2.0 / OIDC: продължава да обработва вътрешна автентикация и локално издаване на токени. Не се изискват промени.
- ✓X.509 сертификати: остават валидни. KERI-към-X.509 bridge-ът превежда на границата без да засяга вашата PKI.
- ✓JWT: форматът на токена ви е непроменен. Verimesh произвежда KERI-закотвени верифицируеми credentials, които се превеждат в JWT на страната на получателя.
- ✓SMTP / DKIM / DMARC: имейл рутирането и анти-спам инфраструктурата остават на място. SEAL добавя верифицируем слой за автентичност над DKIM, а не вместо него.
- ✓Съществуващи работни процеси: крайните потребители изпращат имейли както преди. Верификацията на доверието е невидима за тях.
Какво се променя
- →Зависимост от централизиран сертификационен орган: заменена от двустранна DKMS-закотвена деривация на ключове. Никоя трета страна не може да отнеме комуникационната способност на вашата организация.
- →Имейл с доверие при първо използване: заменен от криптографски верифицирана организационна идентичност при всеки обмен. Фишинг атаките и представянето за друг субект са структурно предотвратени.
- →Ръчни работни процеси за съгласие: заменени от оценявано от policy engine съгласие (OPA). Споразуменията за обмен на данни са машинно-четими и се прилагат на инфраструктурно ниво.
- →Фрагментирани одитни следи: заменени от криптографски свързани KEL/TEL записи, независимо верифицируеми отвъд организационните граници.
Други опитаха децентрализирана идентичност. Какво е различното тук?
Това е правилният въпрос. Три добре финансирани проекта не успяха да доставят децентрализирана идентичност в мащабна експлоатация:
- Sovrin: Фондация Sovrin остана без оперативен капитал през 2023 г. Нейният Hyperledger Indy blockchain изискваше непрекъсната координация на validator нодове и финансирана фондация. Провалът не беше технически, беше в управлението и икономиката: blockchain зависимостта създаде координационен проблем, изискващ централизирано управление.
- uPort: Проектът за идентичност на ConsenSys беше преименуван на Serto, след което напусна изцяло областта на идентичността. uPort беше изграден върху Ethereum, което означаваше газови такси и on-chain транзакционна латентност за всяка операция. Управлението на идентичността в производствен мащаб не е икономически жизнеспособно на публичен blockchain.
- Jolocom: Отказа се от идентификационна инфраструктура след неуспех да постигне производствена адаптация. Общият модел на провал: зависимост от blockchain инфраструктура, която не може да мащабира икономически.
KERI е структурно различен. Няма blockchain зависимост. Key event-ите са закотвени в append-only логове, поддържани независимо от всеки контролер: без споделен ledger, без газови такси, без управление от фондация. Мрежата не се нуждае от централен координатор, защото доверието се установява двустранно.
Институционалната валидация: GLEIF (Global Legal Entity Identifier Foundation) управлява глобалната LEI система за финансови институции в 180 страни. GLEIF избра KERI за системата vLEI (verifiable Legal Entity Identifier). Това не е proof-of-concept. Това е производствена инфраструктура, верифицираща идентичността на финансови институции в световен мащаб. Verimesh е изграден върху същата KERI основа, валидирана от GLEIF в институционален мащаб.
Искате да разберете как това пасва на вашата организация?
Вижте как верифицираната инфраструктура на доверие се прилага към вашите конкретни изисквания и регулаторна среда.