Spesifikasi Pengidentifikasi Terdesentralisasi (DID) W3C (ID)

Spesifikasi W3C Decentralized Identifiers (DIDs) mendefinisikan sintaks URI, model data umum, dokumen DID, properti inti, representasi, persyaratan metode, dan antarmuka abstrak untuk resolusi dan dereferensi URL DID. DID Core 1.0 menjadi Rekomendasi W3C pada 19 Juli 2022. DID Core 1.1 diterbitkan sebagai Snapshot Rekomendasi Kandidat pada 5 Maret 2026; ini adalah pekerjaan yang lebih baru pada tahap standar yang berbeda.

DID Core tidak memerlukan blockchain, membuktikan identitas hukum seseorang, menyimpan kredensial di setiap dokumen DID, atau membuat setiap titik akhir yang diselesaikan dapat dipercaya. Ini menstandardisasi arsitektur pengidentifikasi dan dokumen. Metode DID terpisah mendefinisikan bagaimana DID tertentu dibuat, dibaca, diperbarui, dan dinonaktifkan pada infrastruktur yang dipilihnya.

Poin-poin Penting

• DID adalah URI, bukan kredensial. Bentuk umumnya adalah did:<method-name>:<method-specific-id>.
• Subjek dan pengontrol adalah peran yang berbeda. Subjek adalah apa yang diidentifikasi oleh DID; pengontrol diberi wewenang oleh metode untuk mengubah dokumen DID.
• Kunci membutuhkan tujuan yang eksplisit. Metode verifikasi menjadi dapat digunakan untuk otentikasi, pernyataan, kesepakatan kunci, pemanggilan kemampuan, atau delegasi hanya melalui hubungan verifikasi yang sesuai.
• Metode ini menyediakan aturan operasional. DID Core bersifat netral teknologi; metode ini mendefinisikan interaksi registri, otorisasi, pembaruan, penonaktifan, dan resolusi spesifik metode.
• Resolusi tidak menciptakan kepercayaan dengan sendirinya. Pelaksana harus mengautentikasi hasil metode, memberlakukan tujuan bukti, mengelola kunci dan riwayat, melindungi privasi, dan menerapkan kebijakan aplikasi.

Apa itu pengidentifikasi terdesentralisasi?

Pengidentifikasi terdesentralisasi adalah pengidentifikasi yang dirancang agar kontrol dapat ditetapkan tanpa memerlukan satu penyedia identitas pusat atau otoritas sertifikat untuk menerbitkan dan memelihara setiap pengidentifikasi. Kata “terdesentralisasi” menggambarkan kemampuan arsitektur untuk memisahkan kontrol pengidentifikasi dari penerbit pusat tunggal; ini tidak berarti bahwa setiap implementasi bersifat anonim, publik, tidak dapat diubah, atau disimpan di buku besar terdistribusi.

DID dapat mengidentifikasi:

• seseorang;
• organisasi atau kelompok;
• perangkat atau objek fisik;
• sumber daya digital;
• model data;
• konsep abstrak.

Entitas yang diidentifikasi adalah subjek DID. String saja tidak mengungkapkan jenis subjek.

Sintaks DID

Sintaks umum adalah:

did:<method-name>:<method-specific-id>

Misalnya:

did:example:123456789abcdefghi

did adalah skema URI. example adalah nama metode DID. String yang tersisa adalah pengidentifikasi spesifik metode. Spesifikasi metode mendefinisikan apa arti nilai tersebut dan bagaimana perangkat lunak memprosesnya.

DID yang terlihat valid belum tentu dapat digunakan. Metode harus ada dan resolver harus mendukungnya.

URL DID: jalur, kueri, dan fragmen

URL DID dimulai dengan DID dan dapat menambahkan jalur, kueri, atau fragmen:

did:example:123456789abcdefghi/path?service=messages#key-1

Komponen-komponen ini dapat mengidentifikasi atau membantu memilih:

• metode verifikasi di dalam dokumen DID;
• entri layanan;
• fragmen dokumen DID lainnya;
• sumber daya yang dicapai melalui layanan;
• versi atau opsi yang ditentukan metode.

Fragmen #key-1 umumnya mengidentifikasi metode verifikasi. Ini tidak berarti kunci pribadi ada di dokumen. Dokumen DID menerbitkan materi verifikasi publik atau referensi; materi rahasia harus tetap dilindungi di tempat lain.

Arsitektur DID

Konsep-konsep utama saling terkait tetapi tidak dapat dipertukarkan:

Konsep	Peran
DID	Pengidentifikasi unik global yang sesuai dengan sintaks DID
Subjek DID	Orang, organisasi, benda, sumber daya, atau konsep yang diidentifikasi
Pengontrol DID	Entitas yang diberi wewenang di bawah metode DID untuk mengubah dokumen DID
Dokumen DID	Data yang terkait dengan subjek, termasuk metode verifikasi dan layanan yang diizinkan
Metode DID	Spesifikasi terpisah untuk sintaks dan operasi spesifik metode
Registri data yang dapat diverifikasi	Infrastruktur yang digunakan metode untuk membuat, membaca, memperbarui, atau menonaktifkan status DID
Resolver DID	Perangkat lunak atau perangkat keras yang melakukan resolusi DID untuk metode yang didukung
Dereferencer URL DID	Perangkat lunak atau perangkat keras yang memperoleh sumber daya yang diidentifikasi oleh URL DID

Subjek versus pengontrol

Subjek dan pengontrol bisa menjadi entitas yang sama, tetapi tidak harus. Orang tua dapat mengontrol DID untuk seorang anak, organisasi dapat mengontrol DID untuk suatu perangkat, atau beberapa wali dapat mengontrol pengaturan pemulihan.

controller tingkat atas mengidentifikasi satu atau lebih pengontrol DID. controller yang diperlukan oleh metode verifikasi mengidentifikasi siapa yang mengontrol metode tersebut; itu tidak secara otomatis menjadi pengontrol DID tingkat atas. Mengacaukan keduanya dapat memberikan wewenang yang tidak disengaja.

Apa itu dokumen DID?

Dokumen DID adalah data yang terkait dengan subjek DID di bawah model data DID Core. id akarnya adalah DID. Properti inti opsional dapat menjelaskan pengontrol, pengidentifikasi alternatif, metode verifikasi, hubungan verifikasi, dan layanan.

Contoh yang disederhanakan ini menggunakan materi publik dari ruang contoh spesifikasi:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    }
  ],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-1"
  ]
}

did:example dicadangkan untuk contoh; sistem produksi harus menggunakan metode aktual dan persyaratan suite metode verifikasinya saat ini. JSON di atas sengaja valid JSON. Banyak contoh yang dicetak di dalam spesifikasi teknis berisi komentar atau elipsis agar mudah dibaca dan tidak boleh disalin langsung ke parser.

Properti inti

• id: DID untuk subjek; diperlukan pada akar dokumen.
• controller: satu atau lebih DID yang diizinkan untuk membuat perubahan di bawah metode.
• alsoKnownAs: URI lain yang diklaim mengidentifikasi subjek yang sama.
• verificationMethod: mekanisme verifikasi publik yang dapat direferensikan oleh hubungan eksplisit.
• authentication: metode yang diizinkan untuk otentikasi sebagai subjek.
• assertionMethod: metode yang diizinkan untuk menyatakan klaim, seperti penerbitan kredensial.
• keyAgreement: metode yang dimaksudkan untuk mendapatkan materi rahasia bersama.
• capabilityInvocation: metode yang diizinkan untuk memanggil kemampuan.
• capabilityDelegation: metode yang diizinkan untuk mendelegasikan kemampuan.
• service: titik akhir atau mekanisme interaksi yang terkait dengan subjek.

alsoKnownAs adalah sebuah pernyataan, bukan bukti kriptografi bahwa dua pengidentifikasi setara. Aplikasi harus secara independen memverifikasi hubungan yang diperlukan oleh model kepercayaan mereka.

Model data dan representasi

DID Core mendefinisikan model data abstrak dan aturan untuk menghasilkan dan mengonsumsi representasi. Model data tidak identik dengan satu serialisasi JSON.

Persyaratan representasi bersifat spesifik versi:

• Rekomendasi DID Core 1.0 tahun 2022 mendefinisikan application/did+json dan application/did+ld+json. Representasi JSON-LD-nya dimulai dengan konteks dasar https://www.w3.org/ns/did/v1.
• Rekomendasi Kandidat DID Core 1.1 mengonsolidasikan tipe media inti ke application/did. Representasi JSON-LD-nya dimulai dengan https://www.w3.org/ns/did/v1.1.

Jangan mencampur tipe media atau konteks dasar dari satu versi dengan klaim kesesuaian dengan yang lain. Tentukan versi spesifikasi yang diimplementasikan oleh produsen dan konsumen.

Pelaksana harus menegosiasikan dan memvalidasi representasi secara eksplisit. Menandatangani byte JSON serial yang sewenang-wenang tanpa kanonisasi yang ditentukan dan mekanisme pengamanan tidak setara dengan memproses model data DID dengan benar.

Metode verifikasi dan hubungan verifikasi

Metode verifikasi menjelaskan bagaimana suatu bukti dapat diperiksa. Ini membutuhkan:

• sebuah id yang diekspresikan sebagai URL DID;
• sebuah type;
• sebuah controller;
• materi verifikasi yang sesuai dengan tipe tersebut.

Materi publik dapat direpresentasikan melalui properti yang ditentukan seperti publicKeyJwk atau bentuk lain yang diizinkan oleh suite metode verifikasi. JWK dalam dokumen DID tidak boleh menyertakan materi kunci pribadi. Materi verifikasi yang sama tidak boleh diduplikasi dalam beberapa properti materi dalam satu metode.

Mendefinisikan metode verifikasi tidak mengizinkannya untuk setiap tujuan. Otorisasi berasal dari lima hubungan verifikasi eksplisit.

Hubungan	Tujuan bukti yang dimaksudkan
authentication	Otentikasi sebagai subjek DID melalui tantangan-respons atau mekanisme lain yang diterima
assertionMethod	Mengungkapkan klaim, termasuk menandatangani Kredensial yang Dapat Diverifikasi di mana mekanisme pengamanan yang dipilih menggunakannya
keyAgreement	Membangun materi kriptografi bersama, seringkali untuk enkripsi
capabilityInvocation	Memanggil kemampuan objek
capabilityDelegation	Mendelegasikan kemampuan objek

Verifikator harus memeriksa hubungan yang diperlukan untuk bukti. Kunci yang hanya tercantum di bawah authentication tidak secara otomatis diizinkan untuk pernyataan kredensial atau kesepakatan kunci.

Hubungan dapat menyematkan metode verifikasi lengkap atau mereferensikannya dengan URL DID. Referensi meningkatkan penggunaan kembali tetapi memerlukan dereferensi yang benar dan perbandingan pengidentifikasi yang tepat.

Layanan dan titik akhir layanan

Properti service opsional dapat mengiklankan cara untuk berkomunikasi atau berinteraksi dengan subjek DID. Setiap entri layanan memiliki:

• id unik;
• sebuah type;
• sebuah serviceEndpoint.

Titik akhir bisa berupa URI atau struktur lain yang diizinkan. Definisi layanan dapat diperluas, sehingga aplikasi harus memahami jenis yang dipilih.

Menerbitkan titik akhir tidak membuktikan bahwa server, operator, transportasi, konten, atau tujuannya dapat dipercaya.

Aplikasi harus mengautentikasi status DID yang diselesaikan melalui metode tersebut, memvalidasi jenis layanan, menerapkan kontrol keamanan URL dan jaringan, dan menggunakan protokol aplikasi dengan properti keamanannya sendiri.

Titik akhir layanan publik juga dapat menciptakan korelasi. Menggunakan kembali satu titik akhir di seluruh DID berpasangan dapat mengalahkan manfaat privasi dari pengidentifikasi terpisah.

Apa yang didefinisikan oleh metode DID

DID Core menyediakan arsitektur umum. Metode DID yang sesuai mendefinisikan aturan spesifik metode yang diperlukan untuk mengimplementasikannya, termasuk:

• nama metode dan sintaks pengidentifikasi spesifik metode;
• bagaimana DID dan dokumen DID awal dibuat;
• bagaimana status saat ini dibaca;
• bagaimana pembaruan yang diotorisasi diajukan dan diverifikasi;
• bagaimana DID dinonaktifkan;
• bagaimana resolusi berkomunikasi dengan registri;
• bagaimana keaslian dan integritas hasil ditetapkan;
• bagaimana rotasi kunci, pemulihan, versi, dan riwayat bekerja;
• pertimbangan keamanan dan privasi spesifik metode.

Registri data yang dapat diverifikasi bisa berupa buku besar terdistribusi, sistem file terdesentralisasi, jaringan peer-to-peer, basis data, atau sistem lain. Arsitektur harus dievaluasi berdasarkan tata kelola, ketersediaan, otorisasi, privasi, biaya, riwayat, dan ketahanan terhadap serangan daripada kata “terdesentralisasi.”

Kriteria pemilihan metode

Sebelum memilih metode, uji:

• kematangan dan tata kelola spesifikasi;
• interoperabilitas resolver dan pustaka;
• otorisasi pembaruan dan penonaktifan;
• rotasi dan pemulihan kunci;
• dukungan status historis;
• kebocoran privasi dan metadata;
• ketersediaan registri dan risiko sensor;
• biaya transaksi atau operasi;
• kelincahan kriptografi;
• migrasi dan kegagalan metode.

Mengubah metode biasanya berarti memperkenalkan pengidentifikasi baru dan jalur migrasi yang terpercaya.

Resolusi DID versus dereferensi URL DID

Resolusi DID mengambil DID dan opsi resolusi dan mengembalikan:

1. metadata resolusi DID;
2. dokumen DID, aliran dokumen, atau tidak ada dokumen;
3. metadata dokumen DID.

Resolver menggunakan operasi “baca” yang ditentukan oleh metode. DID Core mendefinisikan antarmuka abstrak dan konsep hasil umum; komunikasi dan otentikasi spesifik metode tetap dengan metode.

Dereferensi URL DID mengambil URL DID lengkap dan mengembalikan:

1. metadata dereferensi;
2. sumber daya yang diidentifikasi, jika tersedia;
3. metadata konten.

Dereferensi mungkin pertama-tama menyelesaikan DID dasar dan kemudian memilih fragmen, layanan, atau sumber daya eksternal. Ini bukan sinonim untuk resolusi.

Spesifikasi Resolusi DID W3C yang terpisah mengembangkan algoritma resolusi dan dereferensi yang terperinci. Publikasi terbarunya adalah Draf Kerja W3C tertanggal 24 Juli 2026, dan dereferensi URL DID ditandai sebagai fitur yang berisiko. Ini tetap merupakan pekerjaan jalur standar daripada bagian dari Rekomendasi DID Core 1.0 tahun 2022, jadi tentukan draf sebelum mengklaim kesesuaian.

Kepercayaan resolver dan cache

Resolver adalah batas keamanan dan privasi. Ini melihat pengidentifikasi yang diminta dan dapat mengembalikan status yang usang atau dimanipulasi. Evaluasi:

• verifikasi hasil metode;
• otentikasi transportasi dan resolver;
• kesegaran dan invalidasi cache;
• opsi versi dan waktu;
• penanganan kesalahan dan perilaku penurunan;
• kebocoran privasi melalui pencarian;
• perilaku selama kegagalan registri atau jaringan.

DID dan Kredensial yang Dapat Diverifikasi

DID dan Kredensial yang Dapat Diverifikasi adalah spesifikasi yang saling melengkapi, bukan objek yang sama.

DID dasar dapat mengidentifikasi:

• penerbit kredensial;
• subjek kredensial;
• pemegang.

Metode verifikasi yang digunakan oleh mekanisme pengamanan malah diidentifikasi oleh URL DID, umumnya DID diikuti oleh fragmen seperti #key-1.

Model Data Kredensial yang Dapat Diverifikasi W3C 2.0 mendefinisikan kredensial, presentasi, penerbit, pemegang, subjek, validitas, status, skema, dan mekanisme pengamanan. Ini tidak mengharuskan setiap pengidentifikasi menjadi DID.

Ketika DID digunakan untuk penerbit, verifikator mungkin menyelesaikan DID penerbit, menemukan metode verifikasi bukti, dan mengonfirmasi bahwa metode tersebut diizinkan di bawah assertionMethod. Verifikasi kriptografi itu masih belum menetapkan:

• bahwa setiap klaim kredensial adalah benar;
• bahwa penerbit dipercaya untuk klaim tersebut;
• bahwa kredensial saat ini atau dapat diterima;
• bahwa status, skema, atau buktinya memenuhi kebijakan;
• bahwa subjek kredensial adalah orang yang mempresentasikannya.

Pemeriksaan tersebut termasuk dalam mekanisme pengamanan, sistem status, kerangka kepercayaan, pengikatan presentasi, dan kebijakan pihak yang mengandalkan.

Pertimbangan privasi dan keamanan

Hindari data pribadi dalam dokumen publik

Dokumen DID dapat direplikasi secara luas. Jangan menerbitkan nama, pengidentifikasi pemerintah, biometrik, kredensial, atau data pribadi lainnya hanya karena modelnya dapat diperluas. Enkripsi bukanlah jawaban yang tahan lama untuk ciphertext yang bersifat publik secara permanen.

Mencegah korelasi

DID berpasangan atau spesifik konteks dapat mengurangi korelasi hanya jika data lain juga dipisahkan. Kunci yang digunakan kembali, titik akhir layanan, pengidentifikasi jaringan, atribut kredensial, waktu, dan aktivitas registri dapat menghubungkan DID yang dianggap terpisah.

Rotasi dan pemulihan kunci

Rencanakan kompromi sebelum peluncuran. Tentukan otorisasi pembaruan, pengontrol pemulihan, aturan ambang batas, rotasi, penanganan kunci lama, dan penonaktifan. Otoritas pemulihan membutuhkan pemisahan dan audit.

Validasi tujuan bukti

Periksa tidak hanya bahwa tanda tangan memverifikasi, tetapi juga bahwa metode verifikasi diizinkan untuk hubungan yang diperlukan pada waktu yang relevan. Cegah substitusi antara otentikasi, pernyataan, kesepakatan, dan penggunaan kemampuan.

Tangani riwayat dengan hati-hati

Dokumen DID saat ini mungkin tidak lagi berisi kunci lama. Memverifikasi bukti historis dapat memerlukan versi historis yang didukung metode dan bukti waktu bukti yang andal. “Kunci tidak ada sekarang” dan “bukti tidak pernah valid” bukanlah kesimpulan yang setara.

Kesalahan umum implementasi DID

Menyebut DID Core sebagai spesifikasi blockchain

DID Core bersifat netral teknologi. Blockchain adalah salah satu arsitektur registri yang mungkin.

Memperlakukan DID sebagai bukti identitas hukum

DID mendukung kontrol pengidentifikasi dan verifikasi kriptografi. Pengikatan identitas dunia nyata membutuhkan bukti terpisah, pernyataan penerbit, atau kerangka kepercayaan.

Menggunakan kunci yang terdaftar untuk tujuan apa pun

Terapkan hubungan verifikasi eksplisit dan tujuan bukti.

Mempercayai titik akhir layanan secara otomatis

Validasi status metode dan terapkan keamanan aplikasi, transportasi, URL, dan konten.

Mengasumsikan semua DID bersifat pribadi atau anonim

Aktivitas registri, resolusi, materi yang digunakan kembali, dan layanan dapat mengekspos korelasi yang tahan lama.

Daftar periksa implementasi

Sebelum produksi, konfirmasi bahwa:

• versi DID Core yang dipilih dan spesifikasi metode DID telah ditentukan;
• parsing pengidentifikasi dan URL DID menggunakan penanganan URI yang sesuai standar;
• representasi dan tipe media yang diterima bersifat eksplisit;
• setiap bukti memberlakukan hubungan verifikasi yang dimaksudkan;
• hasil metode diautentikasi daripada dipercaya dari resolver mana pun;
• caching, versi, verifikasi historis, dan penonaktifan telah diuji;
• pembaruan, rotasi, kompromi, pemulihan, dan migrasi memiliki prosedur yang dilatih;
• dokumen publik tidak berisi data pribadi atau data korelasi yang tidak perlu;
• titik akhir layanan menerima tinjauan keamanan lapisan aplikasi terpisah;
• kepercayaan Kredensial yang Dapat Diverifikasi, status, skema, dan pemeriksaan presentasi tetap terpisah.

Di mana DID bertemu verifikasi identitas

DID dapat mengidentifikasi subjek dan materi verifikasi, tetapi tidak melakukan pembuktian identitas. Sistem identitas yang dapat digunakan kembali masih membutuhkan bukti yang andal dan keputusan yang diatur sebelum mengeluarkan atau menerima klaim. Verifikasi ID Didit dapat memberikan bukti identitas untuk keputusan tersebut, sementara Reusable KYC mendukung penggunaan kembali verifikasi sebelumnya di seluruh layanan yang berpartisipasi dan tercantum sebagai gratis.

Kedekatan produk tersebut tidak menyiratkan bahwa setiap verifikasi Didit adalah DID atau bahwa resolusi DID menggantikan KYC. Tarif modul saat ini tersedia di halaman harga. Arsitektur harus menjaga kontrol pengidentifikasi, bukti identitas, penerbitan kredensial, presentasi, dan kebijakan pihak yang mengandalkan sebagai batas kepercayaan yang terpisah.

Pertanyaan yang sering diajukan

Apa yang didefinisikan oleh spesifikasi W3C DID?

Ini mendefinisikan sintaks DID dan URL DID, model data umum, properti DID-dokumen inti, representasi, persyaratan metode, serta antarmuka resolusi dan dereferensi abstrak.

Apakah setiap DID menggunakan blockchain?

Tidak. Metode DID dapat menggunakan buku besar, basis data, sistem peer-to-peer, sistem file terdesentralisasi, atau arsitektur registri lainnya.

Apa perbedaan antara DID dan dokumen DID?

DID adalah pengidentifikasi. Dokumen DID adalah data terkait yang dapat menjelaskan pengontrol, metode verifikasi dan tujuannya, layanan, dan properti lain yang ditentukan.

Apa perbedaan antara resolusi dan dereferensi?

Resolusi memperoleh dokumen DID dan metadata untuk DID. Dereferensi memperoleh sumber daya yang diidentifikasi oleh URL DID lengkap, berpotensi setelah menyelesaikan DID dasarnya.

Apakah DID sama dengan Kredensial yang Dapat Diverifikasi?

Tidak. DID adalah pengidentifikasi. Kredensial yang Dapat Diverifikasi adalah seperangkat klaim yang tahan gangguan dan dapat diverifikasi secara mesin di bawah model data VC dan mekanisme pengamanan. VC dapat menggunakan DID tetapi tidak secara universal memerlukannya.

Apakah mengontrol DID membuktikan siapa seseorang itu?

Tidak. Ini dapat membuktikan kontrol otoritas kriptografi atau spesifik metode yang terkait dengan DID. Mengikat kontrol itu ke identitas hukum atau dunia nyata membutuhkan bukti tambahan atau pernyataan yang dipercaya.

Bisakah dokumen DID berisi kunci pribadi?

Tidak. Dokumen DID berisi materi verifikasi publik atau referensi. Materi kunci pribadi tidak boleh muncul dan harus tetap dilindungi oleh sistem manajemen kunci pengontrol.

Referensi utama

• W3C Decentralized Identifiers (DIDs) v1.0
• W3C Decentralized Identifiers (DIDs) v1.1
• W3C Decentralized Identifier Resolution
• W3C DID Specification Registries
• W3C Verifiable Credentials Data Model v2.0

DID Core paling berguna ketika klaimnya tetap tepat. Ini menstandardisasi pengidentifikasi, dokumen, tujuan verifikasi, layanan, dan antarmuka metode. Kepercayaan masih berasal dari tata kelola metode, resolusi yang diautentikasi, kunci yang dilindungi, tujuan bukti eksplisit, desain yang sadar privasi, dan keputusan aplikasi tentang bukti apa yang akan diterima.