Skip to content
ADR-0006Mimari karar kaydıKabul edildisürüm 1.0.02 Ekim 2026

ADR-0006 — Belge Formatı ve Protokoller ​

Durum: Accepted Tarih: 2026-09-03 Karar veren: Tamga Network proje yönetimi Kaynak: tamga-guven-cercevesi-v0.1.md (Bölüm F, G, K) — çalışma notu; tam spesifikasyon → SPEC-CRED-0001.


Bağlam ​

Depoda belge (credential)Belge verenin imzaladığı ve kişinin cüzdanında duran dijital belge; kişi yalnız istenen alanları gösterir. formatı bugüne dek "planlı" bırakılmıştı; SPEC-BC-0001 SD-JWT VC (Selective Disclosure JWT Verifiable Credential)Selective disclosure destekli JSON tabanlı belge biçimi; EUDI Wallet'ta ve Tamga'da çevrimiçi gösterme için kullanılır. ve Token Status List'e atıfta bulunuyor ama resmî bir format kararı yoktu. Ayrıca "üniversite fikrindeki gizli hata" (belge başkasının cüzdanına alınabilir) bir güvenlik açığı olarak açıktı. Bu ADR ikisini de kapatır. ADR-0001 (Besu/EVM) ve ADR-0004 (X.509 belge veren (issuer)Belgeyi imzalayıp veren kurum: üniversite, meslek kuruluşu, kamu kurumu ya da şirket. kimliği) üzerine kurulur.


Karar ​

Karar 1 — Format: SD-JWT VC (birincil), mdoc (ikincil, 2. faz) ​

SD-JWT VC birincil formattır: selective disclosureBir belgeden yalnız doğrulayıcının istediği alanların gösterilmesi, fazlasının değil. yerleşik, EUDI ARF (Architecture and Reference Framework)Rolleri, mimariyi, güven modelini ve kuralları anlatan belge seti. Tamga ARF, AB ARF'sinin düzenini izler. ana formatı, kütüphane bolluğu, JSON-LD'den basit. mdocISO/IEC 18013-5 mobil belge biçimi, CBOR ile kodlanır; yüz yüze gösterme ve mobil ehliyet için kullanılır./ISO 18013-5 ikincildir (2. faz; çevrimdışı/ fiziksel ibraz, mDL (mobile Driving Licence)Cüzdanda mdoc biçiminde (ISO/IEC 18013-5) tutulan sürücü belgesi. uyumu).

Karar 2 — Protokoller: OpenID4VCI (ihraç), OpenID4VP (sunum) ​

Fiili standartlar (OpenID4VCI (OpenID for Verifiable Credential Issuance)Belge verenin belgeyi cüzdana teslim ettiği protokol., OpenID4VP (OpenID for Verifiable Presentations)Doğrulayıcının cüzdandan belge istediği ve gösterimi aldığı protokol.); kurumların mevcut OIDC altyapısına oturur, doğrulayıcı (verifier)Gösterilen belgeyi denetleyen taraf: imza, belge verenin güven listesindeki kaydı, durum ve politika. Relying party diye de anılır. entegrasyonu kolay.

Karar 3 — İmza: ES256 (P-256) ​

Mobil secure element (Secure Enclave/StrongBox) ve HSM'lerde evrensel destek.

Karar 4 — Holder binding istisnasız zorunlu (cnf + cihaz anahtarı) ​

Her belge, belge verme (issuance)Belge verenin belgeyi kişinin cüzdanına teslim etmesi (Tamga'da OpenID4VCI ile). anında belge sahibinin (holder)Belgeyi cüzdanında tutan ve kime göstereceğine karar veren kişi. cihazda üretilmiş anahtarına cnf ile bağlanır; sunumda belge sahibi nonce'uBir kez kullanılan rastgele değer; doğrulayıcı gönderir, cüzdan imzalar, böylece eski bir gösterme yeniden kullanılamaz. o anahtarla imzalar (KB-JWT (Key Binding JWT)Cüzdanın gösterme anında belge anahtarıyla imzaladığı kısa belirteç; anahtarın belge sahibinde olduğunu kanıtlar.). Bu, holder bindingBelgeyi yalnız belge sahibinin cihazındaki bir anahtara bağlamak; kopyalanan belge gösterilemez. açığının tek çözümüdür ve kapatılamaz. Anahtar donanımda üretilir, dışa aktarılamaz → belge devredilemez.

Karar 5 — Wallet Unit Attestation (WUA) baştan konur ​

Cüzdanın gerçekliğini (donanım anahtarı, PIN aktif, root/jailbreak yok, sağlayıcı kimliği) beyan eden WUA (Wallet Unit Attestation)Cüzdan sağlayıcısının bir cüzdan birimi ve anahtarlarının güvenliği hakkındaki attestation'ı; güncel AB metinlerinde WIA ve key attestation olarak ikiye ayrılır., pilotta basit içerikle de olsa alan ve akış olarak baştan açılır — sonradan eklemek tüm cüzdanların migrasyonunu gerektirir.

Karar 6 — İptal, Token Status List'e devredilir ​

Ayrı bir iptal (revocation)Bir belgenin süresi dolmadan geçersiz kılınması; belge veren bunu doğrulayıcıların denetlediği iptal listesinde işaretler. mekanizması tanımlanmaz; SPEC-BC-0001 §5 Token Status List kullanılır (off-chain liste + on-chain pointer, min 100k, rastgele index). Korelasyon karşıtı batch belge verme 2. faza ertelenir, formatta yeri açık tutulur.


Gerekçe ​

  • EUDI uyumu: SD-JWT VC + OpenID4VCI/VP + ES256, EUDI ARF'nin ana yığınıdır → "uyumlu ama bağımsız" (PM-PH-0001) ve sınır-ötesi interop.
  • Holder binding = varlık nedeni: bu açık kapatılmazsa sistem sessizce yalan söyler; değeri sıfırlanır.
  • Geri döndürülemezlik: format/binding/WUA baştan doğru kurulmazsa sonradan tüm cüzdan tabanının migrasyonu gerekir — ADR-0003 "bugün bedava, sonra imkânsız" mantığıyla aynı.

Sonuçlar ​

  1. SPEC-CRED-0001 tam spesifikasyondur (format yapısı, KB-JWT, WUA, akışlar).
  2. contracts/ ve sdk/ cüzdanı cihaz secure element anahtarı + cnf üretir; yazılım anahtarı kabul edilmez.
  3. Doğrulayıcı kütüphanesi TrustedListProvider arayüzü üzerinden çalışır (chain-agnostic, Faz 0 dosya / Faz 1 zincir) — ARCH-0001.
  4. PM-ASSUR-0001 belge sahibinin güvence seviyesi, WUA + binding yöntemine bağlanır.

İlişkiler ​

  • SPEC-CRED-0001 — bu kararın tam spesifikasyonu.
  • PM-ASSUR-0001 / ADR-0005 — assurance seviyeleri (formatın taşıdığı güven).
  • SPEC-BC-0001 — issuer registry + Token Status List (iptal).
  • SPEC-ID-0002 — belge veren X.509 (iss), SPEC-ID-0001 — belge sahibinin takma adı (pseudonym)Cüzdanın her web sitesi için ayrı türettiği kararlı hesap kimliği; iki site aynı kişiyi eşleştiremez. (cnf).
  • PM-TRUST-0001 — belge asla zincirde değil.

Format, protokoller, imza, holder binding (zorunlu) ve WUA kabul edildi (2026-09-03). mdoc ve batch belge verme sonraki fazlara havale edildi.