bir aracı için did:key ve did:solidus

Solidus aracısı kendini bir did:solidus ile değil bir did:key ile tanıtır. Kendi kimliği zincire demirlenmemiştir. Bu sayfanın açıkça belirtmek için var olduğu olgu budur, çünkü bir okurun aksi hâlde kendi başına keşfedip kimsenin neden bundan söz etmediğini merak edeceği olgu budur.

Kendiniz kontrol edin

curl -s https://relay.solidus.network/invite | jq -r '.from, .services[0].serviceEndpoint.routingKeys[0]'
# did:key:z6LSsMkRXWM9YLF3f15cEvBtjWneDrbLjto2S53mDJqy8aT8
# did:key:z6LSsMkRXWM9YLF3f15cEvBtjWneDrbLjto2S53mDJqy8aT8

Hem davet eden kimliği hem yönlendirme anahtarı aynı did:keydir.

Her yöntem nedir

did:key açık anahtarı doğrudan tanımlayıcının içine kodlar. Onu çözümlemek için dizeyi çözersiniz: ağ çağrısı yok, defter yok, sicil yok. Güncellenemez (yeni bir anahtar yeni bir tanımlayıcıdır) ve iptal edilemez. Mümkün olan en basit DID yöntemidir ve anahtar döndürmesini yeni bir davet yayımlayarak denetlediğiniz bir hizmet uç noktası için gerçekten uygundur.

did:solidus bizim kendi yöntemimizdir ve W3C DID Method Registry içinde kayıtlıdır (bir sicil listelemesi bir listelemedir; bir W3C standardı değil, bir onay değil). Solidus zincirine karşı çözümlenir; bu da DID belgesinin, DIDComm hizmet girdisi dahil, herkesin kontrol edebileceği bir yere demirlendiği ve güncellemeyi ve devre dışı bırakmayı desteklediği anlamına gelir.

Aracı bugün neden did:key kullanıyor

Çünkü bir aracının kimliğinin dar bir işi vardır: bir muhatabın ona dış bir forward zarfını şifrelemesini ve doğru uç noktaya yönlendirmesini sağlamak. did:key bunu sıfır çözümleme bağımlılığıyla yapar: sıcak yolda RPC çağrısı yok, erişilemez olacak bir şey yok.

Maliyet de aynı ölçüde gerçektir: yeniden yayımlamadan döndürme yok, iptal yok ve aracının kendi kimliği için zincire demirlenmiş köken yok.

En çok önem taşıyan ayrım

Bu, relay'in zincire demirlenmiş çözümlemesi olmadığı anlamına gelmez. Vardır, ama kendi DID'si için değil muhatapların DID'leri için.

Relay bir did:solidus'a yönlendirmesi gerektiğinde, o DID'yi RPC üzerinden zincire karşı çözümler ve DIDComm hizmet girdisini zincir üstü belgeden okur. O yol gerçektir ve zincire demirlenmiş yönlendirme çözümlemesi sayfasında tarif edilmiştir.

Dolayısıyla dürüst tek satırlık özet şudur:

Aracı sizin yönlendirmenizi zincir üstünde çözümler. Kendini ise kendi kendine yeterli bir anahtarla tanıtır.

Bunlar iki farklı sorudur ve yalnızca "zincire demirlenmiş" diyen pazarlama dili, bir okuru ikisini de varsaymaya davet eder.

Tehdit modeliniz için önemli mi?

Muhtemelen değil, ve işte önemli olduğu durum.

Kaygınız gizlilikse pek önemli değildir: iç zarf, aracının kendini nasıl adlandırdığından bağımsız olarak muhatabınıza şifrelidir.

Ama gizlilik ile mahremiyet aynı şey değildir ve yukarıdaki cümle, tam olarak bir okurun yanılabileceği türden doğru bir cümledir. Aracı kendini nasıl adlandırırsa adlandırsın ve içeriğinizden tek kelime okuyabilsin ya da okuyamasın, yine de kimin ne zaman bağlandığını, mesaj zamanlamasını, zarf boyutunu, hacim ve sıklığı ve alıcınızın yönlendirme anahtarını öğrenir. Bu, bir aracının görebildikleri ve göremedikleri sayfasının konusudur ve bu sayfa onu tekrarlamaz.

Aracının anahtar döndürmesi ya da ele geçirilmesi kaygınızsa önemlidir. did:key ile aracının anahtarı yeni bir davet yayımlanarak değişir: döndürmenin zincir üstü kaydı yoktur ve geçmiş bir anahtarı karşılaştıracak bir şey yoktur. Yönlendirme sıçramasının kendisi için denetlenebilir bir kökene ihtiyacınız varsa bunu söyleyin; meşru bir gereksinimdir ve şu anki cevap onu sağlamadığımızdır.