Полиция, Бюра за наем, Работодатели, Застрахователи: Защо Не Трябва да Виждат Едни и Същи Данни

Най-голямата грешка в дизайна на бъдещото Международно Разрешително за Управление на МПС (МРУМПС) би била да се третира всеки проверяващ като един и същ проверяващ. Полицейски служител, бюро за наем на автомобили, работодател и застраховател не задават един и същ въпрос — следователно не трябва да получават един и същ отговор.

Един шофьор. Едно основно право за управление. Един портфейл. Но четирима много различни проверяващи:

• Полицейски служител на пътя
• Бюро за наем на автомобили при вземане на превозното средство
• Работодател, проверяващ допустимостта за флот
• Застраховател, разглеждащ щета

Ако бъдещото МРУМПС показва едни и същи данни на всичките четирима, системата вече се е провалила. Не защото удостоверението е несигурно, а защото моделът на разкриване е прекалено опростен.

Стандартизационната общност вече се отдалечава от този опростен модел. Работата на W3C по проверими удостоверения описва екосистемата около издатели, притежатели и проверяващи, използвайки работодатели и уебсайтове като примери за проверяващи. Работата на ЕС по мобилното шофьорско удостоверение вече третира проверките на пътя и наема на автомобили като отделни сценарии за верификация, включително дистанционно предварително споделяне при наем и лични проверки от полицията. Архитектурата вече е проектирана за множество типове проверяващи. Грешката би била да се проектира потребителското изживяване така, сякаш съществува само един тип.

Защо Физическата Карта Ни Научи да Мислим Неправилно

Физическото свидетелство ни приучи към подход на „показване на всичко”. Предавате картата. Другият човек вижда какво пише на нея. Това е цялото взаимодействие.

Този подход е приемлив в хартиен свят, тъй като няма алтернатива. В дигиталния свят той става неприемлив.

Моделът на данни W3C VC 2.0 заявява директно: шофьорско свидетелство може да съдържа идентификационен номер, ръст, тегло, дата на раждане и домашен адрес — но това пак може да е много повече от необходимото за дадена транзакция. Ключови моменти от настоящите стандарти:

• Най-добра практика на W3C: поддържане на селективно разкриване и искане само на строго необходимото
• Насоки на ЕС за защита на данните: обработването трябва да е ограничено до посочените цели, а обработваните данни трябва да са необходими и пропорционални
• Първият принцип на бъдещото МРУМПС: едно и също удостоверение не означава едно и също право на преглед

Правилният Модел е Разкриване Въз Основа на Политики

Ако искате сериозна архитектура, правилният модел е по-близо до управление на достъп на базата на атрибути, отколкото до представяне на цифрова карта.

NIST SP 800-205 дефинира решенията за контрол на достъпа като оценки на атрибутите, свързани с субекта, обекта, исканата операция и условията на средата, спрямо политиката. Това е точно правилната структура за бъдещото МРУМПС:

• Субект: шофьорът
• Обект: исканите полета с данни
• Действие: не „виждане на свидетелството” в абстрактен смисъл, а нещо конкретно като „потвърждаване на право за управление на категория B на пътя” или „потвърждаване на допустимост за наем при резервация”
• Среда: пътят, бюрото за наем, дистанционната предварителна проверка, въвеждането в корпоративния флот и прегледът на щета след загуба са различни среди и трябва да водят до различни решения

NIST също отбелязва, че системите за атрибути се нуждаят от детайлност, управление и механизми за намаляване, групиране и минимизиране на атрибутите.

Следователно бъдещото МРУМПС не трябва да пита: Може ли този проверяващ да прочете свидетелството? То трябва да пита: Кои твърдения може да получи този проверяващ, за каква предназначена употреба, в каква среда и с какви правила за задържане?

Проверяващият Трябва да Се Идентифицира, Преди да Поиска Каквото и да Е

Бъдещото МРУМПС не трябва да започва с показването на данни от портфейла. То трябва да започва с доказването на самоличността на проверяващия.

Архитектурата на EUDI е ясна по този въпрос. Разчитащите страни трябва:

• Да регистрират кои атрибути възнамеряват да искат и с каква цел
• Да получат сертификати за достъп
• Да се удостоверят пред портфейла преди каквото и да е разкриване
• Да бъдат проверени спрямо регистрирания им обхват, когато информацията за регистрацията е налична

След това потребителят може да види кой пита, какво се иска и дали заявката е в рамките на регистрирания обхват.

Текущата работа на ETSI по сертификатите за разчитащи страни на портфейли прави това по-конкретно. Регистрационният сертификат на разчитаща страна на портфейл може да описва предназначената употреба на разчитащата страна и атрибутите, за чието искане е регистрирана. Съответният сертификат за достъп съществува, за да гарантира, че заявката идва от легитимна, упълномощена страна. ETSI включва и метаданни за разчитащата страна, като например:

• Търговско наименование
• URI за поддръжка
• Предназначена употреба
• Права
• URI на регистъра
• Информация за надзорния орган

Вторият принцип на бъдещото МРУМПС: без идентификация на проверяващия — без разкриване.

Защо Екраните за Съгласие Не са Достатъчни

Тук има още една грешка: третирането на одобрението на потребителя като еквивалент на правна легитимност.

Архитектурата на EUDI изрично заявява, че одобрението на потребителя за представяне на атрибути не трябва да се третира като законово основание за обработването на лични данни от разчитащата страна. Разчитащата страна все още трябва да има собствено правно основание. EUDI също изисква одобрение на потребителя при всички случаи на употреба, включително случаи, в които разчитащата страна може да е част от правоприлагащите органи или друга държавна агенция.

Добрият интерфейс на портфейла може да помогне, но не може сам да реши проблема с прекомерните искания на проверяващите. Правилото трябва да съществува преди интерфейса.

Следователно бъдещото МРУМПС се нуждае и от двете:

• Криптографско удостоверяване на проверяващия за потвърждаване на идентичността на питащия
• Политически ограничения върху това, което тази категория проверяващи може да иска

Без и двете, „изборът на потребителя” се превръща в начин за прехвърляне на провала на политиката върху отделния човек.

1. Полиция: Проверка на Правото за Управление, а Не на Цялата Самоличност

Сценарият с полицейска проверка на пътя е най-конкретният.

Ръководството на ЕС за мобилното шофьорско свидетелство го описва директно: полицията или други служители проверяват свидетелството при необходимост, включително валидността му и правата за превозното средство. В потребителското пътуване служителят верифицира свидетелството чрез поток, задействан с QR код, Bluetooth, Wi-Fi Aware или NFC. Това е конкретна задача за верификация:

• Това лице ли е притежателят?
• Валидно ли е удостоверението?
• Какви права за превозни средства и ограничения се прилагат?

Разрешено по подразбиране:

• Имена
• Портрет
• Статус на свидетелството
• Дати на издаване и изтичане
• Категории
• Ограничения, свързани с управлението
• Издател и юрисдикция
• Резултат за актуалност/статус

Не е разрешено по подразбиране:

• Домашен адрес
• Вътрешни идентификатори, ненужни за употреба на пътя
• Несвързани атрибути от други удостоверения
• Исторически журнали за представяне
• Търговски метаданни

Насоките за прилагане на AAMVA подсилват точката за портрета: ако е поискан портрет и е разкрит друг елемент, портретът трябва да бъде споделен, така че проверяващият да може да свърже данните с представящото се лице. Същите насоки гласят, че заинтересованите страни не трябва да проследяват притежателите на мобилни шофьорски свидетелства или употребата им, освен когато се изисква по закон.

Случаят с полицията не е свързан с получаването на всичко от страна на държавата. Той е свързан с получаването на специфични за управлението данни, необходими за прилагане на пътя. Това е важна разлика.

2. Бюра за Наем: Допустимост, Съвпадение на Самоличността и Нищо Излишно

Случаят с наема е по-детайлен, тъй като всъщност има два момента: дистанционна предварителна проверка преди пристигане и вземане на автомобила, когато лице или киоск предава ключовете.

Ръководството на ЕС за мобилното шофьорско свидетелство вече моделира и двата. Услуга за наем на автомобили може да поиска мобилното свидетелство заедно с доказателство за самоличност по време на резервацията, да валидира удостоверенията и по-късно лично да верифицира клиента при вземането преди предаване на превозното средство. Потребителите могат да споделят мобилните си свидетелства с компании за наем на автомобили или лично, или дистанционно предварително.

Бюрото за наем не се нуждае основно от разследване на инцидент. То трябва да реши: Мога ли да наема това превозно средство на този клиент при тази резервация и политика?

Дистанционната предварителна проверка трябва да включва:

• Свързване на самоличността
• Портрет или еквивалентен елемент за обвързване на самоличността
• Съответна категория превозно средство
• Дати на издаване и изтичане
• Текуща валидност
• Евентуално праг за възраст или възрастова група

Вземането на автомобила трябва да потвърди:

• Притежателят е същото лице, което е завършило предварителната проверка
• Текуща валидност
• Съответни права

Не е необходимо по подразбиране:

• Пълен домашен адрес, когато профилът на резервацията вече съдържа данни за контакт
• Пълна дата на раждане, когато е достатъчна проверка „над определена възраст” или възрастова група
• Несвързани атрибути за самоличност
• Повторно представяне на пълното удостоверение, ако вече съществува удостоверение за резервация

Текущата архитектура за мобилни шофьорски свидетелства на NIST показва разчитащата страна, използваща DCQL за искане само на необходимите атрибути, и изрично заявява, че това поддържа минимизирането на данните и съгласието на притежателя чрез структуриране на заявката, а не третирането на удостоверението като единица. AAMVA добавя, че приложението трябва ясно да показва какви данни са поискани и дали проверяващият възнамерява да ги задържи.

3. Работодатели: Категория Проверяващи, а Не Отваряне към Пълна Самоличност

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

Работодател или оператор на флот може основателно да трябва да знае:

• Дали служителят в момента е правоспособен да управлява определени категории превозни средства
• Дали съществуват ключови ограничения
• Дали правото за управление остава валидно

Това е реална бизнес нужда. Но тя не оправдава автоматично постоянен достъп до цялото шофьорско удостоверение, пълните данни за самоличност или непрекъснат поток от повторни представяния.

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

Бъдещото МРУМПС не трябва да се превръща в значка за достъп до работното място.

За употреба от работодатели и флотове, правилният модел обикновено е:

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

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

4. Застрахователи: Щетите Не са Разрешение за Постоянна Видимост

Застрахователният случай е нерядко реален. В материалите за случаите на употреба на мобилното шофьорско свидетелство на ЕС застрахователите се появяват косвено в сценария с наема: застрахователните компании изискват от компаниите за наем на автомобили да проверяват дали лицето, наемащо автомобила, има право да го управлява. Застраховането вече влияе на процеса на верификация на управлението.

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

Бъдещото МРУМПС трябва да третира застрахователите като отделна категория проверяващи с отделни предназначени употреби:

• Застраховане
• Верификация на риска при наем
• Обработка на щети след загуба
• Преглед на измами

Те не са едно и също предназначение. Съгласно принципите на ЕС за защита на данните, личните данни трябва да се събират за посочени цели и да се ограничават до необходимото и пропорционалното за тази цел. Насоките на W3C за VC достигат до същото заключение технически: проверяващите трябва да искат само строго необходимото.

Легитимни примери, специфични за събитие:

• Доказателство, че свидетелството е било валидно в съответния момент
• Доказателство за съответното право за превозно средство
• Доказателство за свързване на самоличността, когато е необходимо за щета
• Разкриване, специфично за щетата

Не е разрешено по подразбиране:

• Постоянен достъп до основното удостоверение
• Повторна обща верификация всеки път, когато клиентът взаимодейства със застрахователя
• Използване на шофьорското удостоверение като токен за влизане
• Събиране на несвързани атрибути

Шофьорското удостоверение не е абонамент за наблюдение. И не трябва тихо да се превръща в такъв.

Защо Посредниците Трябва да Бъдат Видими

Реалните пазари включват посредници. Платформите за наем, доставчиците на флотове, HR системите на работодателите и процесорите за застрахователни щети често действат чрез трети страни.

Архитектурата на EUDI се справя с това чрез:

• Третиране на посредниците като разчитащи страни
• Изискване за тяхната регистрация
• Изискване атрибутите, искани за опосредстваната разчитаща страна, да бъдат регистрирани
• Показване на потребителя и на посредника, и на крайната разчитаща страна
• Забрана на посредниците да съхраняват данни за съдържанието на транзакцията

Бъдещото МРУМПС никога не трябва да допуска модел, при който потребителят смята, че разкрива данни на компанията за наем, но в действителност разкрива на невидима верига от брокери за верификация, процесори за анализ и доставчици за щети.

ETSI помага тук. Моделът му на сертификати за разчитащи страни на портфейли включва URI за поддръжка, предназначена употреба, URI на регистри и метаданни за надзорния орган. Това е типът машинно четима инфраструктура, необходима на потребителите, за да разберат кой всъщност е от другата страна на заявката и накъде да се обърнат, когато искат изтриване или корекция.

Задържането е Част от Контрола на Достъпа

Повечето дискусии за селективно разкриване приключват твърде рано. Те се фокусират върху това, което се разкрива. Те не се фокусират достатъчно върху това колко дълго остава след това.

Настоящите насоки вече се сближават:

• AAMVA: портфейлът трябва ясно да информира притежателя какви данни са поискани и дали проверяващият възнамерява да ги задържи; заинтересованите страни не трябва да проследяват притежателите или употребата на мобилните свидетелства, освен когато се изисква по закон
• W3C: софтуерът на притежателя трябва да предоставя журнали на информацията, споделена с проверяващите, така че да могат да бъдат идентифицирани прекомерни заявки
• EUDI: потребителите трябва да имат достъп до журнали на транзакциите, да могат да докладват подозрителни заявки и да искат изтриване

Класът на задържане трябва да бъде част от самата политика за разкриване:

• Полицейска проверка на пътя: без задържане по подразбиране, извън законовия оперативен запис
• Предварителна проверка при наем: запис на транзакцията, обвързан с резервацията, не копие на самоличността за многократна употреба
• Съответствие на корпоративния флот на работодателя: запис за съответствие или резултат от удостоверение, не сурови данни от удостоверението
• Застрахователна щета: запис за щетата, ограничен до тази щета, не постоянен достъп

Бъдещо МРУМПС, което пренебрегва задържането, само частично запазва поверителността.

Какво Всъщност Трябва да Решава Портфейлът

Ако трябваше да сведа цялата тази статия до едно правило за прилагане, то би било следното:

Портфейлът не трябва да отговаря на въпроса „Мога ли да представя това удостоверение?” Той трябва да отговаря на „Мога ли да представя този набор от твърдения на този удостоверен проверяващ, за тази предназначена употреба, в този контекст, при този клас на задържане?”

Това решение трябва да бъде движено поне от следните входни данни:

• Самоличност на проверяващия
• Категория на проверяващия
• Предназначена употреба
• Регистриран обхват на атрибутите
• Политика за разкриване от издателя, ако е налична
• Среда (пътят, вземане на автомобила, дистанционно, флот, щета)
• Одобрение на притежателя
• Приложима политика за задържане

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

Основният Аргумент

Бъдещото МРУМПС не трябва да пита дали данните могат да бъдат разкрити. То трябва да пита:

• Кой пита?
• За каква цел?
• Въз основа на кой орган?
• В какъв контекст?
• С какви последствия за задържане?

Полицията, бюрата за наем, работодателите и застрахователите не са четири лога от другата страна на заявка. Те са четири различни модела на риск, четири различни правни контекста, четири различни причини за питане — и трябва да генерират четири различни набора от разкрити данни.

Това не е излишна сложност. Така изглежда едно модерно шофьорско удостоверение, когато спре да третира всеки проверяващ като един и същ проверяващ.