Pa Verifikim "Call-Home": Pse IDP-ja Dixhitale e së Ardhmes Nuk Duhet të Kontaktojë Lëshuesin në Çdo Përdorim

Revokimi është problemi më i vështirë në çdo Leje Ndërkombëtare Drejtimi (IDP) dixhitale të ardhme. Mënyra më e lehtë për ta zgjidhur është edhe më e rrezikshme: ta bësh lëshuesin pjesëmarrës në çdo prezantim të vetëm. Një kredencial modern i drejtimit ndërkufitar duhet ta refuzojë këtë rrugë të shkurtër si parazgjedhje.

Pothuajse çdo propozim i identitetit dixhital përmban të njëjtën fjali qetësuese:

“Kredenciali mund të verifikohet menjëherë.”

Nganjëherë kjo fjali përshkruan përparim të vërtetë. Nganjëherë përshkruan mbikëqyrje me një ndërfaqe më miqësore për përdoruesin.

Standardet e botuara sot e bëjnë të qartë se një verifikues nuk ka nevojë të kontaktojë lëshuesin sa herë që shfaqet një kredencial:

• Arkitektura aktuale mDL e NIST-it thotë se një verifikues mund të vërtetojë autenticitetin dhe integritetin duke u mbështetur në nënshkrimin dhe çelësat publikë të lëshuesit — pa asnjë kontakt të drejtpërdrejtë me lëshuesin.
• AAMVA konfirmon se ISO/IEC 18013-5 kërkon mbështetje për rikuperim nga pajisja dhe vetëm opsionalisht lejon rikuperim nga serveri.
• AAMVA gjithashtu paralajmëron se nën rikuperimin nga serveri, autoriteti lëshues përfshihet në kohë reale në çdo përdorim — që do të thotë se teknikisht mund të regjistrojë kur përdoret kredenciali, cilat të dhëna ndahen, dhe madje të nxjerrë vendndodhjen nga analiza e adresave IP.

Kjo nuk është një shënim i vogël. Është pyetja qendrore e dizajnit për gjeneratën e ardhshme të kredencialeve të drejtimit ndërkufitar.

Shkurtësia e Rrezikshme: Bashkimi i Katër Pyetjeve në një Thirrje të Vetme Rrjeti

Arkitekturat e këqija bashkojnë katër pyetje shumë të ndryshme në një thirrje të vetme të gjallë te lëshuesi:

1. A është ky kredencial autentik?
2. A është personi që e prezanton mbajtësi i ligjshëm?
3. A është vetë kredenciali ende i vlefshëm?
4. A është e drejta themelore kombëtare e drejtimit ende në fuqi?

Një sistem i dizajnuar keq i përgjigjet të katër pyetjeve duke “telefonuar shtëpinë” në kohë reale. Një sistem i dizajnuar mirë i ndan ato — sepse nuk janë e njëjta problem dhe nuk duhet të ndajnë të njëjtin mekanizëm.

Autenticiteti Duhet të Verifikohet Lokalisht, Jo Nëpërmjet Rrjetit

Një kredencial mund të jetë kriptografikisht i vërtetë pa u njoftuar kurrë lëshuesit për transaksionin.

• Modeli i besimit mDL i NIST-it thotë se autenticiteti dhe integriteti vërtetohen nga nënshkrimi dhe çelësat publikë të lëshuesit — nuk kërkohet kontakt i gjallë me lëshuesin.
• Shërbimi i Besimit Dixhital i AAMVA-s ekziston pikërisht për t’u dhënë verifikuesve qasje në çelësat publikë të vlefshëm të lëshuesit pa thirrje kthyese për çdo transaksion.

Parimi i Dizajnit 1: Mos përdor lidhje të gjallë për të zgjidhur një problem që nënshkrimet e zgjidhin tashmë.

Nëse një verifikues mban çelësa të besuar lëshuesish dhe merr një prezantim në përputhje me standardet, autenticiteti është një kontroll kriptografik lokal, jo një varësi nga rrjeti.

Lidhja me Mbajtësin Duhet të Provohet Lokalisht, Jo të Raportohet Globalisht

Pyetja e dytë — a është ky mbajtësi i ligjshëm? — ka gjithashtu një përgjigje pa rrjet.

Arkitektura aktuale EUDI mandaton lidhjen e pajisjes për PID-et dhe vërtetimet ISO/IEC 18013-5. Verifikuesi i kërkon portoflit të nënshkruajë një sfidë të freskët duke përdorur çelësin privat që korrespondon me çelësin publik të ngulitur në kredencial:

• Në ISO/IEC 18013-5 kjo quhet vërtetim mdoc.
• Në SD-JWT VC quhet lidhje çelësi.

Në të dyja rastet, zotërimi provohet lokalisht dhe kriptografikisht. Asnjë të dhënë personale nuk ka nevojë të arrijë tek lëshuesi.

Parimi i Dizajnit 2: Provo zotërimin lokalisht. Mos provo identitetin globalisht.

Një IDP e ardhshme duhet të shterë lidhjen e pajisjes, vërtetimin lokal të mbajtësit dhe sfidë-përgjigjen e verifikuesit para se të marrë parasysh çdo mekanizëm nga ana e lëshuesit.

Statusi i Kredencialit dhe Statusi i të Drejtës së Drejtimit Janë Dy Gjëra të Ndryshme

Shumë dizajne të identitetit dixhital e ngatërrojnë këtë dallim, dhe aty gabojnë.

Specifikimet e Bitstring Status List të W3C-it e bëjnë pikën qartë: informacioni i statusit i bashkangjitur një kredenciali të verifikueshëm vlen për vetë kredencialin e verifikueshëm — jo domosdoshmërisht për të drejtën themelore në botën reale. Një kredencial dixhital mund të revokohet sepse mekanizmi i tij i nënshkrimit u komprometua, ndërkohë që e drejta themelore e drejtimit mbetet plotësisht e vlefshme.

Prandaj, një IDP e ardhshme ka nevojë për dy shtresa të ndryshme statusi:

• Shtresa e statusit të kredencialit — për vetë kredencialin dixhital ose kanalin e prezantimit.
• Shtresa e të drejtës së drejtimit — për të drejtën themelore kombëtare për të drejtuar.

Ndonjëherë këto ndryshojnë së bashku. Shpesh nuk ndryshojnë. Një sistem që i ngatërron ato do të reagojë tepër, do të ekspozojë më shumë të dhëna se sa nevojitet, ose të dyja.

Kompromisi i Portofolit Duhet të Përhapet Nëpërmjet Statusit — Jo të Shkaktojë Thirrje Kthyese të Verifikuesit

Një IDP e ardhshme ka nevojë gjithashtu për një përgjigje të qartë për çfarë ndodh kur një portofol komprometohet.

Arkitektura EUDI ofron një:

• Ofruesi i portofolit lëshon Vërtetime të Njësisë së Portofolit që përmbajnë informacion revokimi.
• Integriteti i portofolit ri-verifikohet me kalimin e kohës; nëse një portofol nuk është më i sigurt, vërtetimi i tij revokohet.
• Ofruesit e PID-it duhet të kontrollojnë rregullisht nëse portofoli është revokuar. Nëse është, ata revokojnë PID-in.
• Duke verifikuar statusin e PID-it, pala mbështetëse implicitisht verifikon statusin e portofolit.

Ky është shtresëzimi që duhet të adoptojë një IDP e ardhshme. Mos kërkoni nga çdo verifikues të kontrollojë në mënyrë të pavarur ofruesin e portofolit. Lini kompromisin e portofolit të përhapet nëpërmjet tubacionit ekzistues të statusit të kredencialit, dhe lini verifikuesit të konsultojnë atë kanal të vetëm të ruajtjes së privatësisë.

Tre Modele Revokimi të Realizueshme (Pa Thirrje Kthyese të Nevojshme)

EUDI kërkon nga ofruesit të përdorin një nga tre metodat e revokimit:

• Vërtetime afatshkurtra — të vlefshme për 24 orë ose më pak, kështu revokimi bëhet i panevojshëm.
• Lista e Statusit të Vërtetimit — një listë e publikuar që verifikuesit mund ta konsultojnë.
• Lista e Revokimit të Vërtetimit — një listë eksplicite e kredencialeve të revokuara.

Për vërtetime të vlefshme më gjatë se 24 orë, EUDI kërkon ngulitur informacion revokimi që përfshin:

• Një URL ku palët mbështetëse mund të marrin listën e statusit.
• Një identifikues që gjen kredencialin brenda asaj liste.

Nëse informacioni i besueshëm i revokimit është i padisponueshëm — për shembull, kur pala mbështetëse është jashtë linje — EUDI i drejton palët mbështetëse të kryejnë një analizë rreziku para se të pranojnë ose refuzojnë kredencialin.

Mesazhi kryesor: revokimi nuk është një mekanizëm i vetëm, dhe sigurisht nuk është një justifikim për thirrje kthyese të detyrueshme të lëshuesit.

Afatshkurtër si Parazgjedhje, Afatgjatë Vetëm Kur Nevojitet

Një nga masat më efektive të privatësisë në të gjithë grupin është gjithashtu më e thjeshta: mbaj çfarë prezantohet afatshkurtër.

• EUDI thotë se vërtetime të vlefshme për 24 orë ose më pak nuk kërkojnë infrastrukturë revokimi — ato skadojnë para se revokimi të kishte rëndësi.
• W3C thotë se prezantimet e verifikueshme janë zakonisht afatshkurtra dhe nuk janë projektuar për ruajtje afatgjatë.
• NIST paralajmëron në mënyrë eksplicite kundër transmetimit të përsëritur të identifikuesve të ripërdorshëm për përdorim të përditshëm. Vërtetimi i përditshëm duhet të mbështetet në teknologji të ndërtuara për atë qëllim, si çelësat e kalimit, jo prezantimi i përsëritur i një kredenciali të pasur me identitet.
• NIST gjithashtu zgjodhi vërtetimin lokal të pajisjes mbi përputhjen biometrike nga ana e serverit pikërisht sepse vërtetimi lokal ruan privatësinë dhe është operacionalisht më efikas.

Parimi i Dizajnit 3: Kredenciali bazë mund të ketë një periudhë vlefshmërie të mesme, por vetë prezantimi duhet të jetë afatshkurtër, specifik për verifikuesin dhe i paripërdorshëm.

Listat e Statusit Janë Mekanizmi i Duhur i Parazgjedhur

Kur nuk mund t’i mbash të gjitha afatshkurtra, ke nevojë për infrastrukturë statusi — dhe lista e statusit është parazgjedhja e duhur.

Bitstring Status List v1.0 e W3C-it përshkruan një mekanizëm me ruajtje privatësie, hapësiror efikas dhe me performancë të lartë për publikimin e të dhënave të statusit si pezullimi ose revokimi. Vetitë kryesore përfshijnë:

• Çdo lëshues menaxhon një listë për kredencialet që ka lëshuar.
• Formati kompresohet mirë, pasi shumica e kredencialeve mbeten të parevokuara.
• Madhësia e parazgjedhur e listës është 131.072 hyrje, të cilat W3C thotë se sigurojnë privatësi grupore të duhur në rastin mesatar.
• Lista më të mëdha mund të përdoren kur nevojitet privatësi grupore më e fortë.

Kjo e zhvendos pyetjen nga:

“A mund të pyes lëshuesin për këtë përdorues tani?”

te:

“A kam tashmë një listë statusi me ruajtje privatësie mjaftueshëm të freskët për të vendosur lokalisht?”

Kjo është një pyetje shumë më e mirë — si teknikisht ashtu edhe politikisht.

“Pa Call-Home” Është një Model Shkarkimi, Jo një Slogan

Rregulli më i rëndësishëm në udhëzimet e privatësisë së EUDI-t është procedural, jo filozofik.

Palët mbështetëse nuk duhet të kërkojnë listën e statusit sa herë që prezantohet një kredencial. Në vend të kësaj, ato duhet të:

• Shkarkojnë çdo version të ri të listës një herë.
• Ta bëjnë këtë në një kohë dhe nga një vendndodhje pa lidhje me asnjë prezantim përdoruesi.
• Shpërndajnë listën brenda organizatës së palës mbështetëse.
• Marrin listën pa vërtetuar palën mbështetëse.

Ky është bërthama operacionale e verifikimit pa thirrje kthyese: rifresko statusin veçmas nga prezantimet e përdoruesit — asnjëherë për person, asnjëherë për transaksion.

Ky zgjedhje e vetme dizajni parandalon lëshuesin ose ofruesin e statusit të mësojë se cili verifikues kontrolloi cilin kredencial në çfarë momenti.

Privatësia Grupore: Kërkesa që Shumica e Dizajneve e Harrojnë

Shumë sisteme reklamojnë zbulimin selektiv brenda vetë prezantimit, pastaj injorojnë në heshtje privatësinë e kërkimeve të statusit. Kjo është një boshllëk i rëndësishëm.

Kërkesat e privatësisë së EUDI-t specifikojnë se:

• Indekset në listat e statusit duhet të caktohen rastësisht, kështu që indeksi vetë nuk bëhet kurrë sinjal gjurmimi.
• Çdo listë duhet të mbulojë një numër mjaftueshëm të madh kredencialesh për të siguruar privatësinë grupore.
• Nëse një listë do të ishte ndryshe shumë e vogël, ofruesit duhet të shtojnë hyrje të papërdorura për të fshehur numrin real të kredencialeve.

Një IDP e ardhshme nuk mund të pretendojë se ruan privatësinë vetëm në bazë të zbulimit selektiv. Nëse mekanizmi i revokimit rrjedh eventin e prezantimit, dizajni i privatësisë është i paplotë.

Operimi Jashtë Linje Nuk Është Rast i Veçantë — Është Kërkesë Themelore

Çdo sistem udhëtimi që presupozon lidhje të përsosur është dizajnuar keq.

• AAMVA konfirmon se rikuperimi nga pajisja funksionon pa lidhje të jashtme si për pajisjen e mbajtësit ashtu edhe për lexuesin, dhe se ISO/IEC 18013-5 kërkon që mDL-et të mbështesin rikuperimin nga pajisja.
• EUDI pranon se palët mbështetëse mund të jenë jashtë linje dhe t’u mungojë një listë statusi e ruajtur në memorie, në të cilin rast rekomandon një analizë rreziku para vendimmarrjes.

Pranoje këtë kompromis herët:

Nuk mund të kesh operim të përsosur jashtë linje dhe freski të përsosur në kohë reale njëkohësisht.

Çdo arkitekturë që premton të dyja pa kompromis ose është e paprecize ose po rifut në heshtje mbikëqyrjen. Përgjigja e duhur është ta bësh freskinë një hyrje politike, jo një varësi universale nga rrjeti.

Regjistrat Janë Vendi Ku Privatësia Dështon në Heshtje

Edhe një arkitekturë e shkëlqyer statusi mund të prishet nga regjistrimi i pakujdesshëm.

• EUDI kërkon nga instancat e palëve mbështetëse të heqin elementet unike dhe vulat kohore sa më shpejt të mos nevojiten më, dhe ndalon përcjelljen e tyre.
• AAMVA ndalon palëve të interesuara të gjurmojnë mbajtësit e mDL-it ose përdorimin e mDL-it përveçse kur kërkohet me ligj, kërkon nga autoritetet lëshuese të minimizojnë ndarjen e meta të dhënave statike ose afatgjata, dhe kufizon qasjen në regjistrin e aktivitetit vetëm për mbajtësin.
• AAMVA gjithashtu kërkon që fshirja nga pajisja të heqë informacionin e regjistrit dhe meta të dhënat që mund të zbulojnë historikun e përdorimit — dhe se kjo fshirje duhet të jetë e mundur jashtë linje.

Kjo është sjellje protokollare, jo mirëmbajtje administrative. Një IDP e ardhshme duhet t’i trajtojë identifikuesit afatgjatë, vulat kohore dhe regjistrat si mjete potenciale gjurmimi nëse nuk provohet ndryshe në mënyrë eksplicite.

Një Arkitekturë Konkrete Pa Thirrje Kthyese për IDP-në e Ardhshme

Duke bashkuar parimet, kjo është ajo që sistemi duhet të bëjë konkretisht:

1. Lësh një kredencial bazë të lidhur me pajisjen. Lidh kredencialin me çelësa të mbrojtur në mjedisin e sigurt të portofolit — i detyrueshëm nën EUDI për PID-et dhe vërtetime ISO/IEC 18013-5.
2. Kërko vetëm çfarë nevojitet, me një sfidë të freskët. Në një transaksion OpenID4VP, një pyetësor DCQL i lejon portofolit t’i tregojë mbajtësit cilat atribute po kërkohen, dhe verifikuesi lëshon një sfidë për të parandaluar riprodhimin (sipas arkitekturës aktuale mDL të NIST-it).
3. Gjenero një prezantim afatshkurtër, jo një identifikues të ripërdorshëm. Çdo prezantim duhet të jetë specifik për verifikuesin, kërkesën dhe momentin.
4. Verifiko autenticitetin lokalisht. Valido nënshkrimet dhe çelësat publikë të lëshuesit jashtë linje; shërbimi i besimit i AAMVA-s është ndërtuar pikërisht për këtë.
5. Kontrollo statusin nga listat e ruajtura në memorie, të rifrestruara veçmas. Kur kredencialet janë shumë afatgjata për të anashkaluar revokimin, përdor lista statusi të ruajtura lokalisht të rifrestruara sipas një orari të palidhur me prezantimet e përdoruesit.
6. Zbato një politikë rreziku kur freskia nuk është e disponueshme. Bëi vendimet jashtë linje politikë eksplicite të verifikuesit, jo hamendje të pastrukturuar.
7. Fshi të dhënat e gjurmimit në mënyrë agresive. Hidh elementet unike të transaksionit dhe vulat kohore kur nuk nevojiten më; mos mbaj regjistrat që mund të rindërtojnë historikun e lëvizjes.

Kjo është pamja e një arkitekture serioze pa thirrje kthyese — të shtresëzuar, me ruajtje privatësie, kriptografikisht lokale dhe operacionalisht të ndershme për realitetin jashtë linje.

Tre Modele që Duhet të Ndalohen nga Dizajni

Një ekosistem i maturuar IDP e ardhshme duhet t’i trajtojë këto si dështime arkitekturale, jo zgjedhje optimizimi:

• Thirrje kthyese të detyrueshme të lëshuesit në çdo prezantim. Udhëzimi i privatësisë i vetë AAMVA-s shpjegon pse kjo është e dëmshme.
• Përdorimi i kredencialit të drejtimit si hyrje rutinë. NIST paralajmëron në mënyrë eksplicite kundër prezantimit të përsëritur të kredencialeve me identitet për vërtetim të përditshëm.
• Mbajtja e identifikuesve, vulave kohore dhe regjistrave që mund të rindërtojnë historikun e prezantimit. Si EUDI ashtu edhe AAMVA kërkojnë të kundërtën.

Argumenti Kryesor në një Fjali

Verifikimi i menjëhershëm nuk duhet të bëhet leje për mbikëqyrje nga ana e lëshuesit.

Një IDP e ardhshme duhet të jetë në gjendje të:

• Provojë autenticitetin lokalisht.
• Provojë zotërimin lokalisht.
• Kontrollojë freskinë privatisht.
• Tolerojë realitetin jashtë linje.
• Funksionojë me hir kur informacioni i përsosur nuk është i disponueshëm.

Asgjë nga kjo nuk e bën sistemin më të dobët. E bën të vlefshëm për t’u vendosur në shkallë.

Momentin që një kredencial drejtimi bëhet mjet për të regjistruar kush tregoi çfarë, ku dhe kur, ai ndalon së qeni një version më i sigurt i letrës. Bëhet infrastrukturë për vëzhgim.

Kjo është pikërisht ajo që IDP-ja e ardhshme duhet të refuzojë të bëhet.

Pyetje të Shpeshta

Çfarë është “verifikimi call-home”?
Është çdo dizajn në të cilin një verifikues kontakton lëshuesin në kohë reale për të vërtetuar një kredencial. Ndërkohë që zgjidh njëkohësisht autenticitetin dhe revokimin, lejon gjithashtu lëshuesin të vëzhgojë çdo event prezantimi.

A kërkon ISO/IEC 18013-5 kontakt të lëshuesit në internet?
Jo. AAMVA konfirmon se ISO/IEC 18013-5 kërkon mbështetje për rikuperim nga pajisja dhe vetëm opsionalisht lejon rikuperim nga serveri.

Si mund të funksionojë revokimi pa kontaktuar lëshuesin?
Nëpërmjet kredencialeve afatshkurtra, listave të statusit të vërtetimit ose listave të revokimit të vërtetimit — idealisht me palën mbështetëse duke shkarkuar të dhënat e statusit veçmas nga prezantimet e përdoruesit.

Pse është “privatësia grupore” e rëndësishme për listat e statusit?
Nëse një listë statusi është shumë e vogël ose indekset e saj janë të parashikueshme, një kërkesë statusi mund të zbulojë se cili kredencial specifik u prezantua. Indekset rastësore dhe listat e mëdha e parandalojnë këtë.

A është verifikimi jashtë linje vërtet praktik?
Po — dhe organet e standardeve duke përfshirë AAMVA-n dhe EUDI-n e kërkojnë atë në mënyrë eksplicite. Kompromisi është se freskia e përsosur në kohë reale është e papajtueshme me operimin e përsosur jashtë linje, kështu që freskia duhet të bëhet një vendim politike, jo një varësi e fortë.