Konteks dan cakupan
Beberapa universitas ingin berbagi direktori institusi dan penerbit kredensial yang dapat diverifikasi tanpa bergantung pada satu registri pusat. Jelaskan bagaimana Anda memodelkan RecognizedEntity, RecognizedAction, dan VerifiableRecognitionCredential, serta menangani privasi, pencabutan, peniruan identitas, dan registri yang berkonflik.
W3C Recognized Entities v1.0 saat ini merupakan First Public Working Draft. Dokumen ini menjelaskan model data untuk entitas yang diakui oleh suatu ekosistem untuk melakukan tindakan tertentu, memungkinkan informasi pengakuan untuk dipublikasikan atau diserahkan langsung kepada verifikator. Pertanyaan ini menguji pemodelan data yang dapat diverifikasi dan keputusan kepercayaan tanpa memperlakukan Working Draft sebagai standar final.
Hal yang dievaluasi pewawancara
Pewawancara mencari model terpisah untuk entitas, tindakan, pihak pengaku (recognizer), validitas kredensial, dan kebijakan verifikasi, ditambah pemeriksaan lintas-registri, pencabutan, dan batasan privasi. Jawaban yang kuat mencatat bahwa kredensial yang disediakan oleh pemegang (holder) tidak harus selalu diterima oleh verifikator dan bahwa pernyataan pengakuan bukanlah otorisasi bisnis otomatis.
Pertanyaan klarifikasi sebelum menjawab
- Siapa pihak pengaku, entitas yang diakui, dan verifikator akhir, serta registri mana yang dipercayai oleh masing-masing pihak?
- Apakah tindakan yang diakui tersebut berupa penerbitan, verifikasi, atau hal lain, dan bagaimana skema keluarannya didefinisikan?
- Apakah kredensial diserahkan langsung ke verifikator, atau status terkini harus diambil dari penerbit?
- Persyaratan pencabutan, validitas, rotasi kunci, dan privasi apa yang berlaku?
- Siapa yang menengahi dan mencatat alasannya ketika registri tidak sejalan?
Kerangka jawaban 30 detik
"Saya akan memodelkan entitas, tindakan, pihak pengaku, dan asersi kredensial sebagai objek yang dapat diverifikasi. RecognizedEntity terhubung melalui recognizedTo ke suatu tindakan; tindakan tersebut menyebutkan recognizedBy dan skema keluaran; dan VerifiableRecognitionCredential mencatat penerbit, validitas, serta rangkaian subjek. Verifikator memeriksa tanda tangan, status, dan waktu, lalu memilih pihak pengaku di bawah kebijakan kepercayaan lokal, mengikuti rantai pengakuan, dan memvalidasi skema keluaran. Kredensial yang disediakan pemegang dapat menghindari pencarian (lookup), tetapi tidak dapat menggantikan pemeriksaan kesegaran data untuk keputusan berisiko tinggi. Saya akan meminimalkan data pribadi dan mengaudit pencabutan, rotasi kunci, serta keputusan atas konflik."
Jawaban mendalam langkah demi langkah
1. Memodelkan entitas, tindakan, dan pengakuan
Gunakan URL unik secara global untuk entitas dan arahkan recognizedTo ke satu atau beberapa objek RecognizedAction. Tindakan mencakup nama, pihak pengaku, dan skema untuk memvalidasi keluaran; jangan menyandikan "institusi ini tepercaya" sebagai boolean tanpa cakupan (unscoped). recognizedIn dapat mereferensikan daftar kepercayaan yang ada atau kredensial pengakuan lain sehingga verifikator dapat mengidentifikasi ekosistem di balik asersi tersebut.
2. Membungkus asersi sebagai kredensial yang dapat diverifikasi
Kredensial harus mematuhi Verifiable Credentials Data Model v2.0 dan menyertakan tipenya, penerbit, validFrom, validUntil, dan entitas yang diakui dalam credentialSubject. Tanda tangan yang valid membuktikan kendali atas kunci penerbit, bukan berarti verifikator harus mempercayai penerbit tersebut; terapkan trust root lokal, allowlist, dan cakupan tindakan sebagai keputusan terpisah.
credential = {
type: ["VerifiableCredential", "VerifiableRecognitionCredential"],
issuer: "did:web:accreditor.example",
validFrom: "2026-01-01T00:00:00Z",
credentialSubject: [{
id: "did:web:university.example",
recognizedTo: [{ action: "issue", outputValidation: [schema] }]
}]
}3. Merancang verifikasi dan rantai pengakuan
Periksa sintaksis, tanda tangan, penerbit, validitas, pencabutan, dan skema terlebih dahulu, lalu tentukan apakah pihak pengaku termasuk dalam set kepercayaan lokal. Untuk rantai recognizedBy atau recognizedIn multi-level, tetapkan kedalaman maksimum, deteksi siklus, dan validasi periode setiap tingkatan; rantai yang lebih panjang tidak otomatis lebih tepercaya. Lakukan pemeriksaan silang dengan ETSI Trust Service Lists, daftar CA X.509, atau registri terkontrol lainnya saat kebijakan mewajibkannya.
4. Menangani kesegaran data dan pencabutan
Pemegang dapat menunjukkan kredensial secara langsung, mengurangi pencarian ke penerbit, tetapi verifikator memutuskan berdasarkan risiko apakah perlu memeriksa status terkini. Gunakan masa berlaku yang pendek, daftar status, pemberitahuan pencabutan, atau versi registri; catat waktu verifikasi, trust root, dan hash konteks. Pencabutan harus mengesampingkan cache hit ketika kunci dirotasi, penerbit disusupi, atau tindakan yang diakui berubah.
5. Melindungi privasi dan mencegah penyalahgunaan
Mencantumkan nama, pengenal, hubungan organisasi, dan tindakan secara publik dapat memungkinkan pengawasan atau praduga bersalah karena asosiasi (guilt by association). Minimalkan bidang data per konteks dan prioritaskan pengungkapan selektif yang dikendalikan oleh pemegang; jangan menyimpulkan properti yang tidak terkait dari satu pengakuan. Cegah pemegang jahat menyebarkan kredensial palsu dengan memvalidasi tanda tangan, status, sumber, dan skema secara bersamaan serta membatasi penerbit yang dapat diterima.
6. Mengelola konflik dan pemulihan (rollback)
Registri yang berbeda dapat menetapkan tindakan, validitas, atau status yang berbeda untuk entitas yang sama. Tentukan aturan preseden, cakupan, waktu, dan bukti sebelum menyimpan keputusan, serta audit alasan yang dipilih. Buat versi untuk konteks, skema, dan algoritma verifikasi saat Working Draft berubah; lakukan pembacaan bayangan (shadow-read) tanpa mengubah otorisasi bisnis. Peniruan identitas, kebocoran privasi, atau regresi verifikasi harus menonaktifkan jalur baru dan memulihkan registri lama.
Contoh jawaban berkualitas tinggi
Saya akan memodelkan RecognizedEntity, RecognizedAction, pihak pengaku, dan VerifiableRecognitionCredential secara terpisah. Entitas memiliki URL global, tindakan menyebutkan cakupan, pihak pengaku, dan skema keluarannya, dan kredensial mengikuti VC Data Model 2.0 dengan penerbit, validitas, dan subjek. Verifikator memeriksa tanda tangan, waktu, pencabutan, dan skema, lalu menerapkan trust root lokal dan allowlist; rantai pengakuan memiliki batas kedalaman dan siklus serta dapat diperiksa silang terhadap daftar ETSI atau X.509. Kredensial yang diserahkan oleh pemegang mengurangi pencarian tetapi tidak menghapus pemeriksaan kesegaran data untuk kasus berisiko tinggi. Minimalkan bidang data pribadi untuk menghindari pengawasan atau praduga bersalah karena asosiasi. Selesaikan konflik registri dengan aturan cakupan, waktu, dan tata kelola, lalu audit hasilnya. Buat versi konteks dan verifikator selama pembaruan Working Draft, dan lakukan rollback saat muncul peniruan identitas, pencabutan basi, atau kegagalan privasi.
Kesalahan umum
- Menganggap tanda tangan yang valid sebagai kepercayaan bisnis → ini hanya membuktikan kendali kunci → tetap periksa trust root, status, dan cakupan tindakan.
- Menyandikan pengakuan sebagai tanda tepercaya tanpa cakupan → tindakan yang diakui akan hilang → modelkan
recognizedTodan skema keluaran. - Selalu mempercayai kredensial terbaru dari pemegang → kredensial tersebut mungkin telah dicabut atau kedaluwarsa → periksa status dan validitas sesuai risiko.
- Mempublikasikan registri pribadi lengkap → agregasi data dapat memungkinkan pengawasan → minimalkan pengungkapan dan batasi agregasi.
- Mengambil hasil pertama saat registri berkonflik → keputusan menjadi tidak dapat diaudit dan dapat dimanipulasi → definisikan preseden, cakupan, waktu, dan bukti.
Pertanyaan lanjutan dan tanggapan
Mengapa kredensial pengakuan tidak memberikan izin bisnis secara langsung?
Kredensial tersebut hanya menegaskan bahwa pihak pengaku mengenal suatu entitas untuk melakukan tindakan tertentu. Izin bisnis juga bergantung pada sumber daya, tenant, waktu, risiko, dan kebijakan lokal.
Bagaimana Anda mencegah rantai pengakuan tak terbatas?
Tetapkan kedalaman maksimum, lacak pengenal yang telah dikunjungi, dan terapkan batas total; batalkan dan catat alasannya jika terjadi siklus atau batas terlampaui.
Kapan verifikator harus mengambil status terkini?
Untuk transaksi bernilai tinggi, jendela pencabutan yang pendek, kunci yang disusupi, atau perubahan versi registri. Kasus dengan risiko lebih rendah dapat menggunakan cache berversi dan terikat waktu.
Bagaimana Anda menangani seseorang yang diakui secara salah?
Sediakan jalur pencabutan, banding, dan koreksi; minimalkan bidang data publik; simpan bukti penerbitan dan verifikasi; dan berhenti menerima kredensial lama saat status yang dikoreksi mulai berlaku.
Bagaimana cara menguji Working Draft dengan aman?
Lakukan shadow-verify pada tenant yang terisolasi tanpa mengubah otorisasi bisnis, kunci spesifikasi dan vektor uji, pertahankan sakelar rollback, dan perluas setelah tinjauan implementasi dan keamanan.