SolidusIdentity

Bir Doğrulanabilir Kimlik Bilgisi Vermek: SDK Gerçekte Neyi İmzalıyor

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

İsteğe bağlı bir parametreyi atlayın ve verdiğiniz şey, dosyayı kim tutuyorsa onun kullanabileceği bir hamiline kimlik bilgisidir. Bu bizim nitelememiz değil; kendi yayımlanmış tür tanımlarımızdaki ifadedir.

İmzanın içine ne giriyor

Verilen her kimlik bilgisi şunları taşıyor:

  • iss, verenin tanımlayıcısı.
  • vct, kimlik bilgisi türü, opak bir dizgi olarak.
  • iat, ne zaman verildiği.
  • öznenin iddiaları, her biri tuzlanmış ve özetlenmiş hâlde, böylece sonradan tek tek açığa çıkarılabilsin.

Ve, yalnızca veren isterse:

  • sub, tutucunun tanımlayıcısı.
  • nbf / exp, geçerlilik başlangıcı ve bitişi.
  • cnf: kimlik bilgisinin bağlandığı bir tutucu açık anahtarı.
  • status, bir iptal durum listesine işaretçi.

İmzalama Ed25519 / EdDSA; açıklama özetleme SHA-256 ve kod, başka herhangi bir özet algoritmasını sessizce kabul etmek yerine hata fırlatıyor.

Varsayılan en zayıf yapılandırmadır, dolayısıyla önce onu söyleyin

Veren bir tutucu açık anahtarı geçirmezse, hiçbir tutucu bağlaması yoktur. O parametrenin yayımlanmış belgesi şöyle: "Omit to issue a bearer credential (Phase 1 default)." Ve özne için: "if absent, the SD-JWT is bearer."

Hamiline kimlik bilgisi tam olarak kulağa geldiği şeydir. Dosyayı ele geçiren herkes onu sunabilir. Size verilmiş olması önemli değil; baytların kimde olduğu önemli.

Bunu "esnek" diye tarif etmeyeceğiz. Ulaşılabilir en zayıf yapılandırmadır ve bir parametreyi dışarıda bırakarak elde ettiğiniz şeydir, ki insanların yaptığı da budur. Önemli bir şey veriyorsanız, tutucunun anahtarını geçirin. Geçirdiğinizde kimlik bilgisi bir cnf iddiası taşıyor ve bir doğrulayıcı, sunum anında tutucunun sahipliği kanıtlamasını isteyebiliyor.

"Seçici açıklama"nın burada ne anlama gelip gelmediği

Tutucuya verdiğiniz kimlik bilgisi her iddia değerini içeriyor. Kendi modül belgemiz açık: "Disclosure values stay attached to the compact form; selective revelation is a holder-side concern."

Yani verme, hiçbir şeyin gizlendiği yer değil. Seçicilik sonradan, tutucu bir sunuma hangi açıklamaları dahil edeceğini seçtiğinde oluyor. O zamana kadar dosya eksiksizdir.

Ve düzenek tuzlanmış özetlerdir, bağlanamazlık değil. Aynı kimlik bilgisinin iki sunumu aynı veren imzasını taşıyor, dolayısıyla ikisini de gören bir doğrulayıcı aynı kimlik bilgisinden geldiklerini anlayabiliyor. Bu, bu biçimin bir özelliğidir ve onu gizlemeyeceğiz: uzun sürümü özetin hâlâ neyi açığa çıkardığı sayfasındadır. Burada atıf yapılan BBS+ uygulaması denetlenmemiştir.

İç içe iddialar tuzağı

Varsayılan olarak her üst düzey iddia açıklanabilir ve iç içe olan hiçbir şey değildir. Yayımlanmış ifade: "nested objects are not auto-expanded", ve yorum devamında seçici olarak açıklamak için açık yollar geçirmeniz gerektiğini söylüyor.

Pratikte bu, bir address nesnesinin ya hep ya hiç tek bir birim olduğu anlamına geliyor. Adresi açığa çıkarın ve içindeki her alanı açığa çıkarırsınız: sokak, şehir, posta kodu, oraya ne koyduysanız. Tutucunun yalnızca bir şehri gösterebilmesini istiyorduysanız, bunu verme anında söylemeniz gerekiyordu, açık noktalı yollarla, ve sonradan yeniden vermeden düzeltemiyorsunuz.

Bu, amaçlanandan fazlasını sızdıran bir kimlik bilgisini kazara vermenin en olası yoludur ve verme anında, sessizce, hiçbir hata olmadan oluyor.

İptal isteğe bağlıdır ve bir tuzak daha var

Bir durum listesi referansı yalnızca veren bir tane sağlarsa mevcut. Onu atlayın ve kimlik bilgisinin hiçbir iptal işaretçisi olmuyor, bir doğrulayıcının hiçbir zaman kontrol edeceği bir şey olmuyor.

Ve sağlandığında bile dürüst sınır geçerli: yığınımızdaki durum listesi uç noktası canlı, ama dışarıdan keşfedilebilir yayımlanmış bir liste tanımlayıcısı yok, ve kontrol etmeyen bir doğrulayıcıyı hiçbir şey durdurmuyor.

Tür hiçbir şeye karşı doğrulanmıyor

vct opak bir dizgidir ve uzak tür üstverisi kapalıdır: kod loadTypeMetadataFormat: false ayarlıyor, verenin tür için yetkili olduğunu ve bir üstveri uç noktasının gelecekteki iş olduğunu söyleyen bir yorumla.

Yani bir kimlik bilgisi alan bir doğrulayıcı, türün verenin söylediği anlama geldiğini doğrulayamıyor. Tür, verenin seçtiği bir etikettir. Bu bir ayrıntı değil, gerçek bir birlikte çalışabilirlik sınırıdır.

Bunların hepsini kendiniz kontrol edebilirsiniz

$ mkdir /tmp/check && cd /tmp/check && npm init -y
$ npm i @solidus-network/[email protected]
$ cat node_modules/@solidus-network/sdk/dist/sdjwt/types.d.ts

Temiz dizin, tek depo yok, yerel derleme yok: bir yabancının yapacağı gibi. 2026-07-31'de yapıldı; paket kuruldu ve bu sayfadaki her alıntı o dosyadan çıktı.

Ve kendi yayımlanmış yorumlarımızdaki iki hata

Onu okurken, sunduğumuz şeyde kusurlar bulduk, dolayısıyla onları sessizce düzeltmek yerine burada adlandırıyoruz:

  1. Bir yorum .claude/plans/developer-tools/archieved/2026-05-09-sdjwt-vc-implementation.md dosyasını gösteriyor: yayımlanan pakette olmayan ve hiçbir okurun açamayacağı bir iç dosya. Yalnızca bizim görebildiğimiz bir şeye atıf yapan yayımlanmış bir yorum, pakette bir hatadır.
  2. Bir yorum SD-JWT VC'ye "one of two W3C VC formats" diyor. SD-JWT VC bir IETF taslağıdır. Bir W3C biçimi değildir, ve bu ayrımda bu sitenin başka yerlerinde titiziz, dolayısıyla gevşek sürümü pakette sunmak bizim hatamızdır.

İkisi de yukarıda alıntılanan sürümde hâlâ mevcut.

Okumaya devam edin

Bir Doğrulanabilir Kimlik Bilgisi Vermek: SDK Gerçekte Neyi İmzalıyor · Solidus — Solidus Identity