Pulisya, mga Kaunter ng Rental, mga Employer, mga Insurer: Bakit Hindi Sila Dapat Makakita ng Parehong Data

Ang pinakamalaking pagkakamali sa disenyo ng isang hinaharap na Internasyonal na Pahintulot sa Pagmamaneho (IDP) ay ang pagtrato sa bawat tagapatunay bilang parehong tagapatunay. Ang isang pulis, isang kaunter ng pagpapaupa ng sasakyan, isang employer, at isang insurer ay hindi nagtatanong ng parehong tanong — kaya hindi sila dapat tumanggap ng parehong sagot.

Isang driver. Isang pangunahing karapatang magmaneho. Isang wallet. Ngunit apat na magkakaibang tagapatunay:

• Isang pulis sa tabi ng daan
• Isang kaunter ng pagpapaupa ng sasakyan sa pickup
• Isang employer na sinusuri ang pagiging karapat-dapat sa fleet
• Isang insurer na nagsusuri ng isang claim

Kung ang hinaharap na IDP ay nagpapakita ng parehong data sa lahat ng apat, ang sistema ay nabigo na. Hindi dahil ang kredensyal ay hindi ligtas, kundi dahil ang modelo ng pagsisiwalat ay masyadong simple.

Ang komunidad ng mga pamantayan ay iniiwan na ang simpleng modelong iyon. Ang gawain ng W3C sa mga nabe-verify na kredensyal ay inilalarawan ang ecosystem sa paligid ng mga nagbibigay, mga may-hawak, at mga tagapatunay, gamit ang mga employer at mga website bilang mga halimbawa ng mga tagapatunay. Ang gawain ng Unyon Europeo sa mobile driving license ay tinatrato na ang mga pagsusuri sa tabi ng daan at mga pagpapaupa ng sasakyan bilang magkahiwalay na mga sitwasyon ng pagpapatunay, kabilang ang malalayong pagbabahagi nang maaga para sa mga rental at personal na pagsusuri para sa pulisya. Ang arkitektura ay dinisenyo na para sa maraming uri ng tagapatunay. Ang pagkakamali ay ang pagdidisenyo ng karanasan ng gumagamit na parang isang uri lamang ang umiiral.

Bakit Tinuruan Tayo ng Pisikal na Kard na Mag-isip nang Mali

Ang isang pisikal na lisensya ay nagturo sa atin ng isang diskarteng ipakita-ang-lahat. Ibinibigay mo ang kard. Nakikita ng kabilang tao kung ano ang nasa kard. Iyon na ang buong interaksyon.

Ang diskarteng iyon ay katanggap-tanggap sa isang mundo ng papel dahil walang alternatibo. Nagiging hindi katanggap-tanggap ito sa isang digital na mundo.

Direktang sinasabi ng W3C VC Data Model 2.0: ang isang lisensya sa pagmamaneho ay maaaring maglaman ng numero ng ID, taas, timbang, kaarawan, at address sa bahay — ngunit maaari pa rin itong maging mas malaki kaysa sa kinakailangan para sa isang partikular na transaksyon. Mga pangunahing punto mula sa mga kasalukuyang pamantayan:

• Pinakamainam na kasanayan ng W3C: suportahan ang selective disclosure, at humiling lamang ng kung ano ang mahigpit na kinakailangan
• Gabay ng Unyon Europeo sa proteksyon ng data: ang pagpoproseso ay dapat limitahan sa mga tinukoy na layunin, at ang data na pinoproseso ay dapat na kinakailangan at proporsyonal
• Ang unang prinsipyo ng isang hinaharap na IDP: ang parehong kredensyal ay hindi nangangahulugang parehong karapatang siyasatin

Ang Tamang Modelo ay ang Pagsisiwalat Batay sa Patakaran

Kung gusto mo ng isang seryosong arkitektura, ang tamang modelo ay mas malapit sa attribute-based access control kaysa sa digital na pagpapakita ng kard.

Tinutukoy ng NIST SP 800-205 ang mga desisyon sa access control bilang mga pagsusuri ng mga katangian na nauugnay sa paksa, bagay, hiniling na operasyon, at mga kondisyon ng kapaligiran, laban sa patakaran. Iyon ay eksakto ang tamang istruktura para sa isang hinaharap na IDP:

• Paksa: ang driver
• Bagay: ang mga hiniling na field ng data
• Aksyon: hindi ang “makita ang lisensya” sa abstract, kundi isang bagay na tiyak tulad ng “i-verify ang karapatang magmaneho ng kategorya B sa tabi ng daan” o “i-verify ang pagiging karapat-dapat sa rental para sa isang booking”
• Kapaligiran: ang tabi ng daan, kaunter ng rental, remote na pre-check, fleet onboarding, at pagsusuri ng claim pagkatapos ng pagkawala ay magkakaibang mga kapaligiran at dapat humantong sa magkakaibang mga desisyon

Nabanggit din ng NIST na ang mga sistema ng katangian ay nangangailangan ng granularity, pamamahala, at mga mekanismo para sa pagbabawas, pagpapangkat, at pagpapaliit ng mga katangian.

Kaya ang hinaharap na IDP ay hindi dapat magtanong: Mababasa ba ng tagapatunay na ito ang lisensya? Dapat itong magtanong: Aling mga claim ang maaaring matanggap ng tagapatunay na ito, para sa aling nilalayong paggamit, sa kapaligiriang ito, na may anong mga patakaran sa pagpapanatili?

Dapat Matukoy ng isang Tagapatunay ang Sarili Nito Bago Humiling ng Anuman

Ang hinaharap na IDP ay hindi dapat magsimula sa wallet na nagpapakita ng data. Dapat itong magsimula sa tagapatunay na nagpapatunay kung sino ito.

Ang arkitektura ng EUDI ay malinaw tungkol dito. Ang mga umaasang partido ay dapat:

• Irehistro ang mga katangiang nilalayon nilang hilingin at para sa anong layunin
• Tumanggap ng mga sertipiko ng access
• Mag-authenticate sa wallet bago ang anumang pagsisiwalat
• Suriin laban sa kanilang nakarehistrong saklaw, kung saan available ang impormasyon sa pagpaparehistro

Ang gumagamit ay maaaring makita kung sino ang nagtatanong, kung ano ang hinihiling, at kung ang kahilingan ay nasa loob ng nakarehistrong saklaw.

Ginagawa ng kasalukuyang gawain ng ETSI sa sertipiko ng wallet-relying-party itong mas kongkreto. Ang isang sertipiko ng pagpaparehistro ng wallet-relying-party ay maaaring ilarawan ang nilalayong paggamit ng relying party at ang mga katangiang nairehistro nito upang hilingin. Ang kaugnay na sertipiko ng access ay umiiral upang matiyak na ang kahilingan ay nagmumula sa isang lehitimo, awtorisadong partido. Kasama rin ng ETSI ang metadata ng relying-party tulad ng:

• Pangalan ng negosyo
• Support URI
• Nilalayong paggamit
• Mga karapatan
• Registry URI
• Impormasyon ng awtoridad sa pangangasiwa

Ang ikalawang prinsipyo ng isang hinaharap na IDP: walang pagkakakilanlan ng tagapatunay, walang pagsisiwalat.

Bakit Hindi Sapat ang mga Screen ng Pahintulot

May isa pang pagkakamali dito: ang pagtrato sa pag-apruba ng gumagamit bilang parehong bagay ng legal na lehitimidad.

Tahasang sinasabi ng arkitektura ng EUDI na ang pag-apruba ng gumagamit na ipresenta ang mga katangian ay hindi dapat ituring na legal na batayan para sa pagpoproseso ng personal na data ng relying party. Ang relying party ay dapat pa ring magkaroon ng sariling legal na batayan. Kinakailangan din ng EUDI ang pag-apruba ng gumagamit sa lahat ng kaso ng paggamit, kabilang ang mga kaso kung saan ang relying party ay maaaring maging bahagi ng pagpapatupad ng batas o ibang ahensya ng gobyerno.

Ang isang magandang interface ng wallet ay maaaring makatulong, ngunit hindi nito maaaring malutas ang labis na pag-abot ng tagapatunay nang mag-isa. Ang panuntunan ay dapat umiiral bago ang interface.

Ang isang hinaharap na IDP ay kailangan ng parehong:

• Cryptographic na pagpapatunay ng tagapatunay upang kumpirmahin kung sino ang nagtatanong
• Mga limitasyon ng patakaran sa kung ano ang maaaring hilingin ng kategoryang iyon ng tagapatunay

Kung wala ang dalawa, ang “pagpipilian ng gumagamit” ay nagiging isang paraan ng paglipat ng kabiguan ng patakaran sa indibidwal.

1. Pulisya: I-verify ang Karapatang Magmaneho, Hindi ang Buong Tao

Ang sitwasyon ng pulisya sa tabi ng daan ay ang pinaka-nakatutok.

Direktang inilalarawan ito ng manuwal ng EU mDL: sinusuri ng pulisya o iba pang mga opisyal ang lisensya kapag kinakailangan, kabilang ang bisa ng lisensya at mga karapatan sa sasakyan. Sa paglalakbay ng gumagamit, bine-verify ng opisyal ang lisensya sa pamamagitan ng isang QR-triggered na daloy, Bluetooth, Wi-Fi Aware, o NFC. Iyon ay isang nakatutok na gawain ng pagpapatunay:

• Ang taong ito ba ang may-hawak?
• Wasto ba ang kredensyal?
• Anong mga karapatan at paghihigpit sa sasakyan ang naaangkop?

Pinahihintulutan bilang default:

• Pangalan
• Larawan
• Katayuan ng lisensya
• Mga petsa ng pagbibigay at pag-expire
• Mga kategorya
• Mga paghihigpit na may kaugnayan sa pagmamaneho
• Nagbibigay at hurisdiksyon
• Resulta ng kasariwaan/katayuan

Hindi pinahihintulutan bilang default:

• Address sa bahay
• Mga panloob na identifier na hindi kailangan para sa paggamit sa tabi ng daan
• Mga walang kaugnayan na katangian mula sa iba pang mga patunay
• Mga log ng makasaysayang pagpapakita
• Commercial na metadata

Pinapalakas ng gabay sa pagpapatupad ng AAMVA ang punto ng larawan: kung ang larawan ay hiniling at anumang iba pang elemento ay inilabas, ang larawan ay dapat ibahagi upang maiugnay ng tagapatunay ang data sa taong nagpapakita nito. Sinasabi rin ng parehong gabay na ang mga stakeholder ay hindi dapat subaybayan ang mga may-hawak ng mDL o ang paggamit ng mDL maliban kung kinakailangan ng batas.

Ang kaso ng pulisya ay hindi tungkol sa estado na tumatanggap ng lahat. Ito ay tungkol sa estado na tumatanggap ng data na tiyak sa pagmamaneho na kailangan para sa pagpapatupad sa tabi ng daan. Iyon ay isang mahalagang pagkakaiba.

2. Mga Kaunter ng Rental: Pagiging Karapat-dapat, Pagtutugma ng Pagkakakilanlan, at Walang Hindi Kinakailangan

Ang kaso ng rental ay mas detalyado dahil may dalawang sandali talaga: remote na pre-check bago dumating, at pickup kapag ang isang tao o kiosk ay nagbibigay ng mga susi.

Mina-modelo na ng manuwal ng EU mDL ang dalawa. Ang isang serbisyo ng pagpapaupa ng sasakyan ay maaaring humiling ng mDL kasama ang patunay ng pagkakakilanlan sa panahon ng pagpapareserba, i-validate ang mga patunay, at kalaunan ay i-verify ang customer nang personal sa pickup bago ilabas ang sasakyan. Maaaring ibahagi ng mga gumagamit ang kanilang mga mDL sa mga kumpanya ng pagpapaupa ng sasakyan nang personal o nang malayo nang maaga.

Ang isang kaunter ng rental ay hindi pangunahing kailangang mag-imbestiga ng isang insidente. Kailangan nitong magpasya: Maaari ko bang ipaaupa ang sasakyang ito sa customer na ito sa ilalim ng booking at patakarang ito?

Ang remote na pre-check ay dapat isama:

• Pagkakaugnay ng pagkakakilanlan
• Larawan o katumbas na elemento ng pagbubuklod ng pagkakakilanlan
• Kaugnay na kategorya ng sasakyan
• Mga petsa ng pagbibigay at pag-expire
• Kasalukuyang bisa
• Posibleng isang threshold ng edad o age band

Dapat kumpirmahin ng pickup:

• Ang may-hawak ay parehong tao na nakumpleto ang pre-check
• Kasalukuyang bisa
• Kaugnay na mga karapatan

Hindi kailangan bilang default:

• Buong address sa bahay kapag ang profile ng booking ay naglalaman na ng mga detalye ng pakikipag-ugnayan
• Buong petsa ng kapanganakan kung saan sapat na ang age-over o age-band
• Mga walang kaugnayan na katangian ng pagkakakilanlan
• Paulit-ulit na muling pagpapakita ng buong kredensyal kung mayroon nang attestation ng booking

Ipinapakita ng kasalukuyang arkitektura ng mDL ng NIST ang relying party na gumagamit ng DCQL upang humiling lamang ng mga kinakailangang katangian, at tahasang sinasabi na sinusuportahan nito ang pagpapaliit ng data at pahintulot ng may-hawak sa pamamagitan ng pagbubuo ng kahilingan kaysa sa pagtrato sa kredensyal bilang isang solong yunit. Idinagdag ng AAMVA na dapat malinaw na ipakita ng aplikasyon kung anong data ang hiniling at kung ang tagapatunay ay nagnanais na panatilihin ang impormasyon.

3. Mga Employer: Isang Kategorya ng Tagapatunay, Hindi isang Pagbubukas sa Buong Pagkakakilanlan

Gumagamit ang pangkalahatang-ideya ng W3C ng digital na sistema ng employer na sinusuri ang isang degree sa unibersidad bilang isang halimbawa ng tagapatunay. Ipinaaalala nito sa atin na ang pagpapatunay ng employer ay isang kilalang pattern na sa mga ecosystem ng kredensyal.

Ang isang employer o operator ng fleet ay maaaring lehitimong kailangang malaman:

• Kung ang isang manggagawa ay kasalukuyang may karapatang magmaneho ng ilang mga kategorya ng sasakyan
• Kung mayroon bang mahahalagang paghihigpit
• Kung ang karapatan ay nananatiling wasto

Iyon ay isang tunay na pangangailangan ng negosyo. Ngunit hindi nito awtomatikong makakatwirang ang permanenteng access sa buong kredensyal sa pagmamaneho, ang buong data ng pagkakakilanlan, o isang tuluy-tuloy na stream ng paulit-ulit na mga pagpapakita.

Binabalaan ng NIST na ang madalas na pagpapadala ng isang muling magagamit na identifier at ang pagsasanay sa mga gumagamit na paulit-ulit na magpakita ng isang kredensyal na may pagkakakilanlan ay hindi kanais-nais, at sinasabi na ang pang-araw-araw na pagpapatunay ay dapat umasa sa mga teknolohiyang dinisenyo para sa pagpapatunay, tulad ng mga passkey. Mas pinipili ng NIST ang lokal na pagpapatunay ng device kaysa sa server-side na biometric matching dahil mas pinoprotektahan nito ang privacy.

Ang isang hinaharap na IDP ay hindi dapat maging isang badge ng access sa lugar ng trabaho.

Para sa paggamit ng employer at fleet, ang tamang pattern ay karaniwang:

• Isang pagsusuri ng karapatan na may kaugnayan sa trabaho
• Marahil ay isang pana-panahong attestation ng pagsunod
• Marahil ay isang claim na ang may-hawak ay nananatiling wasto para sa mga tinukoy na kategorya
• Ngunit hindi isang default na paglipat ng lahat ng data ng lisensya sa tuwing ang empleyado ay nag-sign in sa isang sistema o nagsisimula ng isang shift

Ang pagsunod ng fleet ay isang hiwalay na kategorya ng relying party, na may hiwalay na nilalayong paggamit, at isang hiwalay na profile ng pagsisiwalat.

4. Mga Insurer: Ang mga Claim ay Hindi Pahintulot para sa Patuloy na Visibility

Ang kaso ng insurance ay madalas na tunay. Sa materyal ng kaso ng paggamit ng EU mDL, ang mga insurer ay lumilitaw nang hindi direkta sa sitwasyon ng rental: ang mga kumpanya ng insurance ay nangangailangan ng mga kumpanya ng pagpapaupa ng sasakyan na suriin kung ang taong nag-rerent ng sasakyan ay may karapatang magmaneho. Ang insurance ay nakaka-impluwensya na sa daloy ng pagpapatunay ng pagmamaneho.

Ngunit hindi ito nangangahulugang ang isang insurer ay dapat tumanggap ng parehong data tulad ng pulisya, o isang permanenteng karapatang ma-access ang kredensyal.

Ang isang hinaharap na IDP ay dapat tratuhin ang mga insurer bilang isang hiwalay na kategorya ng tagapatunay na may magkakaibang nilalayong paggamit:

• Underwriting
• Pagpapatunay ng panganib sa rental
• Pamamahala ng claim pagkatapos ng pagkawala
• Pagsusuri ng pandaraya

Iyon ay hindi parehong layunin. Sa ilalim ng mga prinsipyo ng proteksyon ng data ng Unyon Europeo, ang personal na data ay dapat kolektahin para sa mga tinukoy na layunin at limitahan sa kung ano ang kinakailangan at proporsyonal para sa layuning iyon. Ang gabay ng VC ng W3C ay nakaabot sa parehong konklusyon nang teknikal: ang mga tagapatunay ay dapat humiling lamang ng kung ano ang mahigpit na kinakailangan.

Mga lehitimo, event-specific na halimbawa:

• Patunay na ang lisensya ay wasto sa kaugnay na sandali
• Patunay ng kaugnay na karapatan sa sasakyan
• Patunay ng pagkakaugnay ng pagkakakilanlan kung saan kinakailangan para sa isang claim
• Pagsisiwalat na tiyak sa claim

Hindi pinahihintulutan bilang default:

• Patuloy na access sa pinagbabatayang kredensyal
• Paulit-ulit na generic na pagpapatunay sa tuwing ang customer ay nakikipag-ugnayan sa insurer
• Paggamit ng kredensyal sa pagmamaneho bilang isang login token
• Koleksyon ng mga walang kaugnayan na katangian

Ang isang kredensyal sa pagmamaneho ay hindi isang subscription sa pagsubaybay. At hindi ito dapat nang tahimik na maging isa.

Bakit Dapat Makita ang mga Tagapamagitan

Ang mga tunay na merkado ay nagsasangkot ng mga tagapamagitan. Ang mga platform ng rental, mga vendor ng fleet, mga sistema ng HR ng employer, at mga processor ng mga claim ng insurance ay madalas na kumikilos sa pamamagitan ng mga third party.

Hinahawakan ito ng arkitektura ng EUDI sa pamamagitan ng:

• Pagtrato sa mga tagapamagitan bilang mga relying party
• Pag-aatas sa kanila na magparehistro
• Pag-aatas sa mga katangiang hiniling para sa intermediated na relying party na irehistro
• Pagpapakita ng parehong tagapamagitan at ang huling relying party sa gumagamit
• Pagbabawal sa mga tagapamagitan mula sa pag-iimbak ng data tungkol sa nilalaman ng transaksyon

Ang isang hinaharap na IDP ay hindi dapat payagan ang isang pattern kung saan naniniwala ang gumagamit na sila ay nagsisiwalat sa kumpanya ng rental, ngunit sa katotohanan ay nagsisiwalat sila sa isang hindi nakikitang broker ng pagpapatunay, processor ng analytics, at chain ng vendor ng mga claim.

Nakakatulong ang ETSI dito. Ang modelo ng sertipiko ng wallet-relying-party nito ay kinabibilangan ng mga support URI, nilalayong paggamit, mga registry URI, at metadata ng awtoridad sa pangangasiwa. Iyon ang uri ng machine-readable na imprastraktura na kailangan ng mga gumagamit upang maunawaan kung sino talaga ang nasa kabilang dulo ng kahilingan at saan pupunta kapag gusto nilang tanggalin o itama.

Ang Pagpapanatili ay Bahagi ng Kontrol sa Access

Karamihan sa mga talakayan tungkol sa selective disclosure ay nagtatapos nang masyadong maaga. Nakatutok sila sa kung ano ang inisiwalat. Hindi sila nakatutok nang sapat sa kung gaano katagal ito nananatili pagkatapos.

Ang kasalukuyang gabay ay nagtatagpo na:

• AAMVA: ang wallet ay dapat malinaw na sabihin sa may-hawak kung anong data ang hiniling at kung ang tagapatunay ay nagnanais na panatilihin ito; ang mga stakeholder ay hindi dapat subaybayan ang mga may-hawak o ang paggamit ng mDL maliban kung kinakailangan ng batas
• W3C: ang software ng may-hawak ay dapat magbigay ng mga log ng impormasyon na ibinabahagi sa mga tagapatunay, upang matukoy ang mga labis na kahilingan
• EUDI: dapat na ma-access ng mga gumagamit ang mga log ng transaksyon, mag-ulat ng mga kahina-hinalang kahilingan, at humiling ng pagbubura

Ang klase ng pagpapanatili ay dapat maging bahagi ng patakaran sa pagsisiwalat mismo:

• Pulisya sa tabi ng daan: walang pagpapanatili bilang default maliban sa legal na rekord ng operasyon
• Pre-check ng rental: rekord ng transaksyon na nakatali sa booking, hindi isang muling magagamit na kopya ng pagkakakilanlan
• Pagsunod ng fleet ng employer: rekord ng pagsunod o resulta ng attestation, hindi raw na data ng kredensyal
• Claim ng insurer: rekord ng claim na limitado sa claim, hindi permanenteng access

Ang isang hinaharap na IDP na nagtatanaw sa pagpapanatili ay bahagyang nagpoprotekta lamang ng privacy.

Kung Ano ang Tunay na Dapat Pagpasyahan ng Wallet

Kung kailangan kong bawasan ang buong artikulong ito sa isang panuntunan sa pagpapatupad, ito ay ito:

Ang wallet ay hindi dapat sagutin ang “Maaari ko bang ipresenta ang kredensyal na ito?” Dapat itong sagutin ang “Maaari ko bang ipresenta ang hanay ng mga claim na ito sa authenticated na tagapatunay na ito, para sa nilalayong paggamit na ito, sa kontekstong ito, sa ilalim ng klase ng pagpapanatiling ito?”

Ang desisyong iyon ay dapat itakda ng hindi bababa sa mga input na ito:

• Pagkakakilanlan ng tagapatunay
• Kategorya ng tagapatunay
• Nilalayong paggamit
• Nakarehistrong saklaw ng katangian
• Patakaran sa pagsisiwalat mula sa nagbibigay, kung mayroon
• Kapaligiran (tabi ng daan, pickup, remote, fleet, claim)
• Pag-apruba ng may-hawak
• Naaangkop na patakaran sa pagpapanatili

Ang mga pamantayan ay naglalaman na ng malaking bahagi ng makinarya para dito: selective disclosure, pagpapatunay ng relying party, nakarehistrong nilalayong paggamit, mga sertipiko ng access, pagsusuri ng patakaran sa pagsisiwalat, at mga kahilingang nakatali sa layunin. Ang nawawala pa rin ay ang disiplina upang tratuhin ang mga pirasyong iyon bilang isang magkaugnay na arkitektura ng pagsisiwalat.

Ang Pangunahing Argumento

Ang hinaharap na IDP ay hindi dapat magtanong kung ang data ay maaaring isisiwalat. Dapat itong magtanong:

• Sino ang nagtatanong?
• Para sa anong layunin?
• Sa ilalim ng aling awtoridad?
• Sa aling konteksto?
• Na may anong mga kahihinatnan ng pagpapanatili?

Ang pulisya, mga kaunter ng rental, mga employer, at mga insurer ay hindi apat na logo sa kabilang dulo ng isang kahilingan. Sila ay apat na magkakaibang modelo ng panganib, apat na magkakaibang legal na konteksto, apat na magkakaibang dahilan para sa pagtatanong — at dapat silang makagawa ng apat na magkakaibang hanay ng pagsisiwalat.

Iyon ay hindi hindi kinakailangang kumplikasyon. Iyon ang hitsura ng isang modernong kredensyal sa pagmamaneho kapag itinigil nito ang pagtrato sa bawat tagapatunay bilang parehong tagapatunay.