Tek Tohum, Çok Kimlik: İkili DID'ler Nasıl Çalışır

Burada tarif edilen bağlanamazlık uygulaması denetlenmemiştir.

Çoğu insanın merkeziyetsiz kimliğe taşıdığı varsayımla başlayın: tek bir tohumunuz varsa, ondan türetilen her şeyin size geri izlenmesi gerekir. Böyle çalışmak zorunda değil. Tek bir tohum, her biri farklı bir dayanan tarafla kullanılan ve her biri dışarıdan bakıldığında farklı bir kişiye aitmiş gibi görünen birçok DID türetebilir. Bir hizmete bir tanımlayıcı, bir sonrakine farklı birini gösterin; o iki hizmetin, isteseler bile, karşılaştıracakları hiçbir şey iki tanımlayıcıda da yoktur.

Bu bir ikili DID'dir: bir cüzdanın her seferinde tek bir ilişki için ürettiği bir tanımlayıcı, her yerde yeniden kullanılan tek bir tanımlayıcı değil.

Bu nereden geliyor

Solidus ilişki başına tanımlayıcıları icat etmedi. Örüntü, 2017-2019 civarında Hyperledger Indy/Aries ve Sovrin Foundation topluluğunun ikili takma adlı DID'ler üzerine çalışmasına dayanır; sonradan DIF'in did:peer yöntem şartnamesinde resmileştirildi ve W3C DID Core'un kendisinde bir çekirdek mahremiyet örüntüsü olarak tartışıldı. Solidus bir DIF Associate Üyesidir (yalnızca sözcük dağarcığını ödünç aldığı değil, katıldığı bir kuruluş) ve Solidus'un yazdığı şey kendi türetme şemasıdır: did:peer'ı ya da daha yeni bir takma ad taslağını olduğu gibi benimsemek yerine, bir cüzdanın mevcut tohumu üzerinde doğrulayıcı başına alan ayrımı yapılmış, HKDF tabanlı bir anahtar türetmesi. İlişki başına ayrı bir kimlik saklamak yerine türetme fikri Solidus'tan yıllar öncedir. Tam atıf ve Solidus'un belirli uygulamasının dürüst takasları Lexicon'dadır: İkili DID.

Aynı türetmeyi aynı tohum ve aynı doğrulayıcı adıyla iki kez çalıştırın, birebir aynı tanımlayıcıyı geri alırsınız; saklanacak durum yok, ayrı bir yedekleme süreci yok, çünkü her ikili kimlik yalnızca cüzdanın zaten yedeklediği aynı tohumdan yeniden hesaplanır.

Olumsuz kanıt

Bir ikili DID'nin tanımlayıcı özelliği, zincire hiç demirlenmemesi, hiçbir zaman bir zincir işlemi olarak gönderilmemesi ve kayıtlı bir kimlik çıpasının yazıldığı gibi durum ağacına hiç yazılmamasıdır. Bu bir ihmal değil; bütün mesele budur. Açık ve çözümlenebilir bir sicile yayımlanmış bir ikili tanımlayıcı, orada var olduğu anda kendi amacını ortadan kaldırırdı, çünkü "herkesçe çözümlenebilir" ile "yalnızca tek bir dayanan tarafça bilinen" aynı dizenin taşıyamayacağı çelişkili özelliklerdir.

Bu da demektir ki bir ikili DID'nin gizli kaldığının kanıtı bir başarı durumu olarak ekran görüntüsü alabileceğiniz bir şey değil, bir yokluktur. Hiç demirlenmemiş, sözdizimsel olarak geçerli herhangi bir did:solidus dizesini alın ve açık RPC'ye karşı çözümleyin:

curl -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}

result: null. Bir hata değil, bozuk istek yanıtı değil: zincirin "bu tanımlayıcı benim durum ağacımda var mı" sorusuna dürüst cevabı ve cevap hayır. Bu, DID Çözümlemesinin hiç demirlenmemiş herhangi bir tanımlayıcı için belgelediği davranışın aynısıdır: uydurulmuş bir DID ile gerçekten özel, hiç yayımlanmamış bir ikili DID dışarıdan birebir aynı görünür, çünkü ikisi de zincir açısından yapısal olarak hiçbir şeydir. Bu, çözümleyicinin bir sınırlaması değildir. Mekanizmanın tam olarak tasarlandığı gibi çalışmasıdır: bir ikili DID'nin mahremiyeti, zincirin elinde tuttuğu bir şeyi nezaketen yayımlamamasına bağlı değildir; en baştan onu tutması hiç istenmemiş olmasına bağlıdır. Aynı çağrıyı explorer.solidus.network/lookup üzerinden uydurduğunuz herhangi bir tanımlayıcıyla deneyin, aynı hiçliği geri alırsınız: size daha fazlasını söyleyecek ayrı ve daha nazik bir yol yoktur.

Bu kullanıcıya gerçekte ne kazandırır

Pratik çevirisi: iki hizmet aynı kişi için birer ikili DID tutuyorsa, o iki DID'yi karşılaştırıp aynı kullanıcıya baktıkları sonucuna varamazlar, çünkü en baştan karşılaştıracakları ortak ve açık bir tanımlayıcı yoktur. Her hizmet tekrar ziyaretlerde aynı kişiyi yine tanır, çünkü türetme belirlenimcidir ve o belirli doğrulayıcı için her seferinde aynı tanımlayıcıyı döndürür. Bozulan şey tek hizmette tanınma değil, hizmetler arası ilişkilendirmedir. Ortak bir müşteri hakkında not havuzlamak isteyen iki şirketin, kişinin iş birliğine ya da tamamen bu mekanizmanın dışındaki başka bir ortak veri parçasına ihtiyacı olurdu: ikili DID'nin kendisi onlara karşılaştıracak hiçbir şey vermez.

İkili DID bağlanamazlığı, ilişkiler arasındaki tanımlayıcılarla ilgilidir ve herhangi bir kimlik bilgisi sunulmadan önce türetilir. İkisi bir araya gelir, ama aynı iddia değildirler ve bu sayfa diğerini yapacak yer değil.

Sırada nereye

Bu, bir kimlik çıpasının neden asla değer tutamayacağı ya da gönderemeyeceği sayfasının kardeş durumudur; iki sayfa da tasarım gereği yapısal olarak eksik olan hakkındadır, biri değer için biri ilişkilendirme için. Karşıt durum için, yani null yerine gerçek bir belgeye çözümlenen ve demirlenmiş olan bir DID için bkz. bir DID'yi kendiniz çözümleyin. Birlikte okunduğunda, iki çözümleme sonucu bir aramanın ne zaman bir şey bulduğunun ve ne zaman, bilerek, asla bulmayacağının dürüst haritasıdır.