Terlalu Banyak Pembahasan tentang DID

 (steveklabnik.com)
1 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Akun Bluesky tidak terikat pada aplikasi tertentu dan dapat digunakan di berbagai aplikasi berbasis atproto; DID (decentralized identifier) menyediakan fondasi verifikasi identitas yang terpisah dari aplikasi
  • DID memiliki format did:<method>:<identifier>, dan keterkaitan antara penulis postingan dan akun diverifikasi menggunakan kunci publik dan lokasi PDS yang terdapat dalam DID Document
  • did:web adalah metode sederhana yang mengambil /.well-known/did.json pada sebuah domain, tetapi rentan terhadap ketergantungan pada DNS dan registrar, penghentian server web, serta keterlambatan propagasi perubahan dokumen
  • did:plc yang dibuat Bluesky memisahkan ID dari domain tertentu dan membuat plc.directory menangani beban operasional, tetapi alih-alih DNS kita harus memercayai plc.directory, dan di Bluesky metode DID berbasis blockchain dan sejenisnya tidak dapat digunakan
  • Pengguna dapat menghapus kunci yang dibuat Bluesky dan secara nyata mengendalikan identitas mereka sendiri melalui pendaftaran kunci tambahan, rotasi kunci, dan menjalankan PDS sendiri; ini tidak memaksa semua orang mengelola kunci yang rumit, tetapi memberi pilihan bagi yang menginginkannya

Akun Bluesky dan identitas berbasis DID

  • “Akun Bluesky” bukanlah akun yang hanya dipakai di Bluesky, melainkan akun yang dapat digunakan di berbagai aplikasi dalam ATmosphere
  • atproto, protokol dasar untuk Bluesky dan aplikasi lain, menggunakan DID untuk menunjukkan siapa pengguna dan untuk memverifikasi login atau penulis postingan
  • DID yang distandardisasi W3C pada 2022 adalah identifier terdesentralisasi yang dapat digunakan aplikasi sebagai fondasi identitas
  • Sifat terdesentralisasi DID terletak pada kenyataan bahwa, alih-alih satu institusi menentukan jenis DID yang valid, pengguna dapat memilih metode DID untuk memverifikasi identitas mereka sendiri
  • Namun aplikasi tidak otomatis dapat menangani semua metode DID
    • Kode dukungan harus diimplementasikan secara terpisah untuk tiap metode
    • Jika aplikasi tidak mendukung metode foo, maka meski did:foo:1243 diajukan, aplikasi tidak dapat menafsirkannya

DID dan DID Document

  • Contoh DID did:plc:3danwc67lo7obz2fmdg6jxcr terdiri dari tiga bagian yang dipisahkan titik dua
    • Skema: did
    • Metode: plc
    • Identifier khusus metode: 3danwc67lo7obz2fmdg6jxcr
  • Untuk menggunakan DID, DID tersebut harus di-resolve menjadi DID Document
  • DID Document memuat data seperti kunci publik kriptografis agar subjek DID atau pihak yang diberi delegasi dapat mengautentikasi diri dan membuktikan keterkaitannya dengan DID tersebut
  • Dokumen contoh mencakup informasi yang diperlukan untuk verifikasi identitas
    • id: DID itu sendiri
    • alsoKnownAs: at://steveklabnik.com
    • verificationMethod: tipe Multikey dan publicKeyMultibase
    • service: endpoint PDS bertipe AtprotoPersonalDataServer
  • Ketika sebuah postingan sembarang mengklaim ditulis oleh pengguna tertentu, informasi verifikasi dalam dokumen dapat digunakan untuk memeriksa kebenaran klaim tersebut
  • Prosedur untuk menafsirkan DID menjadi dokumen ditentukan oleh standar masing-masing metode
    • did:plc mengikuti standar PLC
    • Metode lain yang didukung Bluesky, did:web, ditafsirkan dengan metode Web

Cara did:web di-resolve

  • Sangat sedikit orang memakai did:web, tetapi strukturnya sederhana sehingga proses resolve DID mudah dipahami
  • did:web:lizthegrey.com milik Liz Fong-Jones ditafsirkan dengan memasukkan lizthegrey.com, identifier khusus metodenya, ke dalam template URL berikut
https://<id>/.well-known/did.json
  • DID Document yang diterima dari URL tersebut memuat informasi berikut
    • id: did:web:lizthegrey.com
    • alsoKnownAs: at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtk
    • verificationMethod: kunci publik Multikey untuk atproto
    • serviceEndpoint: https://pds.lizthegrey.com

Keterbatasan yang dimiliki did:web

  • did:web bergantung pada DNS dan registrar domain
    • Jika registrar menarik kembali domain, kontrol atas DID juga hilang
    • Identitas juga bisa hilang jika domain tidak lagi digunakan, atau setelah kedaluwarsa dibeli orang lain
    • Hal yang sama berlaku jika akun registrar diretas dan domain diambil alih
  • Server web yang menyediakan DID Document harus terus dijalankan, dan jika server berhenti, dokumen juga tidak dapat diambil
  • Tidak ada cara untuk segera memberi tahu klien bahwa DID Document telah berubah
    • Aplikasi dapat terus menggunakan dokumen yang sudah usang
    • Karena jeda antara pembaruan dokumen dan penerapannya oleh aplikasi, masalah sementara dapat terjadi sampai dokumen terbaru diambil lagi

Bagaimana did:plc mengubah cara mempertahankan identitas

  • Bluesky mengembangkan did:plc untuk mengurangi masalah pada did:web
  • did:plc mengambil DID Document dengan memasukkan seluruh DID ke dalam template URL berikut
https://plc.directory/<did>;
  • Sama seperti did:web, metode ini mengambil URL, tetapi cara operasi dan pemeliharaan identitasnya berbeda
    • DID tidak terikat pada domain tertentu, sehingga meski steveklabnik.com dibiarkan kedaluwarsa dan dipindahkan ke steve.klabnik.com, DID yang sama tetap dapat dipertahankan
    • Operasi server web ditangani plc.directory atas nama pengguna, sehingga beban operasional berkurang
  • Namun objek kepercayaan itu sendiri tidak hilang
    • Pada did:web, kita harus memercayai DNS dan registrar domain
    • Pada did:plc, kita harus memercayai bahwa plc.directory tidak akan mengambil ID dan tidak akan diambil alih
  • Pengguna yang menganggap DNS maupun plc.directory tidak dapat dipercaya dapat memilih metode DID lain yang me-resolve nama melalui blockchain dan sebagainya
  • Namun karena Bluesky tidak mendukung metode semacam itu, metode tersebut tidak dapat digunakan dalam aplikasi Bluesky

Masalah aksesibilitas dan metode DID baru

  • Untuk mengatur did:web sendiri, pengguna non-ahli harus melakukan pekerjaan yang membebani
    • Mendaftarkan domain dan terus membayar biayanya
    • Menyiapkan server web dan menulis JSON untuk DID Document
    • Menjaga server tetap berjalan
    • Menyimpan dan mengelola private key dengan aman
  • Proses ini jauh lebih rumit daripada pendaftaran aplikasi web biasa, sehingga tidak sejalan dengan tujuan Bluesky untuk memungkinkan pengguna non-ahli memakai platformnya
  • Jika plc.directory mengelola pekerjaan terkait, pengguna tidak perlu melakukan langkah-langkah ini sendiri
  • did:webvh adalah metode yang memperluas did:web untuk menutupi sebagian kelemahannya dan telah mencapai 1.0, tetapi spesifikasi detailnya tidak termasuk dalam perbandingan ini

Cara memiliki identitas sendiri secara langsung di Bluesky

  • Dalam konfigurasi default, Bluesky membuat pasangan kunci pengguna dan dapat mengakses secret key, sehingga dalam arti tertentu Bluesky dapat dianggap memiliki identitas tersebut
  • did:plc dapat mendaftarkan pasangan kunci tambahan pada ID dan merotasi signing key
    • Kunci yang dibuat Bluesky dapat dihapus
    • Kunci itu dapat diganti dengan kunci yang dibuat langsung oleh pengguna
  • Mengganti kunci saja tidak sepenuhnya memisahkan pengguna dari infrastruktur Bluesky
    • Agar PDS dapat menandatangani postingan, PDS harus menggunakan kunci pengguna
    • Jika menggunakan PDS yang dikelola Bluesky, biasanya kunci disimpan di infrastruktur Bluesky
  • Untuk memisahkan identitas dari Bluesky, pengguna harus menjalankan PDS sendiri lalu merotasi kunci
    • Kunci disimpan di infrastruktur milik pengguna
    • Setelah itu, Bluesky tidak dapat mengendalikan kunci tersebut
  • Meskipun sebagian besar pengguna tidak memilih menjalankan PDS sendiri dan mengelola kunci, fakta bahwa pengguna yang termotivasi dapat benar-benar memiliki identitasnya adalah sifat desain yang penting
  • Daripada memaksa semua pengguna mengelola kunci sendiri, pendekatan yang memungkinkan pengguna yang menginginkannya memilih opsi tersebut lebih tepat bagi sebagian besar pengguna

Bacaan terkait

1 komentar

 
GN⁺ 5 jam lalu
Pendapat di Lobste.rs
  • plc.directory pada awalnya dikendalikan oleh Bluesky, tetapi saat ini sedang menjalani proses untuk berdiri sendiri sebagai organisasi nirlaba Swiss
  • Sejujurnya, DID adalah solusi yang lebih baik daripada autentikasi terpadu (SSO) milik perusahaan teknologi besar. Namun, DID harus bisa digunakan juga oleh orang awam seperti did:plc:, dan meski dimiliki organisasi nirlaba, tetap perlu dipikirkan apakah otoritas pusat bisa dipercaya sepenuhnya
    Saya sedang mengembangkan proyek yang mengimplementasikan ulang Keybase sambil mendukung W3C DID dan W3C Verifiable Credentials (VC). Tujuannya adalah membuktikan bahwa seseorang itu manusia secara unik namun tetap privat, dan membuat mereka memiliki identitas terdesentralisasi yang mereka kendalikan sendiri
  • Dari judulnya saya kira akan mengarah ke spesifikasi DID, ternyata tulisan aslinya juga singkat dan informatif
    • Tautan pertama di tulisan itu memang tautan spesifikasi
  • Fakta yang baru saya pelajari hari ini: DID ternyata bukan Docker in Docker
    • Ini pertama kalinya saya tahu bahwa Docker in Docker bisa dibaca sebagai DID. Selama ini saya selalu mendengarnya disingkat sebagai DinD atau dind yang malah lebih membingungkan; saya tidak tahu apakah itu hanya kebiasaan di tempat kerja saya atau memang penulisan yang umum
    • Juga bukan berarti Direct Inward Dialing
  • Untuk pembaca yang tidak menggunakan Bluesky, bisakah dijelaskan apa itu PDS?
    • PDS adalah Personal Data Server, yaitu server asal untuk konten seperti postingan
    • Dalam Bluesky/AT, alih-alih memasukkan postingan semua pengguna ke satu basis data besar, tiap pengguna memiliki penyimpanan data individual bernama PDS. Anda bisa memakai PDS yang disediakan Bluesky, meng-host sendiri, atau menggunakan layanan pihak ketiga, dan juga bisa berpindah antar-PDS secara transparan sambil tetap mempertahankan seluruh riwayat akun
      Ini tidak sama dengan instance Mastodon, dan konsep di AT serta ActivityPub tidak berkorespondensi satu banding satu secara rapi
  • Jika did:web mengharuskan hosting server .well-known dan datanya juga nyaris statis, mengapa tidak langsung menggunakan DNS yang, seperti record TXT, bisa dibaca mirip URL, kemungkinan besar di-cache, dan kecil kemungkinan berhenti secara tidak sengaja?
    Ketergantungan pada DNS dan masalah bahwa pembaruan did.json tidak mudah dideteksi memang tetap ada, tetapi jika tujuannya adalah menghubungkan domain tertentu dengan identitas seseorang, rasanya lebih baik meminimalkan komponen dan terhubung langsung ke fungsi DNS. Saya penasaran apakah ada alasan mengapa pendekatan ini tidak bekerja atau sulit diterapkan di dunia nyata