Ang hinaharap na Internasyonal na Pahintulot sa Pagmamaneho (IDP) ay nangangailangan ng transparency, mga trust anchor, at pampublikong pananagutan. Ang hindi nito kailangan — bilang default — ay ang paglalagay ng mga driver mismo sa isang distributed ledger.
Sa bawat seryosong talakayan tungkol sa isang digital, cross-border na IDP ay palaging may iisang mungkahi: “Ilagay na lang ito sa blockchain.” Naiintindihan ang apela nito. Nag-aalok ang mga blockchain ng patunay laban sa pagbabago, ibinahaging visibility, at append-only na kasaysayan. Mga tunay na katangian iyon. Ngunit sa konteksto ng cross-border na pagkakakilanlan ng driver, madalas na inilalapat ang mga ito sa maling layer.
Ipinapaliwanag ng artikulong ito kung bakit, tinutukoy kung ano talaga ang sinasabi ng mga pamantayan, at nagtatakda ng mas mahusay na arkitekturang pattern.
Ano Talaga ang Sinasabi ng mga Pamantayan Tungkol sa Blockchain
Malinaw ang W3C Verifiable Credentials Data Model na ang isang verifiable data registry ay maaaring magkaroon ng maraming anyo, kabilang ang:
- Mga pinagkakatiwalaang database
- Mga desentralisadong database
- Mga database ng pagkakakilanlang pang-gobyerno
- Mga distributed ledger
Katulad na ang DID Core: maraming DID method ang gumagamit ng distributed ledger technology, ngunit hindi lahat. Sa madaling salita, tinatanggihan na ng mga pamantayan ang ideya na ang blockchain ay isang mandatoryong pundasyon para sa mga digital na kredensyal.
Iyon ang tamang panimula para sa isang hinaharap na IDP. Ang kapaki-pakinabang na tanong ay hindi “blockchain o walang blockchain?” Kundi:
Aling layer talaga ang nangangailangan ng transparency, at aling layer ang talagang hindi dapat maging pampublikong imprastraktura bilang default?
Ang Blockchain ay Koleksyon ng mga Katangian, Hindi Isang Kinakailangan
Ang unang pagkakamali ay ang pagtrato sa “blockchain” bilang isang solong kinakailangan. Hindi ito ganoon. Ito ay isang bundle ng mga posibleng katangian, kabilang ang:
- Ibinahaging publikasyon
- Append-only na kasaysayan
- Distributed na operasyon
- Pagbuo ng resibo
- Pagtutol sa mga unilateral na pagbabago
Ang ilan sa mga ito ay kapaki-pakinabang para sa isang hinaharap na IDP. Ang ilan ay hindi kaugnay. At ang ilan ay aktibong mapanganib kapag inilapat sa mga taong subject ng kredensyal. Ang W3C registry model ay sadyang nagpapahintulot ng maraming implementasyon dahil ang iba’t ibang ekosistema ay nangangailangan ng iba’t ibang trade-off.
Tatlong Problema na Hindi Dapat Pagsamahin
Ang ikalawang pagkakamali ay ang pagsasama ng tatlong magkaibang problema sa iisang sistema. Para sa isang hinaharap na IDP, kailangan itong manatiling hiwalay:
- Kung saan naninirahan ang legal na katotohanan. Ang karapatang magmaneho ay dapat na nasa mga opisyal na pambansang rekord ng lisensya.
- Paano ipinamamahagi ang mga trust material. Ang mga susi ng nagbibigay at mga sertipiko ng tagaberipika ay dapat nasa mga kontroladong trust registry.
- Paano ino-audit ng ekosistema ang mga pagbabago. Ito ay dapat nasa isang transparency layer.
Ang mga totoong ekosistema sa mundo ay gumagana na sa ganitong paraan. Ang Digital Trust Service ng AAMVA ay namamahagi ng mga pampublikong susi ng nagbibigay sa isang nada-download na listahan bago pa man makipag-ugnayan ang isang tagaberipika sa isang mDL. Tinutukoy ng manwal ng EU para sa mobile driving license na inaabisuhan ng Mga Miyembro ng Estado ang Komisyon tungkol sa mga awtorisadong nagbibigay ng mDL, at inilalathala ng Komisyon ang isang listahan ng pagbeberipika ng mga awtoridad na iyon. Iyon ay pamamahagi ng tiwala nang walang blockchain.
Ano ang Itinuturo sa Atin ng Certificate Transparency
Ang pinaka-epektibong modelo ng transparency sa pampublikong internet ay hindi isang consumer blockchain. Ito ay ang Certificate Transparency (CT).
Inilalarawan ng RFC 9162 ang CT bilang isang protokol para sa pampublikong pag-log ng mga TLS server certificate upang ang sinuman ay maaaring:
- I-audit ang aktibidad ng certification authority
- Matukoy ang mga problemadong o maling inilabas na sertipiko
- I-audit ang mismong mga log
Ang pangunahing aral sa disenyo mula sa CT: ang transparency ay pinaka-mahalaga kapag itinatala nito ang gawi ng nagbibigay at ang mga trust material — hindi ang aktibidad ng end-user.
Inilapat sa isang hinaharap na IDP, nangangahulugan ito ng pag-log ng mga bagay tulad ng:
- Pag-isyu at pag-rotate ng mga susi ng nagbibigay
- Publikasyon ng mga trust anchor
- Pagpaparehistro ng mga kategorya ng tagaberipika
- Mga pagbabago sa patakaran
- Mga pahayag ng pagsunod
- Mga kaganapang may kaugnayan sa seguridad
Ang ibig sabihin nito ay hindi ang paglikha ng isang pampubliko o semi-pampublikong ledger ng mga may hawak, identifier ng kredensyal, o mga kaganapan sa presentasyon. Hindi iyon transparency. Iyon ay labis na koleksyon ng datos.
SCITT: Bakit Hindi Katumbas ng Katotohanan ang Transparency
Pinapalawak ng IETF SCITT architecture draft ang pag-iisip na ito. Tinutukoy ng SCITT ang isang Transparency Service na nagpapanatili ng isang nave-verify na istruktura ng datos at nag-iisyu ng mga cryptographic na resibo na nagpapatunay ng pagsasama ng mga nilagdaang pahayag. Ang pagkakakilanlan ng Transparency Service ay nakuha ng isang pampublikong susi na kilala ng mga relying party, at ang mga trust anchor at mga patakaran sa pagpaparehistro ay ginagawang transparent din.
Ito ay isang makapangyarihang modelo para sa imprastraktura ng IDP dahil ginagawa nitong transparency ang isang ma-audit na serbisyo sa paligid ng trust material at patakaran — hindi sa paligid ng mga personal na kaganapan sa paglalakbay.
Malinaw din ang SCITT tungkol sa mga limitasyon ng transparency:
- Ang isang rehistradong pahayag ay nagpapatunay lamang na ginawa at nirerehistro ito ng isang nagbibigay — hindi na ang pahayag ay tama nang walang katapusan.
- Ang isang mas bagong nilagdaang pahayag ay maaaring palitan ang isang mas lumang pahayag.
- Ang transparency ay hindi pumipigil sa mga hindi tapat o nakompromisong nagbibigay; inihahatid nito sila sa pananagutan.
Para sa pagkakakilanlan ng driver, napakahalaga ng pagkakaibang iyon: ang isang transparency log ay katibayan at kasaysayan ng audit, hindi ang awtorisadong legal na estado ng karapatang magmaneho ng isang tao.
Binanggit din ng SCITT na ang isang transparency service ay maaaring protektahan ang append-only na pagkakasunud-sunod nito gamit ang kumbinasyon ng pinagkakatiwalaang hardware, mga consensus protocol, at cryptographic na katibayan. Kahit ang transparency layer ay hindi nangangailangan ng isang partikular na disenyo ng blockchain. Ang consensus ay isa sa mga opsyon, hindi ang tanging opsyon.
Ang Tamang Arkitekturang Paghihiwalay para sa Hinaharap na IDP
Dapat na paghiwalayin ng isang hinaharap na IDP ang mga alalahanin sa apat na magkaibang layer:
- Mga opisyal na rekord ng sino ang maaaring magmaneho (mga pambansang awtoridad sa pagbibigay ng lisensya)
- Mga trust registry para sa mga susi ng nagbibigay at tagaberipika
- Imprastraktura ng status para sa kasariwaan at pagbabawi
- Isang opsyonal na transparency layer para sa pampublikong audit ng mga patakaran, trust anchor, resibo, at pahayag ng pagsunod
Kapag hinihiwalay mo ang mga layer na ito, nagiging mas malinaw ang tanong tungkol sa blockchain. Hindi na ito “dapat bang nasa blockchain ang hinaharap na IDP?” Nagiging:
Aling layer, kung mayroon man, ang tunay na nakikinabang mula sa append-only na pampublikong audit?
Limang Dahilan Kung Bakit Mali ang On-Chain na Pagkakakilanlan ng Driver Bilang Default
1. Lumilikha Ito ng Matibay na Mga Senyal sa Pagsubaybay
Ipinaliliwanag ng gawain sa privacy ng EUDI na ang mga presentasyon ng attestasyon ay maaaring maglaman ng mga natatanging halaga tulad ng:
- Mga salt
- Mga hash value
- Mga identifier ng pagbabawi
- Mga pampublikong susi ng device binding
- Mga lagda
- Mga timestamp
Dahil ang mga halagang iyon ay naayos para sa parehong attestasyon, pinahihintulutan nito ang mga relying party na mag-link ng iba’t ibang transaksyon at bumuo ng behavioral profile ng user. Tahasan na binabalaan ng EUDI na lumalabag ito sa makatwirang inaasahan na ang magkahiwalay na mga aktibidad sa wallet ay hindi pagsamahin.
Kung maglalathala ka ng mga matatag na identifier ng may hawak, matatag na identifier ng kredensyal, mga maaaring gamitin muli na hash, o mga natatanging nasusubaybayan na kaganapan ng pagbabawi sa isang pampublikong ledger, hindi mo niresolba ang problema sa pagsubaybay — ginagawa mo itong permanente.
2. Inilalantad Nito ang mga Kaganapan ng Pagbabawi at Kasariwaan
Malinaw na inilalarawan ng W3C Bitstring Status List Recommendation ang problema: kung mayroon isang-sa-isang pagmamapa sa pagitan ng isang kredensyal at ang URL kung saan inilathala ang status nito, maaaring ikonekta ng publisher ang may hawak, ang tagaberipika, at ang oras ng pagsusuri. Gumagamit ang spec ng halimbawa ng driver’s license upang ipaliwanag kung bakit ang pagsubaybay ng nagbibigay kapag pumapasok sa isang establisimyento ay lumalabag sa karaniwang inaasahan sa privacy.
Ang mas mahusay na default na iminumungkahi ng Bitstring Status List:
- Malalaking, nako-compress na listahan ng status kung saan maraming kredensyal ang nagbabahagi ng isang status resource
- Default na haba ng listahan na 131,072 entry
- Mga relying party na nag-do-download ng mga bagong bersyon nang hiwalay, nang hindi nagpapatunay ng kanilang sarili
- Mga randomized na index at mga garantiya ng privacy ng grupo
Iyon ay kabaliktaran ng mga indibidwal, on-chain na bakas ng pagbabawi.
3. Inilalito Nito ang Status ng Kredensyal sa Legal na Status sa Pagmamaneho
Ang isang digital na kredensyal ay maaaring bawiin dahil nakompromiso ang mekanismo ng pagpirma nito — kahit na nananatiling balido ang tunay na karapatang magmaneho sa totoong mundo. Ang isang pampublikong ledger ng mga kaganapan ng kredensyal ay hindi isang malinis na kapalit para sa awtorisadong estado ng isang pambansang rekord sa pagmamaneho.
Pinapatibay ng SCITT ang punto: ang isang rehistradong pahayag ay maaaring mapalitan ng bago, at ang mga relying party ay nagpapasya kung ano ang pagkakatiwalaan batay sa patakaran at kasaysayan. Ang log ay hindi permanenteng katotohanan. Ito ay katibayan tungkol sa kung sino ang nagsabi ng ano, kailan, sa ilalim ng anong patakaran. Ang pambansang awtoridad sa pagbibigay ng lisensya ay nananatiling ugat ng legal na katotohanan.
4. Tinutugunan Nito ang Maling Problema sa Pamamahala
Ang cross-border na pagkakakilanlan ng driver ay hindi pangunahing problema sa consensus. Ito ay problema sa pamamahala:
- Sino ang pinapayagang mag-isyu?
- Aling mga pampublikong susi ang kasalukuyan?
- Aling mga tagaberipika ang awtorisado?
- Aling mga kahilingan sa datos ay tugma sa kanilang idineklara na layunin?
- Aling bersyon ng patakaran ang naging bisa sa oras na iyon?
Ang mga tunay na ekosistema ay sumasagot na sa mga ito sa pamamagitan ng pinamamahalaan na imprastraktura ng tiwala, hindi ng desentralisadong consensus:
- Inilalathala ng Digital Trust Service ng AAMVA ang mga pampublikong susi ng awtoridad sa pag-isyu sa isang nada-download na listahan.
- Sinasabi ng manwal ng EU para sa mobile driving license na inilalathala ng Komisyon ang listahan ng mga awtorisadong nagbibigay ng mDL.
- Nagbibigay ang gawain sa sertipiko ng wallet-relying-party ng ETSI ng machine-readable na pagpapatunay ng tagaberipika na may nilalayon na paggamit at mga naka-rehistro na hiniling na katangian.
Iyon ay tahasang pampublikong pamamahala ng tiwala — hindi desentralisadong pamamahala.
5. Hindi Nito Nalulutas ang Katotohanan sa Tabi ng Daan
Maraming panukala sa blockchain ang tahimik na inaasahan na ang live na access sa network ay isang benepisyo. Para sa mga kredensyal ng driver — lalo na sa tabi ng daan o habang naglalakbay — madalas na hindi ito totoo.
Tinutukoy ng gabay sa implementasyon ng AAMVA na:
- Ang pagkuha ng device ay gumagana nang walang koneksyon sa labas para sa parehong may hawak at mambabasa sa oras ng transaksyon.
- Nangangailangan ang ISO/IEC 18013-5 ng suporta para sa pagkuha ng device.
- Ang access ng tagaberipika sa mga pampublikong susi ng nagbibigay ay hindi kailangang mangyari sa oras ng transaksyon. Ang mga susi ay maaaring i-download nang maaga.
Kung makakaberipika na ang isang tagaberipika nang lokal gamit ang naka-cache na trust material, ang isang live na dependency sa blockchain ay hindi mahalaga. Sa pinakamahusay, ito ay isang pagpipilian sa implementasyon para sa ilang backend na audit function.
Ano ang Dapat na Transparent sa Hinaharap na IDP
Ang isang hinaharap na IDP ay talagang nangangailangan ng transparency — sa tamang lugar.
Gawin itong transparent bilang default:
- Mga pampublikong susi ng nagbibigay at mga kaganapan ng key rotation
- Mga trust anchor at listahan ng awtorisadong nagbibigay
- Mga sertipiko ng access ng tagaberipika at metadata ng nakarehistrong layunin
- Mga bersyon ng patakaran at mga panuntunan sa pagpaparehistro
- Mga pahayag ng pagsunod at mga claim ng paglabas ng software na may kaugnayan sa seguridad
- Mga ma-audit na resibo na nagpapatunay na ang mga pahayag na ito ay nairehistro
Huwag gawing pampubliko ito bilang default:
- Mga identifier ng may hawak sa isang pampublikong ledger
- Mga matatag na identifier ng kredensyal na muling ginagamit sa iba’t ibang tagaberipika
- Mga kaganapan bawat presentasyon
- Mga raw na entry ng pagbabawi na nag-iisa sa isang tao
- Mga kumpletong nilagdaang pahayag na naglalaman ng personal na datos kapag sapat na ang mga hash o metadata
Tahasan na binabalaan ng SCITT ang mga nagbibigay na suriin ang pagsasama ng pribado, kumpidensyal, o personal na nakakatukoy na impormasyon bago magsumite ng mga pahayag sa isang transparency service. Binanggit din nito na ang mga transparency service ay maaaring magpanatili lamang ng cryptographic metadata tulad ng mga hash — hindi mga kumpletong nilagdaang pahayag.
Isang Mas Mahusay na Pattern: Transparency sa Paligid ng Ekosistema, Hindi Sa Pamamagitan ng Tao
Ang isang malinis na arkitektura para sa isang hinaharap na IDP ay ganito ang hitsura:
- Awtorisadong pambansang rehistro — nananatiling legal na pinagkukunan ng katotohanan para sa karapatang magmaneho.
- Layer ng kredensyal — nagdadala ng mga machine-verifiable na karapatan sa pagmamaneho sa wallet ng may hawak.
- Layer ng trust registry — namamahagi ng mga susi ng nagbibigay, mga sertipiko ng tagaberipika, at mga listahan ng awtorisadong nagbibigay.
- Layer ng status — gumagamit ng mga short-lived na attestasyon o mga privacy-preserving na listahan ng status na na-refresh nang hiwalay.
- Layer ng transparency — maaaring o hindi gumagamit ng consensus sa loob, at nag-lo-log ng mga trust anchor, pagbabago ng susi, mga update sa patakaran, resibo, at mga pahayag ng ekosistema na nakikinabang mula sa append-only na pampublikong audit.
Kinukuha ng arkitekturang ito ang mga kapaki-pakinabang na bahagi ng pag-iisip sa blockchain — append-only na auditability, pampublikong pagsusuri, patunay laban sa pagbabago, mga resibo — nang hindi ginagawang pampublikong subject ng sistema ang driver. Tumutugma rin ito sa kung ano ang inilalarawan na ng mga pamantayan: ang mga registry ay maaaring magkaroon ng iba’t ibang anyo, ang mga DID ay hindi nangangailangan ng mga distributed ledger, mayroon nang mga trust registry, at ang mga privacy-preserving na mekanismo ng status ay na-standardize na.
Ang Pangunahing Argumento
Dapat na gamitin ng hinaharap na IDP ang pinakamahusay na ideya mula sa blockchain — pampublikong pananagutan para sa imprastraktura — nang hindi ginagamit ang pinakamasamang default nito para sa mga tao: matibay, globally na nakikitang pagsubaybay.
Sa praktika, nangangahulugan ito ng:
- Transparency para sa mga nagbibigay, hindi paglalantad ng mga may hawak
- Mga ma-audit na trust anchor, hindi mga pampublikong rekord ng paglalakbay
- Mga resibo para sa mga patakaran at pagpaparehistro, hindi permanenteng mga timeline ng paggamit ng kredensyal
- Append-only na katibayan para sa pamamahala ng ekosistema, hindi on-chain na pagkakakilanlan ng driver bilang default
Hindi ito argumento laban sa blockchain. Ito ay argumento laban sa paglalapat ng blockchain sa maling layer.
Ang hinaharap na IDP ay maaaring gumamit ng mga consensus-backed na transparency service sa ilang lugar sa ekosistema. Ngunit kung ang disenyo ay nagsisimula sa pamamagitan ng paglalagay ng driver, ng kredensyal, o ng bakas ng presentasyon sa isang ledger, pumili na ito ng maling default.
Nai-publish Mayo 18, 2026 • 13m para mabasa
