Identitas digital terdengar seperti infrastruktur publik. Tapi kalau lapisan trust-nya bergantung ke Google dan Apple, pertanyaannya berubah: siapa yang sebenarnya pegang tombol masuk?
Artikel ini membahas European Digital Identity Wallet dari sudut pandang developer dan builder: bukan untuk menolak digital ID mentah-mentah, tapi untuk membaca tradeoff arsitekturnya. Intinya, security feature seperti remote attestation memang berguna buat mencegah fraud dan device palsu. Tapi saat fitur itu jadi syarat akses layanan publik, dependency ke platform private perlu dibahas secara terbuka.
Apa itu European Digital Identity Wallet?
European Digital Identity Wallet, atau EUDI Wallet, adalah inisiatif Uni Eropa untuk memberi warga cara menyimpan dan memakai identitas digital resmi. Secara sederhana, wallet ini bisa dipakai untuk membuktikan identitas, mengakses layanan publik, atau melakukan verifikasi tertentu secara online.
Konsep dasarnya menarik: user tidak harus terus-menerus menyerahkan dokumen mentah ke banyak website. Idealnya, wallet bisa membantu user membuktikan hal spesifik, misalnya “cukup umur” atau “punya identitas valid”, tanpa membuka semua data pribadi yang tidak perlu.
Masalahnya, identitas digital bukan cuma soal aplikasi wallet. Di bawahnya ada banyak lapisan: perangkat, sistem operasi, app store, cryptographic key, server pemerintah, vendor teknologi, dan aturan governance. Kalau satu lapisan terlalu dominan, sistem yang terlihat publik bisa punya choke point private.
Remote attestation itu apa?
Remote attestation adalah mekanisme untuk membuktikan bahwa software berjalan di perangkat dan environment yang dianggap valid. Misalnya, app ingin tahu apakah perangkat sudah di-root, dimodifikasi, atau berjalan di emulator yang tidak dipercaya.
Di Android, salah satu layanan yang sering dibahas adalah Google Play Integrity API. Di ekosistem Apple, ada Managed Device Attestation untuk membantu organisasi memverifikasi properti perangkat yang dikelola. Secara security, idenya masuk akal: kalau sistem harus menangani identitas, fraud, payment, atau data sensitif, developer ingin punya sinyal bahwa perangkat tidak sedang dimanipulasi.
Tapi remote attestation juga punya sisi lain. Ia bukan cuma menjawab “apakah device ini aman?”, tapi bisa ikut menentukan “device mana yang boleh ikut sistem?”. Di titik itu, security primitive berubah menjadi control layer.
Kenapa Waag mengkritik dependency ke Google dan Apple?
Waag menulis bahwa wallet identitas digital Eropa yang akan dipakai untuk akses layanan dan verifikasi umur online bergantung pada safety services Google dan Apple: Google Play Integrity API dan Apple Managed Device Attestation. Kritik utamanya bukan “security itu buruk”, melainkan: kalau infrastruktur publik bergantung pada gatekeeper private, siapa yang mengontrol aturan akhirnya?
Ini penting karena Google dan Apple bukan sekadar vendor netral. Mereka mengontrol sistem operasi mobile, app distribution, browser engine tertentu, policy app, dan banyak API yang menentukan pengalaman user sehari-hari. Kalau digital ID publik ikut bergantung pada trust signal dari dua platform itu, dependency arsitekturnya jadi besar.
Buat developer, ini mirip keputusan dependency di codebase. Library bisa bagus, aman, dan nyaman. Tapi kalau seluruh fitur kritikal produk lu bergantung ke satu library tanpa fallback, tanpa audit, dan tanpa exit plan, itu bukan cuma pilihan teknis. Itu risiko produk.
Security feature bisa bergeser jadi control layer
Gua melihat remote attestation sebagai contoh bagus dari tradeoff yang sering lu temui di engineering: solusi security yang valid bisa punya konsekuensi governance yang tidak kecil.
- Dari sisi security: attestation membantu mengurangi device spoofing, emulator abuse, dan beberapa bentuk fraud.
- Dari sisi user: perangkat yang sah tapi dimodifikasi, lawas, atau tidak didukung vendor bisa tersingkir dari layanan penting.
- Dari sisi kompetisi: vendor platform punya posisi makin kuat karena mereka menjadi trust anchor.
- Dari sisi publik: layanan negara bisa ikut bergantung pada keputusan teknis dan policy perusahaan private.
Kalimat praktisnya begini: makin penting layanan yang dilindungi, makin penting juga pertanyaan siapa yang menentukan perangkat valid dan perangkat tidak valid.
Analogi buat developer: auth provider vs trust provider
Developer sudah terbiasa memakai OAuth provider seperti Google, GitHub, atau Apple buat login. Itu saja sudah punya tradeoff. Kalau akun user kena suspend, login ke app bisa ikut bermasalah. Kalau provider mengubah policy, flow auth bisa berubah.
Remote attestation naik satu level lebih dalam. Ia bukan cuma provider login, tapi sinyal kepercayaan terhadap perangkat. Jadi dependency-nya lebih dekat ke fondasi akses: apakah app boleh jalan, apakah credential boleh dipakai, apakah user boleh melewati proses tertentu.
Di sinilah pembahasan digital ID perlu lebih matang. Kalau layanan publik memakai wallet sebagai jalan utama, desainnya harus memikirkan orang yang tidak pakai device mainstream, user dengan perangkat lama, komunitas open-source, developer yang memakai custom ROM, sampai kebutuhan audit publik.
Checklist arsitektur yang perlu ditanya sebelum percaya digital ID
Kalau lu membaca proposal digital identity, age verification, atau wallet identitas, jangan cuma tanya “fiturnya keren atau nggak?”. Coba pakai checklist ini:
- Trust anchor: siapa yang menentukan identitas, device, atau credential valid?
- Fallback: apa yang terjadi kalau Google Play Services, Apple service, atau vendor tertentu tidak tersedia?
- Auditability: apakah aturan validasi bisa diaudit publik, atau hanya jadi black box vendor?
- Portability: apakah user bisa pindah perangkat, platform, atau provider tanpa kehilangan akses?
- Minimal disclosure: apakah user bisa membuktikan hal spesifik tanpa membocorkan data berlebihan?
- Exception flow: bagaimana nasib user dengan device lawas, custom ROM, kebutuhan aksesibilitas, atau kondisi khusus?
- Governance: siapa yang bisa mengganti aturan, memblokir akses, dan menyelesaikan dispute?
Checklist ini bukan cuma buat regulator. Developer juga perlu paham, karena pola yang sama muncul di banyak produk: login, payment, anti-bot, fraud prevention, enterprise device management, sampai AI agent access.
Pelajaran buat builder: jangan cuma lihat API yang nyaman
API yang nyaman sering menyembunyikan keputusan besar. Satu call ke Play Integrity atau device attestation bisa terlihat seperti detail implementation. Tapi kalau hasil call itu menentukan user boleh masuk atau tidak, maka API tersebut sudah jadi bagian dari policy produk.
Gua bukan anti-platform. Google dan Apple punya alasan security yang valid. Banyak abuse nyata yang memang susah ditangani tanpa sinyal dari OS dan perangkat. Tapi sistem publik butuh standar yang lebih tinggi: transparansi, akuntabilitas, fallback, dan ruang bagi alternatif.
Kalau tidak, digital ID bisa mengulang masalah platform dependency yang sudah sering terjadi di internet. Awalnya demi user experience dan security. Lama-lama semua orang sadar bahwa akses ke layanan penting melewati beberapa gatekeeper yang tidak dipilih publik.
Takeaway singkat
- Digital ID bukan cuma aplikasi; ia adalah sistem trust berlapis.
- Remote attestation berguna untuk security, tapi bisa menjadi control layer.
- Infrastruktur publik perlu menghindari dependency buta ke platform private.
- Developer perlu membaca trust anchor, fallback, auditability, dan exception flow sebelum menyebut sebuah sistem “aman”.
- Security yang bagus harus tetap bisa dipertanggungjawabkan ke user, bukan hanya ke vendor.
FAQ singkat
Apakah remote attestation selalu buruk?
Tidak. Remote attestation bisa membantu mencegah fraud, emulator abuse, dan device tampering. Masalahnya muncul saat attestation jadi syarat akses layanan penting tanpa governance, transparansi, atau fallback yang jelas.
Apakah Google dan Apple otomatis salah?
Tidak sesederhana itu. Mereka menyediakan primitive security yang banyak dipakai karena mobile ecosystem memang kompleks. Kritik yang lebih fair adalah soal dependency dan kontrol: apakah layanan publik boleh terlalu bergantung pada dua gatekeeper private?
Apa hubungannya dengan developer Indonesia?
Pola ini bakal makin sering muncul di produk lokal juga: e-KYC, fintech, health app, anti-fraud, age verification, dan AI agent access. Kalau lu bikin produk yang menentukan akses user, lu perlu paham bedanya security signal dan control layer.
Penutup
Digital identity bisa membantu internet jadi lebih aman dan lebih rapi. Tapi identitas adalah infrastruktur yang terlalu penting untuk dibangun hanya dari API yang nyaman.
Menurut gua, pertanyaan paling sehat buat semua sistem identitas digital adalah: kalau user ditolak, siapa yang bisa menjelaskan alasannya, siapa yang bisa memperbaiki, dan siapa yang punya kuasa terakhir?
Kalau jawabannya terlalu sering mengarah ke platform private, berarti desainnya belum selesai.
