От 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) се оценяват в реално време. Данни, неразрешени от политиките, не се преместват.
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 в институционален мащаб.
Искате да разберете как това пасва на вашата организация?
Вижте как верифицираната инфраструктура на доверие се прилага към вашите конкретни изисквания и регулаторна среда.