Ang Stack sa Likod ng Hinaharap na IDP: Bakit Kailangan ng Layered Standards Architecture para Mapalitan ang Paper Permit

Walang iisang pamantayan ang makakapalit sa papel na International Driving Permit (IDP). Ang tunay na kapalit nito ay isang stack ng mga pamantayang nagtatrabaho nang magkakasama — at ang pag-unawa sa stack na iyon ang susi sa pag-unawa kung saan talaga patungo ang cross-border digital driving credentials.

Bakit Walang Iisang Pamantayan ang Makakapalit sa Papel na IDP

Karamihan sa mga talakayan tungkol sa hinaharap na IDP ay nagsisimula sa maling tanong: alin na pamantayan ang makakapalit sa papel na permit? Ipinapalagay ng ganitong paraan na kaya ng isang detalye na gawin ang buong trabaho. Hindi kaya.

Hayagang binabanggit ng gawain ng NIST sa mDL (mobile driving license) na ang mga bagong pamantayan ng digital credential ay lumalabas sa magkakahiwalay na lugar ng problema. Ang pamilyang ISO 18013 mismo ay nahati na sa maraming bahagi na sumasaklaw sa disenyo ng pisikal, seguridad, mobile na presentasyon, at mga internet na extension. Ang isang hinaharap na cross-border driving credential ay hindi samakatuwid isang detalye — ito ay isang koordinadong stack ng mga detalye, na ang bawat isa ay humahawak ng natatanging alalahanin.

Ang Hinaharap na IDP Stack sa Isang Tingin

Narito ang walong layer na, kung sama-samahin, ay nagtatakda ng hitsura ng isang hinaharap na IDP:

Layer 0 — Pisikal at data na pundasyon: ISO/IEC 18013-1
Layer 1 — Seguridad ng credential: ISO/IEC 18013-3
Layer 2 — Proximity (personal) na presentasyon: ISO/IEC 18013-5
Layer 3 — Remote / internet na presentasyon: ISO/IEC 18013-7
Layer 4 — Semantika ng credential: W3C Verifiable Credentials Data Model 2.0
Layer 5 — Protokol ng issuance: OpenID4VCI
Layer 6 — Protokol ng kahilingan at presentasyon: OpenID4VP
Layer 7 — Pamamahagi ng tiwala at awtorisasyon ng verifier: Mga trust registry (VICAL na modelo ng AAMVA, ang EUDI certificate-based na modelo ng relying-party)

Ang bawat layer ay nakabatay sa mga kasalukuyang pamantayan o aktibong dokumentasyon ng ecosystem. Ang mga seksyon sa ibaba ay nagpapaliwanag kung ano ang ginagawa ng bawat layer — at, kapareho ng kahalagahan, kung ano ang hindi nito ginagawa.

Layer 0 — ISO/IEC 18013-1: Ang Pisikal at Semantikong Pundasyon

Ang Bahagi 1 ay mas mahalaga kaysa sa naisip ng karamihan, dahil hindi lamang ito tungkol sa disenyo ng kard.

Tinutukoy ng ISO/IEC 18013-1 ang mga pisikal na katangian at pangunahing set ng datos ng isang ISO-compliant na lisensya sa pagmamaneho, na lumilikha ng karaniwang batayan para sa internasyonal na paggamit at mutual recognition. Ito ay itinayo sa paligid ng isang secure na ID-1 na kard na sinasamahan ng isang booklet para sa internasyonal na paggamit, na pinapalitan ang mas lumang papel na modelo ng IDP. Tinutukoy rin ng ISO na sa maraming kaso, ang isang kard ay maaaring makapalit sa pangangailangan para sa dalawang magkahiwalay na dokumento.

Ang praktikal na implikasyon ay simple: ang hinaharap na IDP ay hindi maaaring magsimula sa layer ng wallet. Kung ang pinagbabatayan na istraktura ng dokumento, modelo ng datos, at layout ay hindi muna na-standardize, ang bawat digital na layer sa itaas ay nagiging isang compatibility patch sa mga naka-fragment na pambansang format. Ang Bahagi 1 ang pundasyon na umaasa ang natitirang stack.

Layer 1 — ISO/IEC 18013-3: Seguridad ng Credential

Ang Bahagi 3 ang lugar kung saan ang credential ay nagbabago mula sa pagiging data sa isang dokumento patungong isang security object. Inilalarawan ng ISO ang 18013-3 bilang bahagi na nagtatakda ng mga mekanismo para sa:

Kontrol sa pag-access sa machine-readable na datos
Pagpapatunay ng dokumento
Pagpapatunay ng integridad

Malinaw rin ang ISO, gayunpaman, na ang Bahagi 3 ay hindi tumutugon sa mga isyu ng privacy na may kaugnayan sa susunod na paggamit ng datos — at ang hangganan na iyon ay mahalaga.

Sa madaling salita, ang 18013-3 ay naghahatid ng seguridad ng credential, hindi buong pamamahala ng ecosystem. Tinutulungan itong sagutin ang mga tanong tulad ng: Ang credential na ito ba ay inisyu ng sinasabing awtoridad? Ang datos ba ay nabago? Hindi nito ganap na nasasagot: Dapat bang humiling ang verifier na ito ng field na ito? Dapat bang payagan ang kahilingang ito sa kontekstong ito?

Ito rin ay isang aktibong layer kaysa sa isang natapos na produkto. Inilista ng ISO ang isang 2022 na amendment para sa protokol ng PACE, isang 2023 na amendment para sa mga update ng passive authentication, at isang bagong draft ng 18013-3 na kasalukuyang nasa ilalim ng pagbuo.

Layer 2 — ISO/IEC 18013-5: Personal na Mobile na Presentasyon

Kung tinutukoy ng Bahagi 1 ang dokumento at sine-secure ng Bahagi 3 ito, ginagawang mobile credential ng Bahagi 5 ang lisensya.

Tinutukoy ng ISO na ang 18013-5 ay sumasaklaw sa interface sa pagitan ng mDL at ng reader, at sa pagitan ng reader at ng imprastraktura ng awtoridad na nag-isyu. Pinapayagan din nito ang mga third party — kabilang ang mga awtoridad at verifier sa ibang bansa — na:

Makakuha ng datos ng mDL sa pamamagitan ng makina
Ikonekta ang datos na iyon sa may-hawak
Patunayan ang pinagmulan nito
I-verify ang integridad nito

Ang hindi saklaw ng 18013-5 ay pantay na mahalaga. Hayagang inilista ng ISO ang mga out-of-scope na item, kabilang ang kung paano nakuha ang pahintulot ng may-hawak na ibahagi ang datos at ang mga kinakailangan para sa pag-iimbak ng datos ng mDL at mga pribadong key. Ang Bahagi 5 ay hindi isang kumpletong produkto ng wallet, hindi isang kumpletong modelo ng pahintulot ng gumagamit, at hindi isang kumpletong sistema ng pamamahala. Ito ang layer ng transportasyon at pag-verify para sa mobile na presentasyon.

Ang gabay sa implementasyon ng AAMVA ay nagpapatalas pa nito sa pamamagitan ng pagtatangi sa pagitan ng dalawang modelo ng pagkuha:

Device retrieval, kung saan ang datos ay direktang binabasa mula sa device ng may-hawak.
Server retrieval, na maaaring payagan ang awtoridad na nag-isyu na obserbahan kung kailan ginagamit ang mDL, anong datos ang ibinabahagi, at maging ang pagtatantya ng pisikal na lokasyon sa pamamagitan ng pagsusuri ng IP.

Ang pangalawang punto na iyon ay hindi isang dahilan para tanggihan ang pamantayan — ito ay isang dahilan para maging tumpak tungkol sa kung aling modelo ng pagkuha ang dapat gamitin ng isang hinaharap na IDP bilang default. Hinihiling din ng AAMVA na ang wallet ay magbigay sa may-hawak ng buong kontrol sa kung aling mga elemento ng datos ang ibabahagi, na mas angkop para sa isang hinaharap na IDP kaysa sa mas lumang modelong “ipakita ang buong dokumento”.

Layer 3 — ISO/IEC 18013-7: Presentasyon sa Internet

Niresolba ng Bahagi 5 ang problema sa personal. Pinalawak ng Bahagi 7 ang modelong iyon sa remote na paggamit.

Inilalarawan ng ISO ang 18013-7:2025 bilang pagpapalawak ng 18013-5 na may internet na presentasyon ng isang mDL sa isang reader. Ang internet ay hindi isang pangalawang konsiderasyon sa arkitektura na ito; ito ay isang malinaw na bahagi ng pamantayan.

Tinatrato na ng manwal ng EU para sa mobile driving license ang internet na presentasyon bilang praktikal kaysa sa teoretikal, na naglalarawan ng mga senaryo tulad ng:

Pag-check-in sa pag-renta ng sasakyan, kung saan ibinabahagi ng mga gumagamit ang kanilang mDL alinman sa personal o nang malayo nang maaga
Mga pagsusuri sa tabi ng daan ng pulisya
Isang pangkalahatang profile sa paggamit ng mDL na itinayo sa ISO/IEC 18013-5 at 18013-7

Gayunpaman, ang kasalukuyang gabay ng AAMVA ay tapat tungkol sa mga limitasyon: ang paggamit ng mDL sa internet ay lubos na kanais-nais, ngunit ang ilang sumusuportang pamantayan ay patuloy pa ring umuunlad. Mayroong tunay na mga agwat sa kasalukuyang integrasyon ng wallet-to-browser, at nang wala ang listahan ng mga pinagkakatiwalaang reader, ang panig ng mdoc ay maaaring walang maaasahang paraan upang makumpirma ang ilang partikular na katangian ng seguridad. Ang remote na presentasyon ay totoo — at patuloy pa ring umuunlad.

Kahit sa mga pag-iingat na iyon, ang 18013-7 ang unang seryosong sagot sa isang problemang hindi man lang sinubukan ng papel na IDP na resolbahin: ang pagpapakita ng mga karapatan sa pagmamaneho nang malayo, bago pa man makarating ang tao sa counter o checkpoint.

Layer 4 — W3C VC Data Model 2.0: Ang Layer ng Semantika

Ang W3C Verifiable Credentials Data Model 2.0 ay hindi isang pamantayan ng lisensya sa pagmamaneho — at iyon mismo ang dahilan kung bakit ito mahalaga.

Tinutukoy ng Rekomendasyon ang isang extensible na modelo ng datos para sa mga verifiable credential, nagpapaliwanag kung paano sila mapoprotektahan mula sa pagbabago, at inilalarawan ang ecosystem sa pamamagitan ng tatlong pangunahing papel: mga issuer, may-hawak, at mga verifier. Ang isang lisensya sa pagmamaneho ay lilitaw bilang isa sa mga pangunahing halimbawa nito.

Para sa isang hinaharap na IDP, ang VC 2.0 ay nag-aambag ng pangkalahatang bokabularyo para sa mga claim, presentasyon, at mga verifiable data registry. Malinaw ang W3C na ang mga ganitong registry ay maaaring magkaroon ng ilang anyo, kabilang ang:

Mga pinagkakatiwalaang database
Mga database ng pagkakakilanlan ng gobyerno
Mga desentralisadong database
Mga distributed ledger

Sinisira nito ang maling pagpili sa pagitan ng isang blockchain-only na diskarte at isang ganap na proprietary na isa. Ang modelo ng datos ay mas malawak kaysa sa alinman.

Malinaw din ang VC 2.0 tungkol sa selective disclosure. Binabanggit ng W3C na ang isang lisensya sa pagmamaneho ay maaaring magdala ng higit pang datos kaysa sa kinakailangan para sa isang partikular na kaso ng paggamit, at inirerekomenda alinman ang paghahati ng impormasyon sa mas maliliit na piraso o ang paggamit ng mga mekanismo na nagbibigay-daan sa selective disclosure. Para sa isang hinaharap na IDP, hindi ito isang opsyonal na kaginhawahan sa privacy — ito ang pagkakaiba sa pagitan ng isang modernong credential at isang digital na kopya ng isang plastic na kard.

Ang VC 2.0, gayunpaman, ay hindi isang kumpletong kapalit para sa ISO 18013. Tinutukoy ng W3C na ang modelo ng datos ay hindi nangangailangan ng tradisyonal na certificate-authority chain-of-trust na modelo. Sa praktika, ang VC 2.0 ay isang malakas na layer ng semantika, ngunit ang mga malinaw na layer ng pamamahagi ng tiwala at pamamahala ng verifier ay kailangang nasa ibabaw pa rin.

Layer 5 — OpenID4VCI: Ang Protokol ng Issuance

Ang isang hinaharap na IDP ay nangangailangan ng pamantayang paraan upang ilipat ang isang credential mula sa isang issuer patungo sa isang wallet. Iyon ang papel ng OpenID para sa Verifiable Credential Issuance (OpenID4VCI) 1.0.

Tinutukoy ng detalye ang isang API na protektado ng OAuth para sa pag-isyu ng mga verifiable credential, at sadyang independyente sa format. Kabilang sa mga format ng credential na sinusuportahan nito:

ISO mdoc
SD-JWT VC
Mga credential ng W3C VCDM

Sinusuportahan din nito ang holder binding at mga susunod na presentasyon nang wala pang karagdagang pakikilahok ng issuer. Ang OpenID4VCI 1.0 ay naaprubahan bilang isang Final Specification noong Setyembre 2025.

Ginagawa nitong mahalaga ang OpenID4VCI sa estratehiya para sa isang hinaharap na ecosystem ng IDP. Sa halip na bumuo ng mga bespoke na pipeline ng issuer-to-wallet para sa bawat hurisdiksyon o provider ng wallet, ang ecosystem ay maaaring tumukoy ng isang pinamamahalaan na profile ng issuance sa ibabaw ng isang pamantayang balangkas ng issuance — habang pinipili pa rin kung ang nagresultang credential ay naka-encode bilang mdoc, VC, o isa pang sinusuportahang format. Ang kakayahang iyon ay isa sa pinakamalakas na argumento para sa pagpapanatiling modular ng hinaharap na IDP stack.

Layer 6 — OpenID4VP: Ang Protokol ng Kahilingan at Presentasyon

Kung inililipat ng OpenID4VCI ang credential sa wallet, inililipat ito ng OpenID para sa Verifiable Presentations (OpenID4VP) pabalik sa isang kontroladong paraan.

Tinutukoy ng detalye ang isang mekanismo upang humiling at magpakita ng mga credential. Gumagamit ang baseline nito ng mga mensahe ng HTTPS at mga redirect, ngunit sinusuportahan din nito ang paggamit sa W3C Digital Credentials API sa halip na mga redirect flow. Ang OpenID4VP 1.0 ay umabot sa katayuan ng Final Specification noong Hulyo 2025.

Mahalaga iyon dahil nagbibigay ito sa hinaharap na IDP stack ng isang web-native na layer ng presentasyon na maaaring direktang ipatupad ng mga website, application, at online na verifier. Maraming kamakailang pag-unlad ang nagpapatibay nito:

Noong Agosto 2025, inihayag ng OpenID Foundation ang isang pormal na pagsusuri ng seguridad ng OpenID4VP na ginagamit sa Digital Credentials API, na walang mga bagong kahinaan na natuklasan sa verified na modelo ng protokol.
Ang kasalukuyang draft ng mDL ng NIST ay nagtatayo ng modelo ng banta nito sa paligid ng pag-request at pagpapakita ng mga mDL sa pamamagitan ng OpenID4VP sa W3C Digital Credentials API, na may FIDO CTAP na ginagamit upang ipatupad ang proximity at labanan ang phishing sa mga kaugnay na daloy.

Ang panig ng web ng stack at ang panig ng mDL ay nagkakalapit. Ang OpenID4VP ay hindi dapat basahin bilang isang kakumpitensya sa ISO 18013-7 — ito ang layer ng protokol ng web na ginagawang praktikal ang internet na presentasyon sa mga tunay na kapaligiran ng browser, wallet, at verifier.

Layer 7 — Mga Trust Registry: Kung Saan Nagiging Ecosystem ang Stack

Ito ang layer na nilalaktawan ng maraming talakayan — at ang layer na nagtatakda kung ang buong sistema ay talagang gumagana.

Hindi masyadong magagawa ng isang verifier sa isang nilagdaang credential maliban kung alam nito ang tatlong bagay:

Kung aling mga issuer ang lehitimo
Kung aling mga pampublikong key ang kasalukuyang wasto
Kung ang partido na humihiling ay awtorisado mismo

Sa panig ng issuer, ang Digital Trust Service ng AAMVA ay nag-aalok ng isang kongkretong sagot. Nagbibigay ito ng isang, secure, matibay na paraan para sa mga relying party upang makakuha ng mga pampublikong key ng awtoridad na nag-isyu, na ipinamamahagi sa pamamagitan ng Verified Issuer Certificate Authority List (VICAL). Inilalarawan ng gabay ng AAMVA ang papel ng provider ng VICAL sa praktikal na mga termino: mangolekta ng mga pampublikong key mula sa mga lehitimong awtoridad na nag-isyu, i-verify na ang mga awtoridad na iyon ay namamahala ng kanilang mga key nang may seguridad, pagsamahin ang mga key sa isang solong VICAL, at ihatid ito sa mga verifier.

Sa panig ng verifier, ang Europa ay lumapit sa problema ng tiwala mula sa ibang direksyon. Sa EUDI Architecture and Reference Framework, ang mga relying party ay nagrerehistro, nakakakuha ng mga access certificate, at gumagamit ng mga certificate na iyon upang mapatunayan ang kanilang sarili sa mga aplikasyon ng wallet kapag humihiling ng mga katangian. Pagkatapos, bine-verify ng wallet ang chain ng certificate, sinusuri ang katayuan ng revocation, ipinepresenta ang kahilingan sa gumagamit, at inilalabas lamang ang mga naaprubahang katangian.

Nag-aambag din dito ang modelo ng VC ng W3C, na tinatrato ang mga verifiable data registry bilang isang natatanging papel sa ecosystem. Tulad ng nabanggit kanina, ang mga registry na iyon ay maaaring maging mga pinagkakatiwalaang database, mga database ng pagkakakilanlan ng gobyerno, mga desentralisadong database, o mga distributed ledger. Ang isang hinaharap na IDP trust registry ay hindi kailangang itayo sa blockchain. Kailangan itong pamahalaan, ma-audit, at machine-readable.

Kung tinutukoy ng ISO 18013 kung paano mukhang at naglalakbay ang credential, tinutukoy ng mga trust registry kung dapat ba itong paniwalaan ng sinuman.

Ang isang hinaharap na IDP ay isang stack, hindi isang solong detalye

Paano Gumagana ang isang Hinaharap na Transaksyon ng IDP mula Simula hanggang Katapusan

Narito ang stack sa operasyon, na nahahati sa apat na pangunahing sandali ng buhay ng isang credential.

1. Issuance. Ang isang pambansang awtoridad — o isang mahigpit na pinamamahalaan na awtorisadong issuer — ay bine-verify ang pinagbabatayan na rekord ng lisensya at nag-isyu ng credential sa wallet ng may-hawak. Ang OpenID4VCI ang pinaka-praktikal na layer ng issuance na available ngayon, dahil sinusuportahan na nito ang mga format na ISO mdoc, SD-JWT VC, at W3C VCDM. Ang ISO 18013-5 mismo ay nag-iiwan ng koleksyon ng pahintulot at pag-iimbak ng pribadong key sa labas ng saklaw, na eksakto kung bakit ang issuance at pamamahala ng wallet ay kailangang gumana sa itaas ng pangunahing layer ng transportasyon ng ISO.

2. Personal na presentasyon. Sa isang pagsusuri sa tabi ng daan o sa mesa ng pag-renta, ipinipresenta ng wallet ang credential gamit ang isang proximity flow na batay sa 18013-5. Bine-validate ng reader ang pinagmulan at integridad gamit ang mga key ng issuer na nakuha mula sa isang trust registry — sa halip na gumawa ng mga desisyon sa tiwala nang mag-isa. Inaprubahan ng may-hawak ang mga field lamang na kailangan para sa partikular na sitwasyong iyon.

3. Remote na presentasyon. Para sa mga pagsusuri bago ang pag-renta o iba pang online na proseso, humihiling ang verifier ng minimal na set ng mga katangian sa pamamagitan ng isang internet-capable na daloy gamit ang 18013-7 at/o OpenID4VP. Ipinapakita ng wallet kung aling mga katangian ang hinihingi, inaprubahan ng may-hawak, at nakatanggap ang verifier ng isang nakastrukturang presentasyon sa halip na isang scan o pag-upload ng PDF. Ang kasalukuyang arkitektura ng NIST, na itinayo sa paligid ng OpenID4VP kasama ang Digital Credentials API, ay nagpapakita na ito ay isang praktikal na landas ng inhinyeriya ngayon.

4. Tiwala at awtorisasyon ng verifier. Hindi bulag na pinagkakatiwalaan ng wallet ang bawat humihiling. Ang isang mature na ecosystem ay nagpapatunay ng relying party, nagva-validate ng mga chain ng certificate, sinusuri ang katayuan ng revocation, at nagbibigay sa gumagamit ng visibility sa kung sino ang humihiling ng kung anong datos. Ang modelong EUDI ay partikular na malakas dito, na tinatrato ang pagpaparehistro ng verifier at mga access certificate bilang mahahalagang bahagi ng sistema kaysa sa mga opsyonal na dagdag.

Ang kumpletong daloy na ito ang eksakto kung bakit ang isang hinaharap na IDP ay dapat na isang stack. Walang iisang layer ang makakahatid nito. Hindi ang ISO nang mag-isa. Hindi ang VC nang mag-isa. Hindi ang OpenID nang mag-isa. At tiyak na hindi isang PDF na nakalakip sa isang form.

Ano ang Kulang Pa sa Hinaharap na IDP Stack

Ang pinakamahirap na natitirang problema ay hindi na ang paglikha ng bagong kriptograpiya — ito ay ang pagkamit ng pinamamahalaan na interoperability.

Isaalang-alang kung nasaan ang ecosystem ngayon:

Inilalarawan ng NIST ang kasalukuyang tanawin ng mga pamantayan bilang umuunlad sa magkakahiwalay na lugar.
Nagtayo ang AAMVA ng isang rehiyonal na serbisyo ng tiwala para sa Hilagang Amerika.
Nagtatayo ang Europa ng certificate-based na tiwala ng relying-party sa arkitektura ng wallet nito.
Inayos ng OpenID ang mga detalye ng issuance at presentasyon at nagpapalawak ng imprastraktura ng conformance.

Ang mga ito ay mga partikular na sagot sa ecosystem pa rin. Wala pa isa pang pandaigdigang cross-border na layer ng tiwala para sa mga kredensyal ng driver. Ang natitirang gawain ay ang tukuyin:

Kung aling mga bahagi ng stack ang sapilitan
Kung aling mga format ng credential ang katanggap-tanggap
Kung paano ipinamamahagi ang tiwala ng issuer at verifier
Kung paano sinusubukan ang conformance
Kung paano pinamamahalaan ang cross-border na pagkilala nang hindi nakompromiso ang privacy

Konklusyon: Ang Hinaharap na IDP ay isang Stack, Hindi isang Dokumento

Ang isang hinaharap na IDP ay hindi lalabas dahil isang organisasyon ng mga pamantayan ay sumulat ng isang dokumento. Lalabas ito kapag ang isang magkakaugnay na stack ay tinukoy, pinamamahalaan, at pinagtibay sa iba’t ibang hurisdiksyon. Ang stack na iyon ay mayroon nang mga natutukoy na layer: