Seçici açıklama düzenekleri: iki düzenek, iki farklı güvence, biri denetlenmemiş

BBS+ gerçekleştirimimiz DENETLENMEMİŞTİR.

Bu sayfanın yapmak için var olduğu ayrım

Seçici açıklama ve bağlantılandırılamazlık aynı özellik değildir, ve neredeyse her açıklayıcı metin onlara tek bir şeymiş gibi davranıyor. Birleştirme, bizimki dâhil satıcıların işine geliyor, o yüzden işte ayrılmış hâlleri:

• Seçici açıklama, bir kimlik bilgisinden bazı alanları açıklayıp geri kalanını saklıyorsunuz. Doğrulayıcı, adresinizi öğrenmeden doğum tarihinizi öğreniyor.
• Bağlantılandırılamazlık: aynı kimlik bilgisinin iki farklı doğrulayıcıya yapılan iki sunumu, o doğrulayıcılar gizlice anlaşıp notlarını karşılaştırsa bile birbiriyle ilişkilendirilemiyor.

Birincisi ikincisini gerektirmiyor. Tek bir alanı açıklayıp yine de kimlik bilgisinin kendisini tanımlayan bir şey verebilirsiniz, ki bu, öyle olmasını istemiş olun ya da olmayın, bir ilişkilendirme tutamağıdır.

Birinci düzenek: SD-JWT VC, sunulmuş, ve dürüstçe sınırlanmış

Canlı olan yol budur. Verenimiz onu standart üstveride duyuruyor, ve bunu kendiniz denetleyebilirsiniz:

$ curl -s https://capture-api.solidus.network/.well-known/openid-credential-issuer
  format : vc+sd-jwt

HTTP 200, 2026-07-31'de denetlendi. Uyumlu herhangi bir SD-JWT VC doğrulayıcısının okuyabileceği bir biçim.

Size ne verdiği: hakiki seçici açıklama. Alanlar tek tek açıklanabilirdir; sakladıklarınız açığa vurulmuyor.

Tasarım gereği size ne vermediği: bağlantılandırılamazlık. Açıklanmayan alanların özetleri her sunumla birlikte yine de seyahat ediyor. Bir kimlik bilgisi tek kullanımlık değilse, o özetler ilkesel olarak, gizlice anlaşan doğrulayıcılar için bir ilişkilendirme tutamağıdır.

Bu, gerçekleştirimimizdeki bir kusur değil, düzeneğin bir özelliğidir: her yerde SD-JWT için doğrudur. Bunu söylüyoruz, çünkü "seçici açıklama"nın "izlenemez" demek olduğunu varsayan bir okur yanılırdı, ve bizim lehimize yanılırdı.

Bu konuda ne yaptığımız, ve sınırı: bir kimlik bilgisini anahtara bağlı bir kanıtla tutanına bağlıyoruz, böylece çalınmış bir kimlik bilgisi başkası tarafından sunulamıyor. Bu, kimin sunabileceğini denetliyor. Sunumların bağlanabilir olup olmadığını denetlemiyor. Bağlantılandırılamazlıktan daha dar bir güvencedir ve ikisinin karıştırılmasına izin vermeyeceğiz.

İkinci düzenek: BBS+, bağlantılandırılamaz yol, ve denetlenmemiş olan

Bağlantılandırılamazlık özellikle BBS+ yolunu gerektiriyor. Her seferinde aynı imzayı yeniden göstermek yerine, tutan sunum başına taze bir sıfır bilgi kanıtı türetiyor, böylece iki sunum, gizlice anlaşan bir doğrulayıcı çiftinin eşleştirebileceği hiçbir şeyi paylaşmıyor.

Tasarımın niyeti budur. Kodumuzun doğrulanmış bir güvenlik özelliği değildir, çünkü gerçekleştirimimiz denetlenmedi.

Gösterimi kamuya açık kütükten kendiniz çalıştırabilirsiniz:

$ npm i @solidus-network/auth @solidus-network/bbs        # 0.6.3, checked 2026-07-31
$ node node_modules/@solidus-network/auth/demo/unlinkability-demo.mjs

Gösterim yayımlanmış tarball'ın içinde geliyor; bunu kendi depomuza güvenmek yerine tarball'ı kütükten getirerek doğruladık, ve kendi bastığı çıktı sınırı ifade ediyor: external audit pending (NLnet NGI Zero, H2 2026 target).

Kendi bitmemiş denetimini duyuran bir gösterim, bunun için doğru biçimdir. Argüman iyidir; doğrulanmamış olan şey fikrin biçimi değil, gerçekleştirimimizdir.

Aralarında nasıl seçim yapılacağı

• Bir doğrulayıcıdan alan saklamanız mı gerekiyor? SD-JWT VC bunu bugün yapıyor, ve canlı yol odur.
• Farklı doğrulayıcılara yapılan sunumların ilişkilendirilemez olması mı gerekiyor? Bu BBS+ gerektiriyor, ve denetlenmemiş kriptografik koda bel bağlıyor olurdunuz. Gerçek sonuçları olan herhangi bir şey için bu, dikkatle ilerlemek için bir sebep değil, denetimi beklemek için bir sebeptir.

O cümlenin sonradan keşfedilmesindense anlaşmayı kaybetmeyi tercih ederiz.

Bilmeye değer diğer sınırlar

• SDK yalnızca TypeScript'tir. Diğer dil bağlamaları yol haritasındadır, sunulmuş değil.
• Verenin bugün duyurduğu tek bir kimlik bilgisi yapılandırması var.