DID'inizi Çözümlemek Birine Haber Veriyor mu?
Sorunun aslında ilgili olduğu problem
Pek çok kimlik sisteminde, sizin hakkınızda bir şeyi kontrol etmek onu veren tarafla iletişime geçer. Eve telefon problemi budur ve bir doğruluk özelliğinin içinde gizlenen bir mahremiyet arızasıdır: veren, size verdiği şeyi kullandığınız her yerin kaydına sahip olur.
Taşıyıcı denetimli bir kimlik bilgisinin o bağı kırması beklenir. Peki: bizimki kırıyor mu?
Cevap bir: bir DID'i çözümlemek öznesine haber vermiyor
Size hiçbir geri çağrı ulaşmıyor. Bir did:solidus, öznenin işlettiği bir hizmete karşı değil
zincir durumuna karşı çözümleniyor. Cihazınıza kimse yoklama göndermiyor ve hiçbir bildirim
üretilmiyor.
Bir çözümlemeyi izleyebilirsiniz:
$ curl -s -X POST https://rpc.solidus.network -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","method":"solidus_didResolve","params":["did:solidus:testnet:1111111111111111111111zz"],"id":1}'
{"jsonrpc":"2.0","id":1,"result":null}
Canlı, 2026-07-31. Ve cevabın genel bir geri düşüş olmadığının kontrolü: uydurma bir yöntem
-32601 Method not found döndürüyor. Farklı yanıtlar, dolayısıyla çözümleme yöntemi gerçekten
orada.
Cevap iki: çözümleyici sorguyu görüyor ve bugün çözümleyici biziz
Başlığın sorusunun atlama eğiliminde olduğu kısım burası. Çözümleme bir düğüme yapılan bir istektir. O düğümü kim çalıştırıyorsa hangi DID'in sorulduğunu, ne zaman ve nereden sorulduğunu görür.
Yukarıdaki açık RPC uç noktası bizim. Yani "bir DID'i çözümlemek kimseye haber vermiyor" özne hakkında doğrudur ve işletmeci hakkında yanlıştır ve merkeziyetsiz bir veri modelini göstermek isteği kimin yanıtladığını değiştirmez.
Azaltıcı önlem gerçektir ve sizin için yapabileceğimiz bir şey değildir: kendi düğümünüzü çalıştırın ya da güvendiğiniz birini kullanın. Zincir durumu açıktır ve çoğaltılabilir; azaltıcı önlemi mümkün kılan özellik odur. Bunu yapana kadar çözümleme örüntünüz konusunda bize güveniyorsunuz ve "merkeziyetsiz"in bunu geçiştirmesine izin vermektense o cümleyi yazmayı tercih ederiz.
Ve ilgili bir dürüstlük noktası: doğrulayıcı başına tanımlayıcılar kasten hiç demirlenmez; açık zincirde hiçbir şeye çözümlenirler. Bu, en çok kullandığınız tanımlayıcıların kimsenin çözümlediği tanımlayıcılar olmadığı anlamına gelir, ki bu bir çözümleyicinin öğrenebileceğini gözle görülür biçimde azaltır. Gerçek bir azaltıcı önlemdir ve düğümü denetlemenin yerine geçmez.
Cevap üç: iptal kontrolü, iki kimlik bilgisi biçiminin ayrıldığı yer
İki kimlik bilgisi yolu çalıştırıyoruz ve dürüstçe farklı iki cevabı var. Burada tek bir hikâye yok.
SD-JWT yolu durum listesi tarzı kontrol kullanıyor. Bir doğrulayıcı, özel olarak sizin kimlik bilginiz hakkında sormak yerine birçok kimlik bilgisini kapsayan bir listeyi çekiyor ve sizin yuvanızı okuyor. Bu maruziyeti azaltır (veren hangi kimlik bilgisinin kontrol edildiğini öğrenmez) ama ortadan kaldırmaz: bir listeyi çekmek, onu sunan her kimse ona kabaca hangi kohortun kontrol edildiğini ve ne zaman kontrol edildiğini yine söyler.
Uç nokta canlı, /status-lists/:id adresinde, bir durum listesi jetonu imzalayıp döndürüyor. Kendi lexicon'umuz bugüne kadar aksini söylüyordu: 2026-07-17 tarihli bir yoklama doğru ön eki :id
bölümü olmadan kullandı ve rota kaçırmasını bir yokluk olarak okudu. Bu sayfayla aynı geçişte
düzeltildi. Geriye kalan gerçek kısıt daha dardır: yayımlanmış hiçbir liste kimliği bulunabilir
değil, dolayısıyla rota çalışsa bile bir yabancı bir liste çekemez.
Alınacak şey
- Özneye haber verilmiyor. O kısım sağlam.
- Çözümleyici sorguyu öğreniyor. Sizin için önemliyse kendi düğümünüzü çalıştırın.
- İptal kontrolü bir geri çağrıdan az, hiçbir şeyden çok sızdırıyor.
- Hiçbiri denetlenmedi ve incelenmemiş bir mahremiyet özelliği bir tasarım niyetidir.

