Polis, Kaunter Sewa, Majikan, Penanggung Insurans: Mengapa Mereka Tidak Boleh Melihat Data yang Sama

Kesilapan reka bentuk terbesar dalam Permit Memandu Antarabangsa (IDP) masa depan ialah menganggap setiap pengesah adalah pengesah yang sama. Seorang pegawai polis, kaunter sewa kereta, majikan, dan syarikat insurans tidak mengemukakan soalan yang sama — oleh itu mereka seharusnya tidak menerima jawapan yang sama.

Satu pemandu. Satu hak asas untuk memandu. Satu dompet. Tetapi empat pengesah yang sangat berbeza:

• Seorang pegawai polis di tepi jalan
• Kaunter sewa kereta semasa pengambilan
• Majikan yang menyemak kelayakan armada
• Penanggung insurans yang menyemak tuntutan

Jika IDP masa depan menunjukkan data yang sama kepada keempat-empat pihak, sistem itu sudah pun gagal. Bukan kerana kelayakan itu tidak selamat, tetapi kerana model pendedahan terlalu mudah.

Komuniti piawaian sudah pun bergerak meninggalkan model mudah tersebut. Kerja kelayakan boleh sahkan W3C menerangkan ekosistem berkaitan penerbit, pemegang, dan pengesah, menggunakan majikan dan laman web sebagai contoh pengesah. Kerja lesen memandu mudah alih Kesatuan Eropah sudah pun menganggap pemeriksaan tepi jalan dan sewa kereta sebagai senario pengesahan yang berasingan, termasuk perkongsian awal dari jauh untuk sewaan dan pemeriksaan secara langsung untuk polis. Seni bina sudah direka bentuk untuk pelbagai jenis pengesah. Kesilapannya ialah mereka bentuk pengalaman pengguna seolah-olah hanya satu jenis sahaja yang wujud.

Mengapa Kad Fizikal Melatih Kita untuk Berfikir Secara Salah

Lesen fizikal telah melatih kita dengan pendekatan tunjuk-semua. Anda serahkan kad itu. Orang lain melihat apa yang tertera pada kad. Itulah keseluruhan interaksi.

Pendekatan itu boleh diterima dalam dunia kertas kerana tiada alternatif lain. Ia menjadi tidak boleh diterima dalam dunia digital.

Model Data VC W3C 2.0 menyatakan secara langsung: lesen memandu mungkin mengandungi nombor ID, ketinggian, berat, tarikh lahir, dan alamat rumah — tetapi itu masih boleh jauh melebihi keperluan untuk sesuatu transaksi. Perkara utama daripada piawaian semasa:

• Amalan terbaik W3C: sokong pendedahan terpilih, dan minta hanya apa yang benar-benar diperlukan
• Panduan perlindungan data Kesatuan Eropah: pemprosesan mestilah terhad kepada tujuan yang dinyatakan, dan data yang diproses mestilah perlu dan berkadar
• Prinsip pertama IDP masa depan: kelayakan yang sama tidak bermakna hak yang sama untuk memeriksa

Model yang Betul Ialah Pendedahan Berasaskan Dasar

Jika anda mahukan seni bina yang serius, model yang betul lebih hampir kepada kawalan akses berasaskan atribut berbanding pembentangan kad digital.

NIST SP 800-205 mentakrifkan keputusan kawalan akses sebagai penilaian atribut yang dikaitkan dengan subjek, objek, operasi yang diminta, dan syarat persekitaran, berdasarkan dasar. Itulah struktur yang tepat untuk IDP masa depan:

• Subjek: pemandu
• Objek: medan data yang diminta
• Tindakan: bukan “lihat lesen” secara abstrak, tetapi sesuatu yang spesifik seperti “sahkan kelayakan memandu kategori B di tepi jalan” atau “sahkan kelayakan sewaan untuk sesuatu tempahan”
• Persekitaran: tepi jalan, kaunter sewa, semakan awal dari jauh, pendaftaran armada, dan semakan tuntutan selepas kerugian adalah persekitaran yang berbeza dan seharusnya menghasilkan keputusan yang berbeza

NIST juga menyatakan bahawa sistem atribut memerlukan perincian, tadbir urus, dan mekanisme untuk pengurangan, pengumpulan, dan peminimuman atribut.

Oleh itu, IDP masa depan tidak seharusnya bertanya: Bolehkah pengesah ini membaca lesen? Ia seharusnya bertanya: Tuntutan mana yang boleh diterima oleh pengesah ini, untuk kegunaan yang dimaksudkan, dalam persekitaran ini, dengan peraturan pengekalan yang bagaimana?

Pengesah Harus Mengenal Pasti Dirinya Sebelum Meminta Apa-apa

IDP masa depan tidak seharusnya bermula dengan dompet yang menunjukkan data. Ia seharusnya bermula dengan pengesah yang membuktikan identiti dirinya.

Seni bina EUDI jelas mengenai perkara ini. Pihak yang bergantung mestilah:

• Mendaftarkan atribut yang mereka niat untuk minta dan untuk tujuan apa
• Menerima sijil akses
• Mengesahkan diri kepada dompet sebelum sebarang pendedahan
• Disemak berdasarkan skop pendaftaran mereka, di mana maklumat pendaftaran tersedia

Pengguna kemudiannya boleh melihat siapa yang bertanya, apa yang diminta, dan sama ada permintaan itu berada dalam skop yang didaftarkan.

Kerja sijil dompet-pihak-bergantung ETSI semasa menjadikan ini lebih konkrit. Sijil pendaftaran dompet-pihak-bergantung boleh menerangkan kegunaan yang dimaksudkan oleh pihak yang bergantung dan atribut yang didaftarnya untuk diminta. Sijil akses yang berkaitan wujud untuk memastikan permintaan datang daripada pihak yang sah dan diberi kuasa. ETSI juga menyertakan metadata pihak yang bergantung seperti:

• Nama dagangan
• URI sokongan
• Kegunaan yang dimaksudkan
• Kelayakan
• URI pendaftaran
• Maklumat pihak berkuasa penyeliaan

Prinsip kedua IDP masa depan: tiada identiti pengesah, tiada pendedahan.

Mengapa Skrin Persetujuan Tidak Mencukupi

Terdapat kesilapan lain di sini: menganggap kelulusan pengguna adalah sama dengan kesahan undang-undang.

Seni bina EUDI secara eksplisit menyatakan bahawa kelulusan pengguna untuk membentangkan atribut tidak boleh dianggap sebagai asas yang sah untuk pemprosesan data peribadi oleh pihak yang bergantung. Pihak yang bergantung masih perlu mempunyai asas yang sah sendiri. EUDI juga memerlukan kelulusan pengguna dalam semua kes penggunaan, termasuk kes di mana pihak yang bergantung mungkin merupakan sebahagian daripada penguatkuasaan undang-undang atau agensi kerajaan yang lain.

Antara muka dompet yang baik boleh membantu, tetapi ia tidak dapat menyelesaikan pelanggaran pengesah dengan sendirinya. Peraturan itu mesti wujud sebelum antara muka.

Oleh itu, IDP masa depan memerlukan kedua-duanya:

• Pengesahan pengesah kriptografi untuk mengesahkan siapa yang bertanya
• Kekangan dasar tentang apa yang boleh diminta oleh kategori pengesah tersebut

Tanpa kedua-duanya, “pilihan pengguna” menjadi cara untuk memindahkan kegagalan dasar kepada individu.

1. Polis: Sahkan Hak untuk Memandu, Bukan Keseluruhan Identiti Seseorang

Senario tepi jalan polis adalah yang paling fokus.

Manual mDL Kesatuan Eropah menerangkannya secara langsung: polis atau pegawai lain menyemak lesen apabila diperlukan, termasuk kesahan lesen dan kelayakan kenderaan. Dalam perjalanan pengguna, pegawai mengesahkan lesen melalui aliran pencetus kod QR, Bluetooth, Wi-Fi Aware, atau NFC. Itu adalah tugas pengesahan yang fokus:

• Adakah orang ini pemegang lesen?
• Adakah kelayakan itu sah?
• Apakah kelayakan dan sekatan kendaraan yang terpakai?

Dibenarkan secara lalai:

• Nama
• Gambar
• Status lesen
• Tarikh keluaran dan tamat tempoh
• Kategori
• Sekatan yang berkaitan dengan pemanduan
• Penerbit dan bidang kuasa
• Keputusan kesegaran/status

Tidak dibenarkan secara lalai:

• Alamat rumah
• Pengecam dalaman yang tidak diperlukan untuk kegunaan tepi jalan
• Atribut yang tidak berkaitan daripada pengesahan lain
• Log pembentangan sejarah
• Metadata komersial

Panduan pelaksanaan AAMVA mengukuhkan perkara gambar: jika gambar diminta dan mana-mana elemen lain dikeluarkan, gambar perlu dikongsi supaya pengesah dapat mengaitkan data dengan orang yang membentangkannya. Panduan yang sama juga menyatakan bahawa pihak berkepentingan tidak boleh menjejak pemegang mDL atau penggunaan mDL kecuali seperti yang dikehendaki oleh undang-undang.

Kes polis bukan tentang negara menerima segala-galanya. Ia tentang negara menerima data khusus pemanduan yang diperlukan untuk penguatkuasaan tepi jalan. Itu adalah perbezaan yang penting.

2. Kaunter Sewa: Kelayakan, Pemadanan Identiti, dan Tiada yang Tidak Perlu

Kes sewaan lebih terperinci kerana sebenarnya terdapat dua momen: semakan awal dari jauh sebelum ketibaan, dan pengambilan apabila seseorang atau kiosk menyerahkan kunci.

Manual mDL Kesatuan Eropah sudah pun memodelkan kedua-duanya. Perkhidmatan sewa kereta boleh meminta mDL bersama bukti identiti semasa tempahan, mengesahkan pengesahan, dan kemudian mengesahkan pelanggan secara langsung semasa pengambilan sebelum melepaskan kenderaan. Pengguna boleh berkongsi mDL mereka dengan syarikat sewa kereta sama ada secara langsung atau dari jauh terlebih dahulu.

Kaunter sewa tidak terutamanya perlu menyiasat sesuatu kejadian. Ia perlu memutuskan: Bolehkah saya menyewakan kenderaan ini kepada pelanggan ini di bawah tempahan dan polisi ini?

Semakan awal dari jauh hendaklah merangkumi:

• Pautan identiti
• Gambar atau elemen pengikatan identiti yang setara
• Kategori kenderaan yang berkaitan
• Tarikh keluaran dan tamat tempoh
• Kesahan semasa
• Mungkin ambang umur atau jalur umur

Pengambilan hendaklah mengesahkan:

• Pemegang adalah orang yang sama yang melengkapkan semakan awal
• Kesahan semasa
• Kelayakan yang berkaitan

Tidak diperlukan secara lalai:

• Alamat rumah penuh apabila profil tempahan sudah mengandungi butiran hubungan
• Tarikh lahir penuh apabila umur-melebihi atau jalur umur sudah mencukupi
• Atribut identiti yang tidak berkaitan
• Pembentangan semula kelayakan penuh yang berulang jika pengesahan tempahan sudah wujud

Seni bina mDL semasa NIST menunjukkan pihak yang bergantung menggunakan DCQL untuk meminta hanya atribut yang diperlukan, dan secara eksplisit menyatakan ini menyokong peminimuman data dan persetujuan pemegang dengan menstrukturkan permintaan dan bukannya menganggap kelayakan sebagai satu unit tunggal. AAMVA menambah bahawa aplikasi hendaklah menunjukkan dengan jelas data apa yang diminta dan sama ada pengesah berhasrat untuk menyimpan maklumat tersebut.

3. Majikan: Kategori Pengesah, Bukan Pintu Masuk ke Identiti Penuh

Gambaran keseluruhan W3C menggunakan sistem digital majikan yang menyemak ijazah universiti sebagai contoh pengesah. Ini mengingatkan kita bahawa pengesahan majikan sudah merupakan corak yang diiktiraf dalam ekosistem kelayakan.

Majikan atau pengendali armada mungkin secara sah perlu mengetahui:

• Sama ada pekerja kini berhak memandu kategori kenderaan tertentu
• Sama ada terdapat sekatan utama
• Sama ada kelayakan itu masih sah

Itu adalah keperluan perniagaan yang nyata. Tetapi ia tidak secara automatik membenarkan akses kekal kepada keseluruhan kelayakan memandu, data identiti penuh, atau aliran pembentangan berulang yang berterusan.

NIST memberi amaran bahawa sering menghantar pengecam boleh guna semula dan membiasakan pengguna untuk berulang kali membentangkan kelayakan yang mengandungi identiti adalah tidak diingini, dan menyatakan bahawa pengesahan harian hendaklah bergantung pada teknologi yang direka untuk pengesahan, seperti kunci laluan. NIST lebih mengutamakan pengesahan peranti tempatan berbanding pemadanan biometrik sisi pelayan kerana ia lebih baik memelihara privasi.

IDP masa depan tidak seharusnya menjadi lencana akses tempat kerja.

Untuk kegunaan majikan dan armada, corak yang betul biasanya adalah:

• Semakan kelayakan yang berkaitan dengan pekerjaan
• Mungkin pengesahan pematuhan berkala
• Mungkin tuntutan bahawa pemegang masih sah untuk kategori yang dinyatakan
• Tetapi bukan pemindahan lalai semua data lesen setiap kali pekerja log masuk ke sistem atau memulakan syif

Pematuhan armada adalah kategori pihak yang bergantung yang berasingan, dengan kegunaan yang dimaksudkan yang berasingan, dan profil pendedahan yang berasingan.

4. Penanggung Insurans: Tuntutan Bukan Kebenaran untuk Keterlihatan Berterusan

Kes insurans sering kali nyata. Dalam bahan kes penggunaan mDL Kesatuan Eropah, syarikat insurans muncul secara tidak langsung dalam senario sewaan: syarikat insurans menghendaki syarikat sewa kereta menyemak sama ada orang yang menyewa kereta mempunyai hak untuk memandu. Insurans sudah pun mempengaruhi aliran pengesahan pemanduan.

Tetapi itu tidak bermakna syarikat insurans harus menerima data yang sama seperti polis, atau hak kekal untuk mengakses kelayakan tersebut.

IDP masa depan harus menganggap penanggung insurans sebagai kategori pengesah yang berasingan dengan kegunaan yang dimaksudkan yang berasingan:

• Pengunderaitan
• Pengesahan risiko sewaan
• Pengendalian tuntutan selepas kerugian
• Semakan penipuan

Itu bukan tujuan yang sama. Di bawah prinsip perlindungan data Kesatuan Eropah, data peribadi mestilah dikumpulkan untuk tujuan yang dinyatakan dan dihadkan kepada apa yang perlu dan berkadar untuk tujuan tersebut. Panduan VC W3C mencapai kesimpulan yang sama secara teknikal: pengesah hendaklah meminta hanya apa yang benar-benar diperlukan.

Contoh sah yang khusus untuk kejadian:

• Bukti bahawa lesen itu sah pada saat yang relevan
• Bukti kelayakan kendaraan yang berkaitan
• Bukti pautan identiti apabila perlu untuk sesuatu tuntutan
• Pendedahan khusus tuntutan

Tidak dibenarkan secara lalai:

• Akses berterusan kepada kelayakan asas
• Pengesahan generik berulang setiap kali pelanggan berinteraksi dengan penanggung insurans
• Penggunaan kelayakan memandu sebagai token log masuk
• Pengumpulan atribut yang tidak berkaitan

Kelayakan memandu bukan langganan pemantauan. Dan ia tidak seharusnya diam-diam menjadi sedemikian.

Mengapa Perantara Mesti Kelihatan

Pasaran sebenar melibatkan perantara. Platform sewaan, vendor armada, sistem HR majikan, dan pemproses tuntutan insurans sering bertindak melalui pihak ketiga.

Seni bina EUDI menangani perkara ini dengan:

• Menganggap perantara sebagai pihak yang bergantung
• Menghendaki mereka mendaftar
• Menghendaki atribut yang diminta untuk pihak yang bergantung melalui perantaraan didaftarkan
• Menunjukkan perantara dan pihak yang bergantung akhir kepada pengguna
• Melarang perantara daripada menyimpan data tentang kandungan transaksi

IDP masa depan tidak seharusnya membenarkan corak di mana pengguna percaya mereka mendedahkan kepada syarikat sewaan, tetapi pada hakikatnya mereka mendedahkan kepada broker pengesahan yang tidak kelihatan, pemproses analitik, dan rantaian vendor tuntutan.

ETSI membantu di sini. Model sijil dompet-pihak-bergantungnya menyertakan URI sokongan, kegunaan yang dimaksudkan, URI pendaftaran, dan metadata pihak berkuasa penyeliaan. Itulah jenis infrastruktur boleh baca mesin yang diperlukan untuk pengguna memahami siapa sebenarnya yang berada di hujung lain permintaan dan ke mana hendak pergi apabila mereka mahukan pemadaman atau pembetulan.

Pengekalan Adalah Sebahagian daripada Kawalan Akses

Kebanyakan perbincangan tentang pendedahan terpilih berakhir terlalu awal. Mereka memberi tumpuan kepada apa yang didedahkan. Mereka tidak memberi tumpuan yang cukup kepada berapa lama ia kekal selepas itu.

Panduan semasa sudah pun menumpu:

• AAMVA: dompet mesti memberitahu pemegang dengan jelas data apa yang diminta dan sama ada pengesah berhasrat untuk menyimpannya; pihak berkepentingan tidak boleh menjejak pemegang atau penggunaan mDL kecuali seperti yang dikehendaki oleh undang-undang
• W3C: perisian pemegang hendaklah menyediakan log maklumat yang dikongsi dengan pengesah, supaya permintaan yang berlebihan dapat dikenal pasti
• EUDI: pengguna hendaklah dapat mengakses log transaksi, melaporkan permintaan yang mencurigakan, dan meminta pemadaman

Kelas pengekalan hendaklah menjadi sebahagian daripada dasar pendedahan itu sendiri:

• Tepi jalan polis: tiada pengekalan secara lalai melainkan rekod operasi yang sah
• Semakan awal sewaan: rekod transaksi yang terikat pada tempahan, bukan salinan identiti yang boleh diguna semula
• Pematuhan armada majikan: rekod pematuhan atau hasil pengesahan, bukan data kelayakan mentah
• Tuntutan penanggung insurans: rekod tuntutan yang terhad kepada tuntutan tersebut, bukan akses kekal

IDP masa depan yang mengabaikan pengekalan hanya memelihara privasi sebahagiannya sahaja.

Apa yang Sebenarnya Harus Diputuskan oleh Dompet

Jika saya perlu meringkaskan keseluruhan artikel ini kepada satu peraturan pelaksanaan, ia adalah ini:

Dompet tidak seharusnya menjawab “Bolehkah saya membentangkan kelayakan ini?” Ia seharusnya menjawab “Bolehkah saya membentangkan set tuntutan ini kepada pengesah yang telah disahkan ini, untuk kegunaan yang dimaksudkan ini, dalam konteks ini, di bawah kelas pengekalan ini?”

Keputusan itu hendaklah didorong oleh sekurang-kurangnya input berikut:

• Identiti pengesah
• Kategori pengesah
• Kegunaan yang dimaksudkan
• Skop atribut yang didaftarkan
• Dasar pendedahan daripada penerbit, jika ada
• Persekitaran (tepi jalan, pengambilan, jauh, armada, tuntutan)
• Kelulusan pemegang
• Dasar pengekalan yang terpakai

Piawaian sudah pun mengandungi banyak mekanisme untuk ini: pendedahan terpilih, pengesahan pihak yang bergantung, kegunaan yang dimaksudkan yang didaftarkan, sijil akses, penilaian dasar pendedahan, dan permintaan terikat tujuan. Apa yang masih kurang ialah disiplin untuk menganggap kepingan-kepingan tersebut sebagai satu seni bina pendedahan yang koheren.

Hujah Teras

IDP masa depan tidak seharusnya bertanya sama ada data boleh didedahkan. Ia seharusnya bertanya:

• Siapa yang bertanya?
• Untuk apa tujuan?
• Di bawah kuasa mana?
• Dalam konteks mana?
• Dengan akibat pengekalan yang bagaimana?

Polis, kaunter sewa, majikan, dan penanggung insurans bukan empat logo di hujung lain sesuatu permintaan. Mereka adalah empat model risiko yang berbeza, empat konteks undang-undang yang berbeza, empat sebab yang berbeza untuk bertanya — dan mereka seharusnya menghasilkan empat set pendedahan yang berbeza.

Itu bukan kerumitan yang tidak perlu. Itulah rupa kelayakan memandu moden apabila ia berhenti menganggap setiap pengesah sebagai pengesah yang sama.