Архитектура на съгласието

Съгласието не е отметка в поле.

GDPR изисква това от 2018 г.; EHDS Article 71 го направи приложимо миналата година. Decentralized Key Management е единствената архитектура, която може да изпълни оттеглянето на съгласието през институционалните граници.

Заявете 30-минутен преглед на архитектурата на съгласието

Пет регулаторни режима, сближаващи се в 24-месечен прозорец

Съгласието вече не е организационна опция. В Европа и Швейцария пет отделни регулаторни режима превърнаха отказа от съгласие в твърдо правно задължение — всеки изработен независимо от останалите. Те споделят една обща черта: предполагат, че администраторът на данни може при поискване да спре обработката на лични данни, да разпространи тази забрана към всяка последваща страна и да го докаже по-късно. Централизираната инфраструктура за идентичност никога не е проектирана да предоставя нито една от тези гаранции.

  • EHDS Article 71

    В сила от 26 март 2025 г.

    Отказът от съгласие като законно право; Article 71(8) изключва регистри за повторна идентификация; Recital 54 задължава обратимостта.

  • GDPR Art 7(3) + Art 17(2)

    В сила от 25 май 2018 г.

    Оттеглянето трябва да е толкова лесно, колкото даването на съгласие; администраторите трябва да разпространят изтриването към всеки последващ получател.

  • eIDAS 2.0 Article 5a

    В сила от 20 май 2024 г.; портфейли до Q4 2026

    Контролирани от гражданина портфейли за идентичност (identity wallets) с избирателно разкриване и задължения за невъзможност за свързване (unlinkability) към разчитащите страни.

  • Швейцарски FADP / HFG ревизия

    FADP в сила от 1 септември 2023 г.; изменението на HFG в консултация

    Задължение за оттегляне на съгласие при вторично изследователско ползване; изрична забрана за повторна идентификация на псевдонимизирани данни.

  • Германски PDSG

    В сила от 20 октомври 2020 г.

    Контролиран от пациента достъп до електронни здравни досиета (ePA); гранулиран отказ по категория данни, приложим спрямо всички доставчици.

Всеки поотделно е преодолим. Заедно правят централизираната CA архитектура недостатъчна.

Петте инженерни инварианти

Прочетете петте режима така, както би ги прочел един инженер. Отстранете правния език и остава списък от пет технически инварианта, които реализиращата инфраструктура трябва да удовлетворява. Никой от тях не е незадължителен. Никой не може да се договори чрез разумен договорен език. Всеки е назован, по клауза, в първично законодателство.

Five engineering invariants: X.509 PKI vs Federated IAM vs DKMS Сравнение: коя архитектура удовлетворява кой инженерен инвариант. X.509 удовлетворява нула. Федерацията удовлетворява нула (разпространението само като нарушава невъзможността за свързване). DKMS удовлетворява всичките пет. Инженерен инвариант X.509 PKI Федерирана IAM DKMS Идентификатори с обхват на личността ✗ i ✗ ✓ Проверимо маркирано с времева марка оттегляне ✗ ✗ ✓ Обратимост без повторна идентификация ✗ ✗ ✓ Разпространение между администратори ✗ i ✗ i ✓ i Невъзможност за свързване ✗ i ✗ i ✓ i eIDAS 2.0 Art 5a engineering invariants -- X.509 satisfies 0/5, Federation 0/5, DKMS 5/5 Vereign AG -- Engineering Invariants for Lawful Consent

Кликнете върху (i) за обосновката · Кликнете, за да разширите диаграмата

Five engineering invariants: X.509 PKI vs Federated IAM vs DKMS Сравнение: коя архитектура удовлетворява кой инженерен инвариант. X.509 удовлетворява нула. Федерацията удовлетворява нула (разпространението само като нарушава невъзможността за свързване). DKMS удовлетворява всичките пет. Инженерен инвариант X.509 PKI Федерирана IAM DKMS Идентификатори с обхват на личността ✗ i ✗ ✓ Проверимо маркирано с времева марка оттегляне ✗ ✗ ✓ Обратимост без повторна идентификация ✗ ✗ ✓ Разпространение между администратори ✗ i ✗ i ✓ i Невъзможност за свързване ✗ i ✗ i ✓ i eIDAS 2.0 Art 5a engineering invariants -- X.509 satisfies 0/5, Federation 0/5, DKMS 5/5 Vereign AG -- Engineering Invariants for Lawful Consent

Защо X.509 не може да осигури идентификатори с обхват на личността

X.509 идентифицира субектите чрез сертификати, издадени от Certificate Authority (CA) — а не чрез ключове, контролирани от субекта. Гражданинът няма архитектурна намеса на нивото на корена на доверието — CA решава кой е кой. EHDS Recital 54 и eIDAS 2.0 Article 5a изискват идентификатори, контролирани от субекта; X.509 удовлетворява това само чрез субектна обвивка (subject-side ceremony), която базовият PKI протокол не поддържа нативно.

Защо X.509 не може да разпространи оттеглянето

X.509 няма нативна примитива за разпространение. Отмяната се каскадира през CRL и OCSP responder-и, които всеки верификатор трябва изрично да избере да проверява — и няма начин да се избута отмяна обратно към данни, които вече са били споделени. След като сертификат е подписал разрешение за поток от данни, оттеглянето остава по преценка на верификатора.

Защо X.509 нарушава невъзможността за свързване

Всеки X.509 сертификат носи стабилен сериен номер и Issuer DN, видим за всеки верификатор. Две разчитащи страни могат да корелират един и същ субект през транзакции, сравнявайки серийните номера. Псевдонимизацията изисква повторно издаване, което е оперативно скъпо — свързваемостта тук е по дизайн, не грешка.

Защо федерацията само частично удовлетворява разпространението

Федерираната IAM удовлетворява разпространението между администратори само като нарушава невъзможността за свързване (unlinkability) — доставчикът на идентичност вижда всяко влизане при разчитаща страна, създавайки забранена повърхност за корелация между разчитащи страни (eIDAS 2.0 Art 5a(16)(b)). Затова разпространението чрез федерация се счита за неудовлетворено.

Защо федерацията не може да осигури невъзможност за свързване

Федериран доставчик на идентичност (IdP) вижда всеки опит за вход при всяка разчитаща страна. Дори отделните идентификационни данни да са псевдоними, IdP-то по конструкция държи графа на корелация между RP. eIDAS 2.0 Article 5a(16)(b) забранява точно тази повърхност.

Как DKMS разпространява оттеглянето

Разрешенията се верижат към журнала на ключовите събития (Key Event Log, KEL) на субекта. Когато субектът ротира ключове, всеки верификатор надолу по веригата, който проверява отново KEL при обработката, вижда ротацията и третира остарелите идентификационни данни като невалидни. Без push от оператор, без централен регистър — разпространението е verifier-pull в момента на ползване.

Как DKMS запазва невъзможността за свързване

Субектите могат да генерират свеж AID за всяка разчитаща страна. KEL зад всеки AID е независим — няма централен регистър на идентичности и няма IdP, който вижда всяка транзакция. Корелацията между RP изисква субектът съзнателно да свърже AID-овете.

  1. Идентификатори с обхват на личността

    Идентификаторът, контролиран от субекта на данните, трябва да е коренът на доверие (trust root), а не идентификатор, издаден от разчитаща страна. EHDS Recital 54 и eIDAS 2.0 Article 5a назовават това директно: гражданинът трябва да може да действа, без администраторът да го търси в отделен регистър. Всяка архитектура, която зависи от това администраторът да сече и съхранява идентификатора, се проваля тук от самото начало.

  2. Проверимо маркирано с времева марка оттегляне

    Оттеглянето трябва да е криптографски подписано (cryptographically signed), маркирано с времева марка събитие, което регулаторът (и бъдещ съд) може да провери, без да се доверява на записите на администратора. GDPR Article 7(3) е изричен: доказателствената тежест е върху администратора. Ред в вътрешна база данни не е доказателство в никой форум, в който администраторът е ответникът.

  3. Обратимост без повторна идентификация

    Recital 54 на EHDS изисква отказът от съгласие да остава обратим — гражданинът може да се върне — без някой да трябва да повторно идентифицира (re-identify) основните записи. Това изисква отказът да действа срещу удостоверение, контролирано от субекта, а не срещу таблица за съпоставяне на страна-сървър. Централизираните регистри за съгласие се провалят тук структурно.

  4. Разпространение между администратори

    GDPR Article 17(2) и EHDS Article 71 изискват оттеглянето да се разпространи до всеки последващ получател. На практика това означава, че първоначалният администратор не може просто да обнови своя локален ред — всяка страна, получила някога данните, трябва повторно да удостовери упълномощаването и да установи, че то е отменено. Федерацията може да направи това само като споделя идентификатори, което нарушава следващия инвариант.

  5. Невъзможност за свързване

    eIDAS 2.0 Article 5a изисква разчитащите страни да не могат да корелират един и същи гражданин в отделни транзакции без съгласие. Article 71(8) на EHDS изключва централизирания междуорганизационен идентификатор, който би направил федерираното разпространение тривиално. Двата инварианта заедно — разпространи, но не корелирай — са това, което убива конвенционалните архитектури.

X.509 удовлетворява нула. Федерацията удовлетворява разпространението, като нарушава невъзможността за свързване. DKMS удовлетворява всичките пет.

Капанът на Article 71(8)

Интуитивният инженерен отговор на „зачитай отказа от съгласие в мрежата" е да се поддържа списък с идентификаторите на отказалите се — централно поддържан регистър за забрана на обработката, който всяка последваща система проверява, преди да докосне запис. Article 71(8) на EHDS конкретно забранява точно тази конструкция. Клаузата забранява на притежателите на данни да придобиват или съхраняват допълнителни идентификационни данни единствено с цел зачитане на отказа от съгласие.

Логиката, изрично посочена в Recital 54, е, че самият регистър се превръща в база данни за повторна идентификация — точно вредата, която регламентът е написан да предотврати. Веднага щом поддържате списък с „хора, отказали съгласие", сте възстановили централната база за атаки (honeypot). Структурното следствие е неизбежно: сигналът за отказ трябва да пътува с удостоверение, контролирано от субекта, а не в списък, поддържан от администратора.

The DKMS thesis DKMS е отговорът

Децентрализираното управление на ключове (Decentralized Key Management) е първата структурно стабилна основа за зачитане на отказа от съгласие изцяло — в условия на междуорганизационен поток, след-разкриване и регулаторно наблюдение.

(Децентрализираното управление на ключове се базира на KERI — Key Event Receipt Infrastructure, отворена спецификация на Trust over IP Foundation.)

Как работи:

  1. Контролиращият AID на потребителя е коренът на доверие. Упълномощаванията се свързват с него криптографски, не с акаунт, издаден от администратора.
  2. Всяко упълномощаване е закотвено в журнала на ключовите събития (Key Event Log, KEL) на AID — само-добавящ се, свързан с хеш запис, чието състояние субектът може да докаже едностранно.
  3. Оттеглянето е ротация на ключ, извършена от самия субект. Старият ключ е обявен за невалиден; събитието за ротация е криптографски подписано и маркирано с времева марка в KEL.
  4. Последващите страни, притежаващи остарели удостоверения, трябва да се удостоверят повторно спрямо актуалното състояние на KEL. Оттеглянето се разпространява, като е неуспешно при всеки последващ верификатор.

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

Където DKMS доминира — и където не предлага полза

Честността относно обхвата е това, което прави тезата защитима. DKMS доминира при четири условия: потоци от данни между организации, оттегляне след разкриване, регулаторно наблюдавана обработка и противопоставящи се насрещни страни. Извън тези условия — едноарендаторни натоварвания, производни артефакти като тегла на обучени ML модели, вече направени резервни копия преди оттеглянето и единична нечестна насрещна страна, действаща сама — DKMS осигурява криминалистично откривание, но не превенция.

Където DKMS доминира Където DKMS не предлага полза Потоци от данни между организации Кликнете върху ред за обосновката Устойчивост на съгласието след разкриване Кликнете върху ред за обосновката Регулаторно-определящо попечителство Кликнете върху ред за обосновката Страните прилагат DKMS от край до край Кликнете върху ред за обосновката Производни артефакти (анализи, тегла на ML модели) Кликнете върху ред за обосновката Вече направени резервни копия Кликнете върху ред за обосновката Единична нечестна насрещна страна Кликнете върху ред за обосновката Едноарендаторни натоварвания Кликнете върху ред за обосновката Където DKMS доминира — и където не предлага полза. Кликнете върху ред за обосновката.

Потоци от данни между организации

Изтриването на страна-оператор не може да достигне данни, вече споделени с последващи страни. DKMS разширява криптирането с ключове на притежателя (holder-controlled keying) по цялата обработваща верига — всеки получател проверява повторно KEL в момента на ползване. Централизираният CMK осигурява изтриване само в границите на арендаторното пространство на оператора.

Устойчивост на съгласието след разкриване

EUDIW ARF §6.6 изрично признава, че оттеглянето не отменя ретроактивно законосъобразна предходна обработка. DKMS стеснява тази пропаст: верификаторите повторно проверяват публикувания KEL в момента на обработката, така че остарелите удостоверения стават одитируеми като такива. Архитектурният примитив е управляван от притежателя, а не от оператора.

Регулаторно-определящо попечителство

Schrems II / EDPB Recommendations 01/2020 Use Case 3 изискват вносителят на данни ДА НЕ притежава ключове. Централизираният CMK по дефиниция не издържа на този тест (напр. здравни данни от САЩ в Azure при достъп по FISA 702). DKMS прави попечителството на ключовете свойство на страна-притежател — вносителят не може да декриптира без текущото KEL състояние на притежателя.

Страните прилагат DKMS от край до край

Архитектурата има значение само когато всички страни я прилагат. Верификатор, игнориращ KEL, обезсилва веригата. Когато всички страни прилагат DKMS, оттеглянето се разпространява чрез просто повторно верифициране — никой оператор не трябва да „натиска" изтриването.

Производни артефакти (анализи, тегла на ML модели)

EDPB Opinion 28/2024 изрично потвърждава, че задълженията за изтриване не се разпространяват чисто до теглата на модели след приключване на обучението. DKMS не осигурява по-добро покритие от CMK тук. Оттеглянето не може ретроактивно да отмени аналитични резултати или вече подадени регулаторни доклади.

Вече направени резервни копия

Никоя архитектура не може да извика обратно данни, вече репликирани на офлайн или неизменими носители за резервни копия. Криптирането в покой плюс унищожаването на ключа покрива остатъците в рамките на прозореца за задържане; то не възстановява дългосрочни архиви. DKMS не променя това фундаментално свойство.

Единична нечестна насрещна страна

DKMS осигурява криминалистично откривание (подписите след публикувана ротация на ключ са одитируеми като остарели), но не превенция. Напълно некооперативен подизпълнител, декриптиращ открит текст и съхраняващ го извън криптирания обвит, обезсилва веригата — DKMS разкрива нарушението, вместо да го блокира.

Едноарендаторни натоварвания

За SaaS под един администратор криптографското изтриване по NIST SP 800-88 §2.5 чрез централизиран CMK е достатъчно и по-просто. Преминаването към DKMS добавя оперативна тежест без архитектурна полза, когато няма граници между домейни на доверие.

Извън четирите условия, при които DKMS доминира, централизираният CMK е рационален избор. Казването на това прави тезата по-силна.

Доказателство от продукционна среда

HIN — Health Info Net — е гръбнакът на здравната информация в Швейцария, свързващ болници, клиники и специализирани доставчици през кантоналните граници. SEAL — слоят за верифицируема доставка на имейл, който Vereign предоставя в рамките на HIN — е в production днес и пренася над 800 000 верифицирани съобщения месечно — доказателство, че Vereign вече оперира production-grade инфраструктура вътре в швейцарското здравеопазване.

Stargate — runtime средата за Decentralized Key Management, която въвежда в оперативна употреба четиристъпковия opt-out механизъм, описан по-горе — влиза в ранен production през юни 2026 г.

FHIR слоят на Stargate — същите гаранции, приложени към обмена на клинични записи, а не само към съобщения — днес е архитектурно разработен. Преминаването му в production зависи от onboarding от страна на болниците; най-ранната реалистична дата е септември 2026 г.

Пет инцидента, доказващи структурния модел

  1. Kaiser Foundation Health Plan — USD 47,5 млн. извънсъдебно споразумение по колективен иск (2026). Данни от пациентски портал изтекоха към рекламни платформи чрез вградени проследяващи пиксели. Архитектурата нямаше механизъм субектът да оттегли последващото разпространение.
  2. Sutter Health — USD 21,5 млн. извънсъдебно споразумение по колективен иск (2026). Същият модел: тагове на трети страни на страна портал, без примитив за отмяна, контролиран от субекта, без възможност да се докаже не-обработка след събитието.
  3. NHS National Data Opt-Out (2021) — признание за невъзможност за ретроактивно действие; програмата GPDPR беше забавена, защото архитектурата не можеше да зачете оттеглянето срещу данни вече споделени с последващи изследователи.
  4. SingHealth (2018) — 1,5 млн. записа бяха пробити, защото пациентските данни се намираха в единична монолитна база без криптографски граници на пациента. Субектът нямаше какво да отмени; нямаше ключ за ротация.
  5. DigiNotar (2011) — компрометирането на коренния CA накара браузърите да не се доверяват на всеки сертификат, издаван някога от този CA. Субектите нямаха никаква архитектурна свобода: техните идентификатори и отношения на доверие бяха изцяло контролирани от оператора.

Всеки централизиран инцидент споделя една обща черта: потребителят нямаше архитектурна свобода.

Откъде да започнете

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

Заявете 30-минутен преглед на архитектурата на съгласието Изтеглете тезата за съгласието (PDF, 24 стр.)

За Вашия сектор

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

Прочетете повече

Прилагане на съгласието във финансите

Прочетете повече

Често задавани въпроси

Какво изисква EHDS Article 71?
EHDS Article 71 (в сила от 26 март 2025 г.) дава на всеки гражданин на ЕС право да откаже вторично ползване на лични здравни данни. Article 71(8) забранява на притежателите на данни да придобиват допълнителни идентификационни данни единствено за зачитане на отказа — изключвайки централизирани реализации на „списък с отказали се идентификатори", тъй като самият списък е забранен запис за повторна идентификация. Recital 54 задължава отказът да е обратим и в свободна форма.
Защо централизиран регистър за съгласие не може да работи?
Article 71(8) го забранява изрично. Самият регистър се превръща в запис за повторна идентификация — точно това, което регламентът е проектиран да предотврати. Структурният отговор изисква идентификатори, контролирани от субекта, а не централен списък, контролиран от оператора.
Гарантира ли DKMS прилагането на съгласието?
Не. DKMS е първата структурно стабилна основа за зачитане на отказа от съгласие изцяло в условия на междуорганизационен поток, след-разкриване и регулаторно наблюдение. Извън тези условия — едноарендаторни натоварвания, производни като тегла на ML модели, вече направени резервни копия, единична нечестна насрещна страна — DKMS осигурява криминалистично откривание, но не превенция.
Как DKMS си взаимодейства с насрещни страни, използващи X.509 / S/MIME?
Чрез мостове S/MIME, закотвени в KERI (KERI-anchored S/MIME bridges), позволяващи оттеглянето да се разпространи към страни, ползващи X.509. Мостът закотвя X.509 сертификата към KERI AID; оттеглянето на съгласие задейства ротация на ключа на AID; последващите X.509 верификатори трябва повторно да изтеглят и удостоверят.