Bağlı Veri İmzaları: Kimlik Bilginizin Arkasındaki İspat Biçimi

Kimlik bilginizin arkasındaki ispat biçimi değildir ve bu sayfanın yapabileceği ilk dürüst şey bunu söylemektir. Yukarıdaki başlık içerik planımızdan geliyor; adlandırdığı biçim, yayımlanmış tür tanımlarımızda görünüyor ve gerçekte verdiğimiz kimlik bilgilerinin hiçbirinde yok. Terim spec durumundadır.

Bir Bağlı Veri İmzası nedir

JSON-LD belgeleri için, güncel W3C Veri Bütünlüğü çalışmasından önce gelen soydan bir ispat biçimleri ailesi. Ayırt edici fikir kanonikleştirmedir: imzalamadan önce belge belirlenimci bir biçime dönüştürülür, böylece aynı anlama gelen iki JSON belgesi, farklı anahtar sırasıyla, farklı bağlam açılımıyla, aynı baytları ve dolayısıyla aynı imzayı üretir.

Bu gerçekten güçlüdür. Bir imzanın yeniden serileştirmeyi atlattığı ve bir doğrulayıcının verenin imzaladığı tam bayt dizisini almak zorunda olmadığı anlamına gelir.

Karmaşıklığın yaşadığı yer de burasıdır. Bir çizgeyi kanonikleştirmek bir dizgiyi özetlemekten çok daha fazla iştir ve sonucun güvenliği, kanonikleştirmenin doğru olmasına bağlıdır.

Bu soydan takım adları Ed25519Signature2020 gibi görünür.

Yayımlanmış türümüzün içerdikleri

export interface CredentialProof {
  type: 'Ed25519Signature2020'
  created: string
  verificationMethod: string
  proofPurpose: 'assertionMethod'
  proofValue: string
}

Bu tam olarak bir Bağlı Veri İmzası ispat bloğudur: takım adı, oluşturma zamanı, karşısında doğrulanacak anahtar, amaç ve imza değeri.

Yani belgelenmiş kimlik bilgisi ispat biçimimiz bu soya aittir, kripto takımı adlandırmalı daha yeni ardılına değil. O ayrımın neden önemli olduğu için bkz. kripto takımı alanı ve altındaki alan için bkz. proofPurpose.

Ve çalışan verenin ürettiği: hiçbiri

Canlı hat biçimi JOSE/SD-JWT'dir. Veren vc+sd-jwt ilan ediyor ve bir JOSE algoritma tanımlayıcısıyla imzalıyor. Bugün kimlik bilgisi veren yolda hiçbir kanonikleştirme adımı, hiçbir proof nesnesi, hiçbir proofValue ve hiçbir JSON-LD işleme yok.

Bu biçim, yayımlanmış tür tanımlarımızda var ve canlı hat biçiminde hiçbir yerde yok. Bunu bir tür tanımının aksini ima etmesine izin vermek yerine açıkça söylüyoruz: yayımlanmış bir arayüz bir belgedir ve biri onu haklı olarak alacağı şeyin tarifi diye okuyacaktır.

Boşluğun neden var olduğu, süslemeden

Avrupa cüzdan mimarisi tarafından iki kimlik bilgisi ailesi kabul ediliyor: SD-JWT VC ve ISO mDoc. Biz birincisini uyguluyoruz. İkisi de JSON-LD Veri Bütünlüğü değil.

Tür, sevk edilen yoldan önce geliyor. Hat biçimi seçildiğinde güncellenmedi ve açıklamanın tamamı budur; devam eden bir geçiş değil, ikili biçim stratejisi değil. Bayat bir tür bir belgeleme kusurudur ve bu sayfa, onu açıkladığımız yer değil bunu söylediğimiz yerdir.

Bir araştırmacının kaydetmesi gerekenler

• Solidus Bağlı Veri İmzaları uygulamıyor. Kanonikleştirme yok, Veri Bütünlüğü ispatı üretimi yok.
• Yayımlanmış türümüz yine de bir tanesini tarif ediyor, 2022 öncesi adlandırma soyunda.
• Bizi tür üzerinden değil hat biçimi üzerinden puanlayın. Aldığınız kimlik bilgisi bir SD-JWT'dir.
• Buradaki seçici açıklama tuzlanmış özet temellidir, JSON-LD türevi değil; bkz. açıklanan her alan neden kendi tuzunu taşır.

Biçimin kendisi için söylenmeye değer tek şey

Kanonikleştirme, bizim sahip olmadığımız gerçek bir problemi çözüyor. Kimlik bilgilerimiz, tam baytları doğrulanan şey olan sıkıştırılmış jetonlar olarak seyahat ediyor, dolayısıyla yeniden serileştirmeyi atlatmak bizim yolumuzda bir gereklilik değil.

Bu, seçimin savunulabilir olmasının bir sebebidir. Tür tanımının hattan farklı bir şey söylemesinin sebebi değildir ve onu öyle kullanmayacağız.