Saat melihat Citadel 2 dari $DUSK , poin “sekali KYC bisa digunakan di mana saja” benar-benar membuatku paham. Aku meluangkan sedikit waktu untuk menenangkan diri dan membaca dokumen serta repositori kodenya, barulah kusadari bahwa di balik itu ada beberapa prasyarat yang tersembunyi.
Gambaran singkat dari seluruh prosesnya seperti ini: pengguna menyelesaikan verifikasi identitas offline melalui LP, mendapatkan kredensial terenkripsi yang kemudian di-anchoring ke blockchain. Setelah itu, saat mengakses berbagai aplikasi, pengguna membuktikan kepatuhan melalui proof ZK tanpa perlu mengekspos informasi privasi.
Awalnya aku mengira, selama sudah melakukan satu kali KYC dan mendapat kredensial, maka bisa dipakai di mana-mana. Namun ketika mengikuti alur logika protokol Citadel, aku menemukan satu detail kunci: Service Provider punya hak untuk menentukan sendiri lisensi provider mana yang mereka anggap tepercaya.
Citadel sendiri tidak memaksa semua SP menerima standar kredensial yang sama. Misalnya, bisnis A mempercayai LP tertentu, sementara bisnis B bisa saja tidak mengakuinya. Kalau di bisnis A kamu melakukan KYC dan mendapatkan kredensial dari LP yang tidak diterima oleh bisnis B, maka kamu harus mengulang KYC dari awal. Jangkauan “sekali KYC” secara alami terbatas pada “lingkaran kecil” yang saling mengakui kumpulan LP yang sama. Keluar dari lingkaran itu, penggunaan ulang menjadi tidak berlaku $BTR
Aku awalnya ingin melihat seperti apa kualitas dokumen integrasi untuk institusi. Setelah berkeliling, memang ada W3sper SDK, tapi untuk versi yang benar-benar lengkap dari panduan integrasi level institusi dan skema manajemen izin, aku tidak menemukan yang terlalu menyeluruh. Bisa jadi juga tempat yang aku cari kurang tepat, tapi setidaknya dari kanal publik yang terlihat, jika institusi ingin langsung masuk, ambangnya memang tidak rendah.
Sebagai perbandingan, ambil contoh eIDAS Uni Eropa: di dunia nyata, verifikasi timbal balik identitas sudah lama didorong, hanya saja tidak bergantung pada ZK. Ide teknis Citadel tidak salah, tapi protokol identitas sangat bergantung pada efek jaringan. Agar sistem ini bisa berjalan, harus ada banyak LP berlisensi, dan berbagai SP bisnis bersedia menerima kredensial-kredensial tersebut. Aku sempat mencari apakah sudah ada contoh LP berlisensi eksternal yang sudah benar-benar go-live, tetapi setelah mencari berkeliling, aku tidak menemukan informasi publik yang jelas. Mungkin juga masih tahap awal, jadi informasinya belum tersebar luas—tetapi setidaknya yang terlihat sekarang, upaya utama masih #dusk sendiri, dan jejak partisipasi dari pihak LP eksternal belum terlalu jelas.
Untuk sementara aku tidak menyimpulkan secara negatif, tapi aku akan terus memantau dua sinyal kunci: terwujudnya LP berlisensi eksternal dan peluncuran resmi JS SDK. Belum melihat dua perubahan ini, “KYC yang bisa dipakai seumur hidup” masih punya perjalanan panjang yang harus ditempuh @Dusk .
Gambaran singkat dari seluruh prosesnya seperti ini: pengguna menyelesaikan verifikasi identitas offline melalui LP, mendapatkan kredensial terenkripsi yang kemudian di-anchoring ke blockchain. Setelah itu, saat mengakses berbagai aplikasi, pengguna membuktikan kepatuhan melalui proof ZK tanpa perlu mengekspos informasi privasi.
Awalnya aku mengira, selama sudah melakukan satu kali KYC dan mendapat kredensial, maka bisa dipakai di mana-mana. Namun ketika mengikuti alur logika protokol Citadel, aku menemukan satu detail kunci: Service Provider punya hak untuk menentukan sendiri lisensi provider mana yang mereka anggap tepercaya.
Citadel sendiri tidak memaksa semua SP menerima standar kredensial yang sama. Misalnya, bisnis A mempercayai LP tertentu, sementara bisnis B bisa saja tidak mengakuinya. Kalau di bisnis A kamu melakukan KYC dan mendapatkan kredensial dari LP yang tidak diterima oleh bisnis B, maka kamu harus mengulang KYC dari awal. Jangkauan “sekali KYC” secara alami terbatas pada “lingkaran kecil” yang saling mengakui kumpulan LP yang sama. Keluar dari lingkaran itu, penggunaan ulang menjadi tidak berlaku $BTR
Aku awalnya ingin melihat seperti apa kualitas dokumen integrasi untuk institusi. Setelah berkeliling, memang ada W3sper SDK, tapi untuk versi yang benar-benar lengkap dari panduan integrasi level institusi dan skema manajemen izin, aku tidak menemukan yang terlalu menyeluruh. Bisa jadi juga tempat yang aku cari kurang tepat, tapi setidaknya dari kanal publik yang terlihat, jika institusi ingin langsung masuk, ambangnya memang tidak rendah.
Sebagai perbandingan, ambil contoh eIDAS Uni Eropa: di dunia nyata, verifikasi timbal balik identitas sudah lama didorong, hanya saja tidak bergantung pada ZK. Ide teknis Citadel tidak salah, tapi protokol identitas sangat bergantung pada efek jaringan. Agar sistem ini bisa berjalan, harus ada banyak LP berlisensi, dan berbagai SP bisnis bersedia menerima kredensial-kredensial tersebut. Aku sempat mencari apakah sudah ada contoh LP berlisensi eksternal yang sudah benar-benar go-live, tetapi setelah mencari berkeliling, aku tidak menemukan informasi publik yang jelas. Mungkin juga masih tahap awal, jadi informasinya belum tersebar luas—tetapi setidaknya yang terlihat sekarang, upaya utama masih #dusk sendiri, dan jejak partisipasi dari pihak LP eksternal belum terlalu jelas.
Untuk sementara aku tidak menyimpulkan secara negatif, tapi aku akan terus memantau dua sinyal kunci: terwujudnya LP berlisensi eksternal dan peluncuran resmi JS SDK. Belum melihat dua perubahan ini, “KYC yang bisa dipakai seumur hidup” masih punya perjalanan panjang yang harus ditempuh @Dusk .