DID Hakkında Gereğinden Fazla Söz

 (steveklabnik.com)
1 puan yazan GN⁺ 5 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Bluesky hesabı belirli bir uygulamaya bağlı değildir; atproto tabanlı birden fazla uygulamada kullanılabilir ve DID (merkeziyetsiz tanımlayıcı), uygulamadan ayrılmış bir kimlik doğrulama temeli sağlar
  • DID, did:<method>:<identifier> biçimindedir ve DID Document içinde yer alan açık anahtarlar ile PDS konumu kullanılarak gönderi yazarıyla hesabın ilişkisi doğrulanır
  • did:web, alan adının /.well-known/did.json dosyasını sorgulayan basit bir yöntemdir; ancak DNS ve kayıt kuruluşu bağımlılığına, web sunucusu kesintilerine ve belge değişikliklerinin yansımasındaki gecikmelere açıktır
  • Bluesky’nin oluşturduğu did:plc, kimliği belirli bir alan adından ayırır ve işletim yükünü plc.directory üstlenir; ancak DNS yerine plc.directoryye güvenmek gerekir ve Bluesky’de blokzincir tabanlı DID yöntemleri gibi alternatifler kullanılamaz
  • Kullanıcılar ek anahtar kaydı, anahtar döndürme ve kendi PDS’lerini çalıştırma yoluyla Bluesky’nin oluşturduğu anahtarları kaldırabilir ve kimliklerini fiilen doğrudan kontrol edebilir; bu da karmaşık anahtar yönetimini herkese zorunlu kılmadan isteyenlere seçim hakkı sunar

Bluesky hesabı ve DID tabanlı kimlik

  • “Bluesky hesabı”, yalnızca Bluesky’de kullanılan bir hesap değil; ATmosphere içindeki çeşitli uygulamalarda kullanılabilen bir hesaptır
  • Bluesky’nin ve diğer uygulamaların temel protokolü olan atproto, kullanıcının kim olduğunu göstermek ve giriş ya da gönderi yazarını doğrulamak için DID kullanır
  • W3C’nin 2022’de standartlaştırdığı DID, uygulamalarda kimliğin temeli olarak kullanılabilen merkeziyetsiz bir tanımlayıcıdır
  • DID’nin merkeziyetsizliği, tek bir kurumun geçerli DID türünü belirlemesi yerine kullanıcının kendi kimliğini doğrulamak için kullanacağı DID yöntemini seçebilmesinden gelir
  • Ancak uygulamalar tüm DID yöntemlerini otomatik olarak işleyemez
    • Her yöntem için destek kodunun ayrıca uygulanması gerekir
    • Uygulama foo yöntemini desteklemiyorsa did:foo:1243 sunulsa bile bunu yorumlayamaz

DID ve DID Document

  • Örnek DID did:plc:3danwc67lo7obz2fmdg6jxcr, iki nokta üst üste ile ayrılan üç bölümden oluşur
    • Şema: did
    • Yöntem: plc
    • Yönteme özgü tanımlayıcı: 3danwc67lo7obz2fmdg6jxcr
  • Bir DID’yi kullanmak için onu DID Document olarak çözümlemek gerekir
  • DID Document, DID öznesinin ya da onun tarafından yetkilendirilmiş bir tarafın kendini doğrulamasına ve ilgili DID ile bağlantısını kanıtlamasına imkân veren kriptografik açık anahtarlar gibi verileri içerir
  • Örnek belgede kimlik doğrulama için gerekli bilgiler bulunur
    • id: DID’nin kendisi
    • alsoKnownAs: at://steveklabnik.com
    • verificationMethod: Multikey türü ve publicKeyMultibase
    • service: AtprotoPersonalDataServer türünde PDS uç noktası
  • Rastgele bir gönderinin belirli bir kullanıcı tarafından yazıldığı iddia edildiğinde, belgedeki doğrulama bilgileri kullanılarak bu iddianın doğru olup olmadığı kontrol edilebilir
  • DID’yi belgeye çözümleme süreci, yönteme özgü standart tarafından tanımlanır
    • did:plc, PLC standardını izler
    • Bluesky’nin desteklediği diğer yöntem olan did:web, Web yöntemiyle çözülür

did:web nasıl çözülür

  • did:web kullanan kişi sayısı çok azdır, ancak yapısı basit olduğu için DID çözümleme sürecini anlamayı kolaylaştırır
  • Liz Fong-Jones’un did:web:lizthegrey.com tanımlayıcısı, yönteme özgü tanımlayıcı olan lizthegrey.com değerini aşağıdaki URL şablonuna yerleştirerek çözülür
https://<id>/.well-known/did.json
  • Bu URL’den alınan DID Document şu bilgileri içerir
    • id: did:web:lizthegrey.com
    • alsoKnownAs: at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtk
    • verificationMethod: atproto için Multikey açık anahtarı
    • serviceEndpoint: https://pds.lizthegrey.com

did:webin taşıdığı kısıtlar

  • did:web, DNS ve alan adı kayıt kuruluşlarına bağımlıdır
    • Kayıt kuruluşu alan adını geri alırsa DID üzerindeki kontrol de kaybedilir
    • Alan adı artık kullanılmazsa ya da süresi dolduktan sonra başka biri tarafından satın alınırsa kimlik de kaybedilebilir
    • Kayıt kuruluşu hesabı ele geçirilip alan adı çalınırsa sonuç yine aynıdır
  • DID Document’i sunan web sunucusunun sürekli çalışır durumda olması gerekir; sunucu durursa belge de alınamaz
  • DID Document değişikliklerini istemcilere anında bildirmenin bir yolu da yoktur
    • Uygulamalar eski belgeyi kullanmaya devam edebilir
    • Belgenin güncellenmesi ile uygulamaların bunu yansıtması arasındaki gecikme, en güncel belge yeniden alınana kadar geçici sorunlara yol açabilir

did:plc kimliğin sürdürülme biçimini nasıl değiştiriyor

  • Bluesky, did:webin sorunlarını azaltmak için did:plc geliştirdi
  • did:plc, DID Document’i almak için tüm DID’yi aşağıdaki URL şablonuna yerleştirir
https://plc.directory/<did>;
  • URL sorgulama mantığı did:web ile aynı olsa da işletim ve kimliği sürdürme biçimi farklıdır
    • DID belirli bir alan adına bağlı olmadığından, steveklabnik.com süresi dolup steve.klabnik.com alan adına geçilse bile aynı DID korunabilir
    • Web sunucusunu kullanıcı yerine plc.directory işlettiği için operasyonel yük azalır
  • Güvenilmesi gereken taraf ortadan kalkmış değildir
    • did:webte DNS’e ve alan adı kayıt kuruluşlarına güvenmek gerekir
    • did:plcte ise plc.directorynin kimliği ele geçirmeyeceğine ve kendisinin ele geçirilmeyeceğine güvenmek gerekir
  • Hem DNS’e hem de plc.directoryye güvenilemeyeceğini düşünen kullanıcılar, isim çözümlemesi için blokzincir gibi alternatifler kullanan başka DID yöntemlerini seçebilir
  • Ancak Bluesky bu yöntemleri desteklemediği için Bluesky uygulamalarında kullanılamazlar

Erişilebilirlik sorunu ve yeni DID yöntemleri

  • did:webi doğrudan kurmak, uzman olmayan kullanıcılar için külfetli işler gerektirir
    • Alan adı kaydetmek ve bunun için sürekli ödeme yapmak gerekir
    • Bir web sunucusu kurup DID Document için JSON yazmak gerekir
    • Sunucunun sürekli çalışması gerekir
    • Özel anahtarları saklamak ve güvenli biçimde yönetmek gerekir
  • Bu süreç, sıradan bir web uygulamasına kaydolmaktan çok daha karmaşıktır; dolayısıyla uzman olmayan kullanıcıların da platformu kullanabilmesini hedefleyen Bluesky yaklaşımıyla örtüşmez
  • plc.directory ilgili işleri yönettiğinde kullanıcıların bu adımları doğrudan yapması gerekmez
  • did:webvh, did:webi genişleterek bazı dezavantajlarını gidermeyi amaçlayan ve 1.0 sürümüne ulaşmış bir yöntemdir; ancak burada ayrıntılı belirtimi karşılaştırma kapsamına alınmamıştır

Bluesky’de kimliğe doğrudan sahip olma yolu

  • Varsayılan ayarlarda Bluesky kullanıcının anahtar çiftini oluşturur ve gizli anahtara erişebilir; bu yüzden bir bakıma kimliğin sahibi Bluesky sayılabilir
  • did:plc, kimliğe ek anahtar çiftleri kaydetmeye ve imza anahtarlarını döndürmeye imkân tanır
    • Bluesky’nin oluşturduğu anahtar kaldırılabilir
    • Kullanıcının kendisinin oluşturduğu bir anahtarla değiştirilebilir
  • Anahtarı değiştirmek tek başına Bluesky altyapısından tamamen ayrılmak anlamına gelmez
    • PDS’nin gönderileri imzalayabilmesi için kullanıcının anahtarını kullanması gerekir
    • Bluesky tarafından yönetilen bir PDS kullanıldığında anahtar genellikle Bluesky altyapısında saklanır
  • Bluesky ile kimliği ayırmak için önce kendi PDS’nizi çalıştırıp ardından anahtarı döndürmeniz gerekir
    • Böylece anahtar kullanıcıya ait altyapıda saklanır
    • Sonrasında Bluesky bu anahtarı kontrol edemez
  • Kullanıcıların çoğu kendi PDS’sini ve anahtar yönetimini seçmese bile, isteyen kullanıcıların kimliklerine fiilen sahip olabilmesi önemli bir tasarım özelliğidir
  • Doğrudan anahtar yönetimini tüm kullanıcılara zorunlu kılmak yerine, bunu isteyen kullanıcılara seçenek olarak sunmak çoğu kullanıcı için daha uygundur

İlgili okumalar

1 yorum

 
GN⁺ 5 시간 전
Lobste.rs yorumları
  • plc.directory başlangıçta Bluesky tarafından kontrol ediliyordu, ancak şu anda İsviçre merkezli bir kâr amacı gütmeyen kuruluş olarak bağımsızlaşma sürecinde
  • Açıkçası DID, büyük teknoloji şirketlerinin birleşik kimlik doğrulamasından (SSO) daha iyi bir çözüm. Ancak did:plc: gibi sıradan insanların da kullanabilmesi gerekir; sahibi kâr amacı gütmeyen bir kuruluş olsa bile merkezi bir kuruma tamamen güvenip güvenmeyeceğimiz üzerine düşünmek gerekir
    Keybase’i yeniden uygularken W3C DID ve W3C Doğrulanabilir Kimlik Bilgileri’ni (VC) destekleyen bir proje geliştiriyorum. Amaç, bir kişinin insan olduğunu benzersiz ama gizli biçimde kanıtlayabilmesini ve kendi kontrolünde merkeziyetsiz bir kimliğe sahip olmasını sağlamak
  • Başlığa bakınca DID spesifikasyonuna bağlantı verileceğini sandım; asıl yazı da kısa ve faydalıymış
    • Yazıdaki ilk bağlantı zaten doğrudan spesifikasyon bağlantısı
  • Bugün öğrendiğim şey: DID, Docker in Docker değilmiş
    • Docker in Docker’ın DID diye okunabileceğini ilk kez öğrendim. Ben hep DinD ya da daha da kafa karıştırıcı olan dind şeklinde kısaltıldığını duymuştum; bunun iş yerindeki bir alışkanlık mı yoksa yaygın yazım mı olduğunu bilmiyorum
    • Direct Inward Dialing anlamına da gelmiyor
  • Bluesky kullanmayan okurlar için PDS’nin ne olduğunu tanımlayabilir misiniz?
    • PDS, Personal Data Server demek; gönderiler gibi içeriklerin kaynak sunucusunu ifade eder
    • Bluesky/AT, tüm kullanıcıların gönderilerini tek bir büyük veritabanına koymak yerine, her kullanıcının PDS adlı ayrı bir veri deposuna sahip olduğu bir yapı kullanır. Bluesky’nin sağladığı PDS’yi kullanabilir, kendiniz barındırabilir veya üçüncü taraf bir hizmetten yararlanabilirsiniz; ayrıca tüm hesap geçmişinizi koruyarak PDS’ler arasında şeffaf biçimde taşınabilirsiniz
      Mastodon’daki instance’larla aynı şey değildir; AT ve ActivityPub kavramları bire bir, temiz bir şekilde eşleşmez
  • did:web, bir .well-known sunucusu barındırmayı gerektiriyorsa ve veriler de neredeyse statikse, neden TXT kaydı gibi URL’ye benzer şekilde okunabilen, önbelleğe alınma olasılığı yüksek ve kazara kesintiye uğrama olasılığı düşük olan DNS’i doğrudan kullanmıyoruz?
    DNS bağımlılığı ve did.json güncellemelerini kolayca algılayamama sorunu yine kalır, ancak amaç belirli bir alan adını bir kişinin kimliğiyle ilişkilendirmekse, bileşenleri en aza indirip doğrudan DNS işlevlerine bağlanmak daha iyi görünüyor. Bu yaklaşımın çalışmamasının ya da pratikte zor olmasının bir nedeni var mı merak ediyorum