Policia, Sportelet e Marrjes me Qira, Punëdhënësit, Siguruesit: Pse Nuk Duhet të Shohin të Njëjtat të Dhëna

Gabimi më i madh i projektimit në një Leje Drejtimi Ndërkombëtare (LDN) të ardhshme do të ishte trajtimi i çdo verifikuesi si i njëjti verifikues. Një oficer policie, një sportel marrjeje me qira makine, një punëdhënës dhe një sigurues nuk bëjnë të njëjtën pyetje — prandaj nuk duhet të marrin të njëjtën përgjigje.

Një shofer. Një e drejtë bazë për të drejtuar. Një portofol. Por katër verifikues shumë të ndryshëm:

• Një oficer policie anës rrugës
• Një sportel marrjeje me qira makine gjatë tërheqjes
• Një punëdhënës që kontrollon kushtet e flotës
• Një sigurues që shqyrton një kërkesë

Nëse LDN e ardhshme u tregon të njëjtat të dhëna të katërve, sistemi ka dështuar tashmë. Jo sepse kredenciali është i pasigurt, por sepse modeli i zbulimit është shumë i thjeshtë.

Komuniteti i standardeve po largohet tashmë nga ai model i thjeshtë. Puna e W3C-së për kredencialet e verifikueshme përshkruan ekosistemit rreth lëshuesve, mbajtësve dhe verifikuesve, duke përdorur punëdhënësit dhe faqet e internetit si shembuj verifikuesish. Puna e Bashkimit Europian (BE) për lejet e drejtimit në celular trajton tashmë kontrollet anës rrugës dhe marrjet me qira makine si skenarë verifikimi të veçantë, duke përfshirë ndarjen paraprake nga distanca për marrjet me qira dhe kontrollet personale për policinë. Arkitektura është projektuar tashmë për lloje të shumta verifikuesish. Gabimi do të ishte projektimi i përvojës së përdoruesit sikur të ekzistojë vetëm një lloj.

Pse Karta Fizike Na Mësoi të Mendojmë Gabim

Një leje fizike na mësoi qasjen e shfaqjes-gjithçkaje. E dorëzon kartën. Personi tjetër sheh çfarë është në kartë. Kjo është e gjithë ndërveprimi.

Kjo qasje është e pranueshme në një botë letre sepse nuk ka alternativë. Bëhet e papranueshme në një botë dixhitale.

Modeli i të Dhënave VC 2.0 i W3C-së thotë drejtpërdrejt: një leje drejtimi mund të përmbajë numrin e ID-së, gjatësinë, peshën, ditëlindjen dhe adresën e shtëpisë — por kjo mund të jetë shumë më tepër se sa e nevojshme për një transaksion të caktuar. Pikat kryesore nga standardet aktuale:

• Praktika më e mirë e W3C-së: mbështetni zbulimin selektiv dhe kërkoni vetëm atë që është rreptësisht e nevojshme
• Udhëzimi i mbrojtjes së të dhënave i BE-së: përpunimi duhet të kufizohet në qëllime të specifikuara, dhe të dhënat e përpunuara duhet të jenë të nevojshme dhe proporcionale
• Parimi i parë i një LDN të ardhshme: i njëjti kredencial nuk do të thotë e njëjta e drejtë për inspektim

Modeli i Duhur Është Zbulimi i Bazuar në Politika

Nëse doni një arkitekturë serioze, modeli i duhur është më afër kontrollit të aksesit të bazuar në atribute sesa prezantimit të kartës dixhitale.

NIST SP 800-205 përcakton vendimet e kontrollit të aksesit si vlerësime të atributeve të lidhura me subjektin, objektin, operacionin e kërkuar dhe kushtet e mjedisit, kundrejt politikës. Kjo është pikërisht struktura e duhur për një LDN të ardhshme:

• Subjekti: shoferi
• Objekti: fushat e të dhënave të kërkuara
• Veprimi: jo “shiko lejen” në mënyrë abstrakte, por diçka e veçantë si “verifiko të drejtën e drejtimit të kategorisë B anës rrugës” ose “verifiko kushtet e marrjes me qira për një rezervim”
• Mjedisi: anës rrugës, sportel marrjeje me qira, kontroll paraprak nga distanca, integrimi në flotë dhe shqyrtimi i kërkesave pas humbjeve janë mjedise të ndryshme dhe duhet të çojnë në vendime të ndryshme

NIST gjithashtu vëren se sistemet e atributeve kanë nevojë për granularitet, qeverisje dhe mekanizma për reduktim, grupim dhe minimizim të atributeve.

Prandaj LDN e ardhshme nuk duhet të pyesë: A mund ky verifikues të lexojë lejen? Duhet të pyesë: Cilat pretendime mund të marrë ky verifikues, për çfarë përdorimi të synuar, në këtë mjedis, me çfarë rregullash ruajtjeje?

Një Verifikues Duhet të Identifikohet Para se të Kërkojë Ndonjë Gjë

LDN e ardhshme nuk duhet të fillojë me portofolin që tregon të dhëna. Duhet të fillojë me verifikuesin që provon kush është.

Arkitektura EUDI është e qartë për këtë. Palët mbështetëse duhet të:

• Regjistrojnë cilat atribute synojnë të kërkojnë dhe për çfarë qëllimi
• Marrin çertifikata aksesi
• Autentikohen te portofoli para çdo zbulimi
• Kontrollohen kundrejt fushës së tyre të regjistruar, kur informacioni i regjistrimit është i disponueshëm

Përdoruesi mund të shohë kush po kërkon, çfarë po kërkohet dhe nëse kërkesa është brenda fushës së regjistruar.

Puna aktuale e ETSI-së për çertifikatat e palëve mbështetëse të portofolit e bën këtë më konkrete. Një çertifikatë regjistrimi e palës mbështetëse të portofolit mund të përshkruajë përdorimin e synuar të palës mbështetëse dhe atributet që ajo ka regjistruar për të kërkuar. Çertifikata e aksesit e lidhur ekziston për të siguruar që kërkesa vjen nga një palë legjitime dhe e autorizuar. ETSI gjithashtu përfshin metadat e palës mbështetëse si:

• Emri tregtar
• URI mbështetjeje
• Përdorimi i synuar
• Autorizimet
• URI regjistri
• Informacioni i autoritetit mbikëqyrës

Parimi i dytë i një LDN të ardhshme: pa identitetin e verifikuesit, nuk ka zbulim.

Pse Ekranet e Miratimit Nuk Janë të Mjaftueshme

Ka edhe një gabim tjetër këtu: trajtimi i miratimit të përdoruesit si i njëjti gjë si legjitimiteti ligjor.

Arkitektura EUDI thotë shprehimisht se miratimi i përdoruesit për të paraqitur atribute nuk duhet të trajtohet si bazë ligjore për përpunimin e të dhënave personale nga pala mbështetëse. Pala mbështetëse duhet të ketë ende bazën e saj ligjore. EUDI kërkon gjithashtu miratimin e përdoruesit në të gjitha rastet e përdorimit, duke përfshirë rastet kur pala mbështetëse mund të jetë pjesë e zbatimit të ligjit ose një agjenci tjetër qeveritare.

Një ndërfaqe e mirë portofoli mund të ndihmojë, por nuk mund ta zgjidhë vetë tejkalimin e verifikuesit. Rregulli duhet të ekzistojë para ndërfaqes.

Prandaj një LDN e ardhshme ka nevojë për të dyja:

• Autentikimi kriptografik i verifikuesit për të konfirmuar kush po kërkon
• Kufizime politikash mbi atë që ajo kategori verifikuesi mund të kërkojë

Pa të dyja, “zgjedhja e përdoruesit” bëhet një mënyrë për të transferuar dështimin e politikës tek individi.

1. Policia: Verifikoni të Drejtën për të Drejtuar, Jo të Gjithë Personin

Skenari i policisë anës rrugës është ai më i fokusuar.

Manuali i mDL-së i BE-së e përshkruan drejtpërdrejt: policia ose zyrtarë të tjerë kontrollojnë lejen kur kërkohet, duke përfshirë vlefshmërinë e lejes dhe autorizimet e mjetit. Në udhëtimin e përdoruesit, oficeri verifikon lejen përmes një rrjedhe të aktivizuar nga QR, Bluetooth, Wi-Fi Aware ose NFC. Kjo është një detyrë verifikimi e fokusuar:

• A është ky person mbajtësi?
• A është kredenciali i vlefshëm?
• Cilat autorizime dhe kufizime mjeti zbatohen?

Lejohet si parazgjedhje:

• Emri
• Portret
• Statusi i lejes
• Datat e lëshimit dhe skadimit
• Kategoritë
• Kufizimet relevante për drejtimin
• Lëshuesi dhe juridiksioni
• Rezultati i freskisë/statusit

Nuk lejohet si parazgjedhje:

• Adresa e shtëpisë
• Identifikuesit e brendshëm që nuk nevojiten për përdorim anës rrugës
• Atribute të palidhura nga vërtëtimet e tjera
• Regjistrat e paraqitjeve historike
• Metadat tregtare

Udhëzimi i zbatimit i AAMVA-s forcon pikën e portretit: nëse portretit i kërkohet dhe çdo element tjetër lirohet, portreti duhet të ndahet në mënyrë që verifikuesi të mund ta lidhë të dhënën me personin që e paraqet. I njëjti udhëzim gjithashtu thotë se palët e interesuara nuk duhet të gjurmojnë mbajtësit e mDL-së ose përdorimin e mDL-së përveç kur kërkohet me ligj.

Rasti i policisë nuk ka të bëjë me shtetin që merr gjithçka. Ka të bëjë me shtetin që merr të dhënat specifike të drejtimit të nevojshme për zbatimin anës rrugës. Kjo është një ndryshim i rëndësishëm.

2. Sportelet e Marrjes me Qira: Kushtet e Pranueshmërisë, Konfirmimi i Identitetit dhe Asgjë e Panevojshme

Rasti i marrjes me qira është më i detajuar sepse ka vërtet dy momente: kontroll paraprak nga distanca para mbërritjes, dhe tërheqja kur një person ose kiosk dorëzon çelësat.

Manuali i mDL-së i BE-së i modelon të dyja tashmë. Një shërbim marrjeje me qira makine mund të kërkojë mDL-në së bashku me provën e identitetit gjatë rezervimit, të vërtetojë vërtetimet dhe më vonë të verifikojë klientin personalisht gjatë tërheqjes para se të lëshojë mjetin. Përdoruesit mund të ndajnë mDL-të e tyre me kompanitë e marrjes me qira makine ose personalisht ose nga distanca paraprakisht.

Një sportel marrjeje me qira kryesisht nuk ka nevojë të hetojë një incident. Duhet të vendosë: A mund t’i jap me qira këtë mjet këtij klienti sipas këtij rezervimi dhe politike?

Kontrolli paraprak nga distanca duhet të përfshijë:

• Lidhjen e identitetit
• Portret ose element ekuivalent të lidhjes së identitetit
• Kategorinë relevante të mjetit
• Datat e lëshimit dhe skadimit
• Vlefshmërinë aktuale
• Mundësisht një prag moshe ose brez moshe

Tërheqja duhet të konfirmojë:

• Mbajtësi është i njëjti person që ka kryer kontrollin paraprak
• Vlefshmëria aktuale
• Autorizimet relevante

Nuk nevojitet si parazgjedhje:

• Adresa e plotë e shtëpisë kur një profil rezervimi tashmë përmban detajet e kontaktit
• Data e plotë e lindjes ku mosha-mbi ose brezi i moshës është i mjaftueshëm
• Atribute identiteti të palidhura
• Ri-paraqitja e përsëritur e kredencialit të plotë nëse tashmë ekziston një vërtetim rezervimi

Arkitektura aktuale e mDL-së e NIST-it tregon palën mbështetëse duke përdorur DCQL për të kërkuar vetëm atributet e nevojshme, dhe thotë shprehimisht se kjo mbështet minimizimin e të dhënave dhe miratimin e mbajtësit duke strukturuar kërkesën në vend që ta trajtojë kredencialin si një njësi të vetme. AAMVA shton se aplikacioni duhet të tregojë qartë çfarë të dhënash u kërkua dhe nëse verifikuesi synon të ruajë informacionin.

3. Punëdhënësit: Një Kategori Verifikuesi, Jo një Hapje drejt Identitetit të Plotë

Pasqyrimi i W3C-së përdor sistemin dixhital të një punëdhënësi që kontrollon një diplomë universitare si shembull verifikuesi. Kjo na kujton se verifikimi i punëdhënësit është tashmë një model i njohur në ekosistemet e kredencialeve.

Një punëdhënës ose operator flote mund të ketë nevojë legjitime të dijë:

• Nëse një punëtor aktualisht ka të drejtë të drejtojë kategori të caktuara mjetesh
• Nëse ekzistojnë kufizime kyçe
• Nëse autorizimi mbetet i vlefshëm

Kjo është një nevojë reale biznesi. Por nuk justifikon automatikisht akses të përhershëm në të gjithë kredencialin e drejtimit, të gjitha të dhënat e identitetit, ose një rrjedhë të vazhdueshme paraqitjesh të përsëritura.

NIST paralajmëron se transmetimi i shpeshtë i një identifikuesi të ripërdorshëm dhe kushtëzimi i përdoruesve për të paraqitur vazhdimisht një kredencial të mbartë identiteti është i padëshirueshëm, dhe thotë se autentikimi i përditshëm duhet të mbështetet në teknologji të projektuara për autentikim, si çelësat e kalimit. NIST preferon autentikimin lokal të pajisjes ndaj përputhjes biometrike nga ana e serverit sepse mbron më mirë privatësinë.

Një LDN e ardhshme nuk duhet të bëhet një badge aksesi në vendin e punës.

Për përdorimin nga punëdhënësi dhe flota, modeli i duhur zakonisht është:

• Një kontroll autorizimi relevant për punën
• Ndoshta një vërtetim periodik i pajtueshmërisë
• Ndoshta një pretendim se mbajtësi mbetet i vlefshëm për kategoritë e specifikuara
• Por jo transferim si parazgjedhje i të gjitha të dhënave të lejes sa herë që punonjësi identifikohet në një sistem ose fillon një turë

Pajtueshmëria e flotës është një kategori e veçantë palë mbështetëse, me një përdorim të synuar të veçantë, dhe një profil të veçantë zbulimi.

4. Siguruesit: Kërkesat Nuk Janë Leje për Dukshmëri të Vazhdueshme

Rasti i sigurimit është shpesh real. Në materialin e rasteve të përdorimit të mDL-së të BE-së, siguruesit shfaqen indirekt në skenarin e marrjes me qira: kompanitë e sigurimit kërkojnë nga kompanitë e marrjes me qira makine të kontrollojnë nëse personi që merr me qira makinën ka të drejtë të drejtojë. Sigurimi ndikon tashmë në rrjedhën e verifikimit të drejtimit.

Por kjo nuk do të thotë se një sigurues duhet të marrë të njëjtat të dhëna si policia, ose një të drejtë të përhershme aksesi në kredencial.

Një LDN e ardhshme duhet t’i trajtojë siguruesit si një kategori të veçantë verifikuesi me qëllime të synuara të ndara:

• Nënshkrim
• Verifikimi i rrezikut të marrjes me qira
• Trajtimi i kërkesave pas humbjeve
• Shqyrtimi i mashtrimit

Këto nuk janë i njëjti qëllim. Sipas parimeve të mbrojtjes së të dhënave të BE-së, të dhënat personale duhet të mblidhen për qëllime të specifikuara dhe të kufizohen në atë që është e nevojshme dhe proporcionale për atë qëllim. Udhëzimi VC i W3C-së arrin të njëjtin përfundim teknikisht: verifikuesit duhet të kërkojnë vetëm atë që është rreptësisht e nevojshme.

Shembuj legjitime, specifike për ngjarje:

• Provë se leja ishte e vlefshme në momentin përkatës
• Provë e autorizimit të mjetit relevant
• Provë e lidhjes së identitetit kur nevojitet për një kërkesë
• Zbulim specifik për kërkesën

Nuk lejohet si parazgjedhje:

• Akses i vazhdueshëm në kredencialin bazë
• Verifikim i përgjithshëm i përsëritur sa herë që klienti ndërvepron me siguruesin
• Përdorimi i kredencialit të drejtimit si token identifikimi
• Mbledhja e atributeve të palidhura

Një kredencial drejtimi nuk është një abonement monitorimi. Dhe nuk duhet të bëhet i tillë në heshtje.

Pse Ndërmjetësit Duhet të Jenë të Dukshëm

Tregjet reale përfshijnë ndërmjetës. Platformat e marrjes me qira, shitësit e flotave, sistemet HR të punëdhënësve dhe procesuesit e kërkesave të sigurimit shpesh veprojnë nëpërmjet palëve të treta.

Arkitektura EUDI e trajton këtë duke:

• Trajtuar ndërmjetësit si palë mbështetëse
• Kërkuar që ata të regjistrohen
• Kërkuar që atributet e kërkuara për palën mbështetëse të ndërmjetësuar të regjistrohen
• Treguar përdoruesit si ndërmjetësin ashtu edhe palën mbështetëse fundore
• Ndaluar ndërmjetësit nga ruajtja e të dhënave rreth përmbajtjes së transaksionit

Një LDN e ardhshme nuk duhet të lejojë kurrë një model ku përdoruesi beson se po zbulojë te kompania e marrjes me qira, por në realitet po zbulojë te një ndërmjetës i padukshëm verifikimi, procesor analitikash dhe zinxhir shitësish kërkesash.

ETSI ndihmon këtu. Modeli i çertifikatave të palës mbështetëse të portofolit i ETSI-së përfshin URI-të mbështetëse, përdorimin e synuar, URI-të e regjistrit dhe metadat e autoritetit mbikëqyrës. Kjo është lloji i infrastrukturës i lexueshëm nga makina që nevojitet që përdoruesit të kuptojnë se kush është vërtet në anën tjetër të kërkesës dhe ku të shkojnë kur duan fshirje ose korrigjim.

Ruajtja Është Pjesë e Kontrollit të Aksesit

Shumica e diskutimeve rreth zbulimit selektiv mbarojnë shumë herët. Fokusohen në atë që zbulohet. Nuk fokusohen mjaftueshëm në sa kohë mbetet pastaj.

Udhëzimi aktual po konvergjon tashmë:

• AAMVA: portofoli duhet t’i tregojë qartë mbajtësit çfarë të dhënash u kërkua dhe nëse verifikuesi synon t’i ruajë; palët e interesuara nuk duhet të gjurmojnë mbajtësit ose përdorimin e mDL-së përveç kur kërkohet me ligj
• W3C: softueri i mbajtësit duhet të ofrojë regjistrat e informacionit të ndarë me verifikuesit, në mënyrë që të identifikohen kërkesat e tepruara
• EUDI: përdoruesit duhet të mund të aksesojnë regjistrat e transaksioneve, të raportojnë kërkesa të dyshimta dhe të kërkojnë fshirje

Klasa e ruajtjes duhet të jetë pjesë e politikës së zbulimit vetë:

• Policia anës rrugës: pa ruajtje si parazgjedhje përtej rekordit operacional ligjor
• Kontrolli paraprak i marrjes me qira: rekord transaksioni i lidhur me rezervimin, jo një kopje identiteti e ripërdorshme
• Pajtueshmëria e flotës së punëdhënësit: rekord pajtueshmërie ose rezultat vërtetimi, jo të dhëna të papërpunuara kredenciali
• Kërkesa e siguruesit: rekord kërkese i kufizuar në kërkesë, jo akses i përhershëm

Një LDN e ardhshme që injoron ruajtjen ruan privatësinë vetëm pjesërisht.

Çfarë Duhet Vërtet të Vendosë Portofoli

Nëse do ta reduktoja të gjithë këtë artikull në një rregull zbatimi, do të ishte ky:

Portofoli nuk duhet të përgjigjet “A mund të paraqes këtë kredencial?” Duhet të përgjigjet “A mund t’i paraqes këtë grup pretendimesh këtij verifikuesi të autentikuar, për këtë përdorim të synuar, në këtë kontekst, sipas kësaj klase ruajtjeje?”

Ai vendim duhet të drejtohet nga të paktën këto hyrje:

• Identiteti i verifikuesit
• Kategoria e verifikuesit
• Përdorimi i synuar
• Fusha e atributeve të regjistruara
• Politika e zbulimit nga lëshuesi, nëse ekziston
• Mjedisi (anës rrugës, tërheqja, nga distanca, flota, kërkesa)
• Miratimi i mbajtësit
• Politika e ruajtjes e zbatueshme

Standardet tashmë përmbajnë shumë nga mekanizmat për këtë: zbulimi selektiv, autentikimi i palës mbështetëse, përdorimi i synuar i regjistruar, çertifikatat e aksesit, vlerësimi i politikës së zbulimit dhe kërkesat e lidhura me qëllimin. Ajo që mungon ende është disiplina për t’i trajtuar ato pjesë si një arkitekturë koherente zbulimi.

Argumenti Kryesor

LDN e ardhshme nuk duhet të pyesë nëse të dhënat mund të zbulohen. Duhet të pyesë:

• Kush po kërkon?
• Për çfarë qëllimi?
• Sipas cilit autoritet?
• Në cilin kontekst?
• Me çfarë pasojash ruajtjeje?

Policia, sportelet e marrjes me qira, punëdhënësit dhe siguruesit nuk janë katër logot në anën tjetër të kërkesës. Janë katër modele të ndryshme rreziku, katër kontekste të ndryshme ligjore, katër arsye të ndryshme për të pyetur — dhe duhet të prodhojnë katër grupe të ndryshme zbulimi.

Kjo nuk është kompleksitet i panevojshëm. Kjo është mënyra si duket një kredencial modern drejtimi kur ndalon trajtimin e çdo verifikuesi si i njëjti verifikues.