Polisi, Meja Rental, Pemberi Kerja, Perusahaan Asuransi: Mengapa Mereka Tidak Boleh Melihat Data yang Sama

Kesalahan desain terbesar dalam Surat Izin Mengemudi Internasional (SIMI) masa depan adalah memperlakukan setiap pemverifikasi sebagai pemverifikasi yang sama. Seorang petugas polisi, meja rental mobil, pemberi kerja, dan perusahaan asuransi tidak mengajukan pertanyaan yang sama — sehingga mereka seharusnya tidak menerima jawaban yang sama.

Satu pengemudi. Satu hak mengemudi yang mendasarinya. Satu dompet digital. Namun empat pemverifikasi yang sangat berbeda:

• Seorang petugas polisi di tepi jalan
• Meja rental mobil saat pengambilan kendaraan
• Pemberi kerja yang memeriksa kelayakan armada kendaraan
• Perusahaan asuransi yang meninjau suatu klaim

Jika SIMI masa depan menampilkan data yang sama kepada keempat pihak tersebut, sistem ini sudah gagal. Bukan karena kredensialnya tidak aman, melainkan karena model pengungkapan datanya terlalu sederhana.

Komunitas standar internasional sudah bergerak meninggalkan model sederhana tersebut. Pekerjaan verifiable-credentials dari W3C menggambarkan ekosistem yang melibatkan penerbit, pemegang, dan pemverifikasi, dengan menggunakan pemberi kerja dan situs web sebagai contoh pemverifikasi. Pekerjaan mobile driving-license dari Uni Eropa sudah memperlakukan pemeriksaan di tepi jalan dan rental mobil sebagai skenario verifikasi yang terpisah, termasuk berbagi data jarak jauh di muka untuk rental dan pemeriksaan langsung untuk polisi. Arsitekturnya sudah dirancang untuk berbagai jenis pemverifikasi. Kesalahannya adalah merancang pengalaman pengguna seolah-olah hanya ada satu jenis pemverifikasi.

Mengapa Kartu Fisik Melatih Kita untuk Berpikir Secara Keliru

Lisensi fisik melatih kita pada pendekatan tampilkan-segalanya. Anda menyerahkan kartu. Orang lain melihat apa yang tertera di kartu tersebut. Itulah seluruh interaksinya.

Pendekatan tersebut dapat diterima di dunia berbasis kertas karena tidak ada alternatif lain. Pendekatan itu menjadi tidak dapat diterima di dunia digital.

W3C VC Data Model 2.0 menyatakan secara langsung: SIM dapat memuat nomor identitas, tinggi badan, berat badan, tanggal lahir, dan alamat rumah — namun itu semua masih bisa jauh melebihi kebutuhan untuk suatu transaksi tertentu. Poin-poin kunci dari standar yang berlaku saat ini:

• Praktik terbaik W3C: mendukung pengungkapan selektif, dan hanya meminta data yang benar-benar diperlukan
• Panduan perlindungan data Uni Eropa: pemrosesan harus dibatasi untuk tujuan yang telah ditentukan, dan data yang diproses harus diperlukan serta proporsional
• Prinsip pertama SIMI masa depan: kredensial yang sama tidak berarti hak yang sama untuk memeriksa

Model yang Tepat adalah Pengungkapan Berbasis Kebijakan

Jika Anda menginginkan arsitektur yang serius, model yang tepat lebih mendekati kontrol akses berbasis atribut daripada presentasi kartu digital.

NIST SP 800-205 mendefinisikan keputusan kontrol akses sebagai evaluasi atribut yang terkait dengan subjek, objek, operasi yang diminta, dan kondisi lingkungan, berdasarkan kebijakan yang berlaku. Itulah struktur yang tepat untuk SIMI masa depan:

• Subjek: pengemudi
• Objek: bidang data yang diminta
• Tindakan: bukan “lihat lisensi” secara abstrak, melainkan sesuatu yang spesifik seperti “verifikasi hak mengemudi kategori B di tepi jalan” atau “verifikasi kelayakan rental untuk suatu pemesanan”
• Lingkungan: tepi jalan, meja rental, pemeriksaan jarak jauh di muka, orientasi armada, dan tinjauan klaim pasca-kerugian adalah lingkungan yang berbeda dan seharusnya menghasilkan keputusan yang berbeda pula

NIST juga mencatat bahwa sistem atribut memerlukan granularitas, tata kelola, serta mekanisme untuk pengurangan, pengelompokan, dan minimisasi atribut.

Maka SIMI masa depan seharusnya tidak bertanya: Dapatkah pemverifikasi ini membaca lisensi? Melainkan harus bertanya: Klaim mana yang boleh diterima pemverifikasi ini, untuk penggunaan yang dimaksud, dalam lingkungan ini, dengan aturan retensi seperti apa?

Pemverifikasi Harus Mengidentifikasi Diri Sebelum Meminta Apa Pun

SIMI masa depan seharusnya tidak dimulai dengan dompet digital yang menampilkan data. Melainkan harus dimulai dengan pemverifikasi yang membuktikan identitas dirinya.

Arsitektur EUDI sudah jelas dalam hal ini. Pihak yang mengandalkan data (relying parties) harus:

• Mendaftarkan atribut apa yang ingin mereka minta dan untuk tujuan apa
• Menerima sertifikat akses
• Melakukan autentikasi ke dompet digital sebelum pengungkapan data apa pun
• Diperiksa terhadap cakupan yang telah didaftarkan, jika informasi pendaftaran tersedia

Pengguna kemudian dapat melihat siapa yang meminta, apa yang diminta, dan apakah permintaan tersebut berada dalam cakupan yang telah didaftarkan.

Pekerjaan sertifikat wallet-relying-party ETSI saat ini membuat hal ini lebih konkret. Sertifikat pendaftaran wallet-relying-party dapat mendeskripsikan penggunaan yang dimaksud oleh pihak yang mengandalkan dan atribut yang telah didaftarkan untuk diminta. Sertifikat akses terkait ada untuk memastikan permintaan berasal dari pihak yang sah dan berwenang. ETSI juga menyertakan metadata relying-party seperti:

• Nama dagang
• URI dukungan
• Penggunaan yang dimaksud
• Hak dan wewenang
• URI registri
• Informasi otoritas pengawas

Prinsip kedua SIMI masa depan: tanpa identitas pemverifikasi, tidak ada pengungkapan data.

Mengapa Layar Persetujuan Tidak Cukup

Ada kesalahan lain di sini: memperlakukan persetujuan pengguna sebagai hal yang sama dengan legitimasi hukum.

Arsitektur EUDI secara eksplisit menyatakan bahwa persetujuan pengguna untuk mempresentasikan atribut tidak boleh diperlakukan sebagai dasar hukum bagi pemrosesan data pribadi oleh relying party. Relying party tetap harus memiliki dasar hukum tersendiri. EUDI juga mensyaratkan persetujuan pengguna dalam semua kasus penggunaan, termasuk kasus di mana relying party mungkin merupakan bagian dari penegak hukum atau lembaga pemerintah lainnya.

Antarmuka dompet digital yang baik dapat membantu, namun tidak dapat menyelesaikan masalah pemverifikasi yang melampaui kewenangannya sendirian. Aturan harus ada sebelum antarmukanya.

SIMI masa depan oleh karena itu memerlukan keduanya:

• Autentikasi pemverifikasi secara kriptografis untuk mengonfirmasi siapa yang meminta
• Batasan kebijakan tentang apa yang boleh diminta oleh kategori pemverifikasi tersebut

Tanpa keduanya, “pilihan pengguna” menjadi cara untuk mengalihkan kegagalan kebijakan kepada individu.

1. Polisi: Verifikasi Hak Mengemudi, Bukan Seluruh Identitas

Skenario pemeriksaan polisi di tepi jalan adalah yang paling terfokus.

Panduan mDL Uni Eropa menggambarkannya secara langsung: polisi atau pejabat lainnya memeriksa lisensi saat diperlukan, termasuk validitas lisensi dan hak kendaraan. Dalam perjalanan pengguna, petugas memverifikasi lisensi melalui alur yang dipicu QR code, Bluetooth, Wi-Fi Aware, atau NFC. Itulah tugas verifikasi yang terfokus:

• Apakah orang ini adalah pemegang yang sah?
• Apakah kredensial tersebut valid?
• Hak dan pembatasan kendaraan apa yang berlaku?

Diizinkan secara default:

• Nama
• Foto
• Status lisensi
• Tanggal penerbitan dan kedaluwarsa
• Kategori kendaraan
• Pembatasan yang relevan dengan mengemudi
• Penerbit dan yurisdiksi
• Hasil kesegaran/status

Tidak diizinkan secara default:

• Alamat rumah
• Pengenal internal yang tidak diperlukan untuk penggunaan di tepi jalan
• Atribut yang tidak terkait dari attestasi lain
• Log riwayat presentasi
• Metadata komersial

Panduan implementasi AAMVA memperkuat poin foto: jika foto diminta dan elemen lain pun turut diungkapkan, foto harus disertakan agar pemverifikasi dapat menghubungkan data dengan orang yang mempresentasikannya. Panduan yang sama juga menyatakan bahwa para pemangku kepentingan tidak boleh melacak pemegang mDL atau penggunaan mDL kecuali jika diwajibkan oleh hukum.

Kasus polisi bukan tentang negara yang menerima segalanya. Ini tentang negara yang menerima data spesifik terkait mengemudi yang diperlukan untuk penegakan di tepi jalan. Itu adalah perbedaan yang penting.

2. Meja Rental: Kelayakan, Pencocokan Identitas, dan Tidak Ada yang Tidak Diperlukan

Kasus rental lebih terperinci karena sesungguhnya ada dua momen: pemeriksaan jarak jauh di muka sebelum kedatangan, dan pengambilan kendaraan saat seseorang atau kios menyerahkan kunci.

Panduan mDL Uni Eropa sudah memodelkan keduanya. Layanan rental mobil dapat meminta mDL beserta bukti identitas selama pemesanan, memvalidasi attestasi, dan kemudian memverifikasi pelanggan secara langsung saat pengambilan sebelum melepaskan kendaraan. Pengguna dapat berbagi mDL mereka dengan perusahaan rental mobil baik secara langsung maupun dari jarak jauh sebelumnya.

Meja rental utamanya tidak perlu menyelidiki suatu insiden. Yang perlu diputuskan adalah: Dapatkah saya menyewakan kendaraan ini kepada pelanggan ini berdasarkan pemesanan dan kebijakan ini?

Pemeriksaan jarak jauh di muka sebaiknya mencakup:

• Tautan identitas
• Foto atau elemen pengikat identitas yang setara
• Kategori kendaraan yang relevan
• Tanggal penerbitan dan kedaluwarsa
• Validitas saat ini
• Kemungkinan ambang usia atau rentang usia

Pengambilan kendaraan sebaiknya mengonfirmasi:

• Pemegang adalah orang yang sama yang menyelesaikan pemeriksaan awal
• Validitas saat ini
• Hak yang relevan

Tidak diperlukan secara default:

• Alamat rumah lengkap jika profil pemesanan sudah memuat detail kontak
• Tanggal lahir lengkap jika konfirmasi usia-di-atas atau rentang-usia sudah cukup
• Atribut identitas yang tidak terkait
• Presentasi ulang kredensial penuh secara berulang jika attestasi pemesanan sudah ada

Arsitektur mDL terkini dari NIST menunjukkan bahwa relying party menggunakan DCQL untuk meminta hanya atribut yang diperlukan, dan secara eksplisit menyatakan bahwa hal ini mendukung minimisasi data dan persetujuan pemegang dengan menyusun permintaan secara terstruktur alih-alih memperlakukan kredensial sebagai satu unit tunggal. AAMVA menambahkan bahwa aplikasi harus menampilkan dengan jelas data apa yang diminta dan apakah pemverifikasi bermaksud menyimpan informasi tersebut.

3. Pemberi Kerja: Kategori Pemverifikasi, Bukan Pintu Masuk ke Seluruh Identitas

Ikhtisar W3C menggunakan sistem digital pemberi kerja yang memeriksa gelar universitas sebagai contoh pemverifikasi. Hal ini mengingatkan kita bahwa verifikasi oleh pemberi kerja sudah merupakan pola yang diakui dalam ekosistem kredensial.

Pemberi kerja atau operator armada mungkin secara sah perlu mengetahui:

• Apakah seorang pekerja saat ini berhak mengemudikan kategori kendaraan tertentu
• Apakah ada pembatasan utama yang berlaku
• Apakah hak tersebut masih berlaku

Itu adalah kebutuhan bisnis yang nyata. Namun hal itu tidak secara otomatis membenarkan akses permanen ke seluruh kredensial mengemudi, data identitas lengkap, atau aliran presentasi berulang yang terus-menerus.

NIST memperingatkan bahwa sering mengirimkan pengenal yang dapat digunakan kembali dan membiasakan pengguna untuk berulang kali mempresentasikan kredensial yang memuat identitas adalah hal yang tidak diinginkan, dan menyatakan bahwa autentikasi sehari-hari sebaiknya mengandalkan teknologi yang dirancang untuk autentikasi, seperti passkeys. NIST lebih menyukai autentikasi perangkat lokal daripada pencocokan biometrik sisi server karena lebih baik dalam menjaga privasi.

SIMI masa depan tidak boleh menjadi lencana akses tempat kerja.

Untuk penggunaan oleh pemberi kerja dan armada, pola yang tepat biasanya adalah:

• Pemeriksaan kelayakan yang relevan dengan pekerjaan
• Mungkin attestasi kepatuhan secara berkala
• Mungkin klaim bahwa pemegang tetap valid untuk kategori yang ditentukan
• Namun bukan transfer default semua data lisensi setiap kali karyawan masuk ke sistem atau memulai giliran kerja

Kepatuhan armada adalah kategori relying party yang terpisah, dengan penggunaan yang dimaksud yang terpisah, dan profil pengungkapan yang terpisah pula.

4. Perusahaan Asuransi: Klaim Bukan Izin untuk Visibilitas yang Berkelanjutan

Kasus asuransi seringkali nyata. Dalam materi kasus penggunaan mDL Uni Eropa, perusahaan asuransi muncul secara tidak langsung dalam skenario rental: perusahaan asuransi mewajibkan perusahaan rental mobil untuk memeriksa apakah orang yang menyewa kendaraan memiliki hak untuk mengemudi. Asuransi sudah memengaruhi alur verifikasi mengemudi.

Namun itu tidak berarti perusahaan asuransi harus menerima data yang sama seperti polisi, atau hak permanen untuk mengakses kredensial.

SIMI masa depan harus memperlakukan perusahaan asuransi sebagai kategori pemverifikasi terpisah dengan penggunaan yang dimaksud yang terpisah:

• Penjaminan (underwriting)
• Verifikasi risiko rental
• Penanganan klaim pasca-kerugian
• Tinjauan penipuan

Itu bukan tujuan yang sama. Berdasarkan prinsip perlindungan data Uni Eropa, data pribadi harus dikumpulkan untuk tujuan yang telah ditentukan dan dibatasi pada apa yang diperlukan serta proporsional untuk tujuan tersebut. Panduan VC dari W3C mencapai kesimpulan yang sama secara teknis: pemverifikasi hanya boleh meminta data yang benar-benar diperlukan.

Contoh yang sah dan spesifik berdasarkan peristiwa:

• Bukti bahwa lisensi berlaku pada saat yang relevan
• Bukti hak kendaraan yang relevan
• Bukti tautan identitas jika diperlukan untuk suatu klaim
• Pengungkapan spesifik klaim

Tidak diizinkan secara default:

• Akses persisten ke kredensial yang mendasarinya
• Verifikasi generik berulang setiap kali pelanggan berinteraksi dengan perusahaan asuransi
• Penggunaan kredensial mengemudi sebagai token login
• Pengumpulan atribut yang tidak terkait

Kredensial mengemudi bukan langganan pemantauan. Dan tidak seharusnya diam-diam menjadi demikian.

Mengapa Perantara Harus Terlihat

Pasar nyata melibatkan perantara. Platform rental, vendor armada, sistem SDM pemberi kerja, dan pemroses klaim asuransi seringkali bertindak melalui pihak ketiga.

Arsitektur EUDI menangani hal ini dengan cara:

• Memperlakukan perantara sebagai relying party
• Mewajibkan mereka untuk mendaftar
• Mewajibkan atribut yang diminta untuk relying party yang dimediasi untuk didaftarkan
• Menampilkan baik perantara maupun relying party akhir kepada pengguna
• Melarang perantara untuk menyimpan data tentang isi transaksi

SIMI masa depan tidak boleh memungkinkan pola di mana pengguna mengira mereka mengungkapkan data kepada perusahaan rental, padahal kenyataannya mereka mengungkapkan data kepada rantai broker verifikasi, pemroses analitik, dan vendor klaim yang tidak terlihat.

ETSI membantu di sini. Model sertifikat wallet-relying-party-nya mencakup URI dukungan, penggunaan yang dimaksud, URI registri, dan metadata otoritas pengawas. Itulah jenis infrastruktur yang dapat dibaca oleh mesin yang diperlukan agar pengguna memahami siapa sebenarnya yang ada di ujung permintaan tersebut dan ke mana harus pergi jika mereka ingin penghapusan atau koreksi data.

Retensi adalah Bagian dari Kontrol Akses

Sebagian besar diskusi tentang pengungkapan selektif berakhir terlalu dini. Mereka berfokus pada apa yang diungkapkan. Mereka tidak cukup berfokus pada berapa lama data tersebut disimpan setelahnya.

Panduan yang berlaku saat ini sudah mulai konvergen:

• AAMVA: dompet harus dengan jelas memberi tahu pemegang data apa yang diminta dan apakah pemverifikasi bermaksud menyimpannya; para pemangku kepentingan tidak boleh melacak pemegang atau penggunaan mDL kecuali diwajibkan oleh hukum
• W3C: perangkat lunak pemegang harus menyediakan log informasi yang dibagikan kepada pemverifikasi, sehingga permintaan yang berlebihan dapat diidentifikasi
• EUDI: pengguna harus dapat mengakses log transaksi, melaporkan permintaan yang mencurigakan, dan meminta penghapusan data

Kelas retensi harus menjadi bagian dari kebijakan pengungkapan itu sendiri:

• Polisi di tepi jalan: tidak ada retensi secara default di luar catatan operasional yang sah
• Pemeriksaan jarak jauh di muka untuk rental: catatan transaksi terikat pada pemesanan, bukan salinan identitas yang dapat digunakan kembali
• Kepatuhan armada pemberi kerja: catatan kepatuhan atau hasil attestasi, bukan data kredensial mentah
• Klaim asuransi: catatan klaim terbatas pada klaim tersebut, bukan akses permanen

SIMI masa depan yang mengabaikan retensi hanya sebagian menjaga privasi.

Apa yang Seharusnya Diputuskan oleh Dompet Digital

Jika saya harus meringkas seluruh artikel ini menjadi satu aturan implementasi, itu adalah:

Dompet digital seharusnya tidak menjawab “Dapatkah saya mempresentasikan kredensial ini?” Melainkan harus menjawab “Dapatkah saya mempresentasikan kumpulan klaim ini kepada pemverifikasi yang terautentikasi ini, untuk penggunaan yang dimaksud ini, dalam konteks ini, di bawah kelas retensi ini?”

Keputusan tersebut setidaknya harus didorong oleh masukan-masukan berikut:

• Identitas pemverifikasi
• Kategori pemverifikasi
• Penggunaan yang dimaksud
• Cakupan atribut yang terdaftar
• Kebijakan pengungkapan dari penerbit, jika ada
• Lingkungan (tepi jalan, pengambilan kendaraan, jarak jauh, armada, klaim)
• Persetujuan pemegang
• Kebijakan retensi yang berlaku

Standar yang ada sudah memuat banyak mekanisme untuk ini: pengungkapan selektif, autentikasi relying party, penggunaan yang dimaksud yang terdaftar, sertifikat akses, evaluasi kebijakan pengungkapan, dan permintaan yang terikat tujuan. Yang masih kurang adalah disiplin untuk memperlakukan bagian-bagian tersebut sebagai satu arsitektur pengungkapan yang koheren.

Argumen Inti

SIMI masa depan seharusnya tidak bertanya apakah data dapat diungkapkan. Melainkan harus bertanya:

• Siapa yang bertanya?
• Untuk tujuan apa?
• Berdasarkan kewenangan mana?
• Dalam konteks mana?
• Dengan konsekuensi retensi seperti apa?

Polisi, meja rental, pemberi kerja, dan perusahaan asuransi bukan sekadar empat logo di ujung permintaan. Mereka adalah empat model risiko yang berbeda, empat konteks hukum yang berbeda, empat alasan berbeda untuk meminta — dan seharusnya menghasilkan empat set pengungkapan yang berbeda pula.

Itu bukan kompleksitas yang tidak perlu. Itulah tampilan kredensial mengemudi modern ketika ia berhenti memperlakukan setiap pemverifikasi sebagai pemverifikasi yang sama.