Passport Credential ve Dijital Cüzdan: Issuer–Holder–Verifier Mimarisi

Digital Travel Architecture — Bölüm 2

Serinin ilk bölümünde ePassport çipinden okunan verinin Passive Authentication ile doğrulanmasını ve normalize edilmesini ele aldık. İkinci adım, doğrulanmış bu veriyi bir dijital cüzdana taşınabilecek, gerektiğinde havayolu veya havalimanı tarafından doğrulanabilecek bir Passport Credential'a dönüştürmektir.

Referans aldığımız FastAPI prototipi bu akışı JWT, MongoDB tabanlı wallet ve basit bir presentation endpointiyle görünür hale getiriyor. Bu yapı mimari rolleri anlamak için iyi bir başlangıçtır; fakat “imzalı JWT”, “Verifiable Credential” ve “selective disclosure” kavramları aynı şey değildir. Bu yazıda çalışan demo ile üretim düzeyindeki Issuer–Holder–Verifier modelinin sınırlarını açıkça ayıracağız.

1. Üç rol, üç ayrı güven sorumluluğu

Passport Issuer
    │  doğrulanmış pasaport claim'lerini imzalar
    ▼
Holder / Digital Wallet
    │  credential'ı saklar ve sunum için kullanıcı onayı alır
    ▼
Verifier
    │  imza + durum + holder binding + kullanım politikasını doğrular
    ▼
Airline / Airport işlemi

Issuer, credential içindeki iddiaların kaynağıdır. Digital Travel senaryosunda bu rolü doğrudan devlet otoritesi, yetkilendirilmiş bir dijital kimlik hizmeti veya güvenilir bir türetme servisi üstlenebilir. Issuer'ın imzası yalnızca verinin sonradan değişmediğini değil, belirli claim'lerin belirli bir otorite tarafından ifade edildiğini gösterir.

Holder, credential'ı bulunduran ve verifier'a presentation oluşturan taraftır. Holder çoğu senaryoda yolcudur; ancak holder ile credential subject'in her zaman aynı olmak zorunda olmadığı da unutulmamalıdır.

Verifier, credential'ı alan havayolu, havalimanı, sınır kontrol sistemi veya başka bir yetkili servistir. W3C modelinde kriptografik doğrulamanın başarılı olması, claim'lerin belirli bir işlem için otomatik olarak yeterli olduğu anlamına gelmez. Verifier ayrıca issuer güvenini, geçerlilik zamanını, credential durumunu ve kendi iş politikasını değerlendirir.

2. Demo credential nasıl üretiliyor?

Prototipte ortak bir payload oluşturucu iss, sub, iat, exp, vc_type ve claims alanlarını hazırlıyor. Ardından PyJWT ile HS256 imzası üretiliyor:

def build_payload(subject_id, vc_type, claims, ttl):
    now = int(time.time())
    return {
        "iss": "did:example:issuer",
        "sub": subject_id,
        "iat": now,
        "exp": now + ttl,
        "vc_type": vc_type,
        "claims": claims,
    }

token = jwt.encode(payload, shared_secret, algorithm="HS256")

Bu yaklaşımın güçlü yanı sadeliğidir. Token kompakt biçimde taşınabilir, süre kontrolü standart JWT kütüphaneleriyle yapılabilir ve prototip boyunca Passport, Loyalty ve Order credential'ları aynı mekanizmayla üretilebilir.

Ancak bu nesne W3C Verifiable Credentials Data Model 2.0'ın tam bir uygulaması değildir. W3C modeli issuer, credential subject, type, validity, status ve securing mechanism gibi kavramları tanımlar; kullanılacak credential formatı ve değişim protokolü ayrıca seçilmelidir. Bu nedenle prototipteki yapıyı “JWT tabanlı demo credential” olarak adlandırmak daha doğrudur.

3. Neden HS256 üretim için doğru güven modeli değil?

HS256 simetrik bir algoritmadır: token'ı imzalayan taraf ile doğrulayan taraf aynı gizli anahtarı bilir. Bir havayoluna doğrulama yetkisi vermek için bu anahtar paylaşıldığında, aynı havayolu teorik olarak yeni credential da üretebilir. Issuer ile verifier arasındaki yetki ayrımı kaybolur.

Üretim mimarisinde issuer özel anahtarla imzalar, verifier ise yalnızca açık anahtarı kullanır:

{
  "alg": "ES256",
  "kid": "https://issuer.example/keys/2026-07"
}

kid, doğrulayıcının doğru açık anahtarı bulmasına yardımcı olur. Özel anahtar HSM veya uygun bir anahtar yönetim hizmetinde tutulmalı; anahtar rotasyonu, algoritma politikası, denetim kaydı ve acil iptal prosedürü tasarımın parçası olmalıdır. Issuer kimliği yalnızca payload içindeki bir string'e güvenilerek kabul edilmemeli, güvenilir metadata ve anahtar materyaliyle bağlanmalıdır.

4. Cüzdana eklemek ile holder binding aynı şey değildir

Demo frontend önce Passport JWT'yi üretiyor, sonra ayrı bir çağrıyla /wallet/{user_id}/add endpointine ekliyor. Backend token imzasını doğruluyor ve MongoDB'de şu mantıksal yapıyı saklıyor:

{
    "user_id": user_id,
    "vc_type": "passport",
    "vc_jwt": token,
    "description": "Passport VC"
}

Token'ın bir kullanıcı koleksiyonuna yazılması, o kullanıcının credential'ın meşru sahibi olduğunu kriptografik olarak kanıtlamaz. Endpointlerde authentication ve authorization yoksa başka bir kişinin wallet kaydına token eklemek veya wallet içeriğini listelemek de mümkün olabilir.

Cryptographic holder binding, credential'ı holder'ın kontrol ettiği anahtara bağlar. Wallet issuance sırasında bir anahtar çifti oluşturur veya güvenli cihaz anahtarını kullanır; issuer, credential'ı bu açık anahtarla ilişkilendirir. Presentation sırasında wallet private key kontrolünü kanıtlar. Böylece yalnızca token dosyasını kopyalamak credential'ı kullanmaya yetmez.

OpenID4VCI gibi issuance protokolleri; yetkilendirme, credential endpointi, issuer metadata ve proof-of-possession adımlarını standartlaştırmak için kullanılabilir. Güvenli cihaz, anahtar yedekleme ve cihaz değişimi politikaları ise ayrıca tasarlanmalıdır.

5. Demo “presentation” endpointi ne yapıyor?

Wallet router'ındaki present endpointi istenen credential tipini buluyor, JWT'yi doğruluyor ve required_claims listesindeki alanları seçerek JSON döndürüyor:

claims = payload.get("claims", {})

if request.required_claims:
    claims = {
        key: value
        for key, value in claims.items()
        if key in request.required_claims
    }

return {
    "vc_type": request.vc_type,
    "subject_id": payload["sub"],
    "claims": claims,
    "issuer": payload["iss"],
}

Bu, veri minimizasyonu fikrini göstermek açısından yararlıdır; fakat kriptografik selective disclosure değildir. Sunucu orijinal imzalı token'ı açıp yeni bir imzasız JSON nesnesi üretmektedir. Verifier bu alanların gerçekten issuer tarafından imzalandığını bağımsız olarak kanıtlayamaz; wallet servisine güvenmek zorunda kalır.

SD-JWT VC yaklaşımında issuer, seçilebilir claim'leri hash tabanlı disclosure yapılarıyla credential'a bağlar. Holder yalnızca gerekli disclosure'ları sunar; verifier açıklanan claim'lerin issuer imzasıyla bağlı olduğunu doğrular. SD-JWT VC hâlen IETF Internet-Draft sürecindedir; kullanılacak sürüm ve uyumluluk profili proje kapsamında sabitlenmelidir.

6. Presentation replay saldırısına nasıl bağlanır?

Bir Passport Credential veya presentation ele geçirilip başka bir işlemde tekrar oynatılmamalıdır. Güvenli presentation akışında verifier, işlem bağlamına özel bir nonce ve kendi kimliğini gönderir. Wallet sunumu bu değerlere bağlar:

Verifier → Wallet:
  client_id, nonce, istenen credential ve claim'ler

Wallet → Verifier:
  seçilmiş disclosure'lar,
  holder key proof,
  client_id + nonce'a bağlı presentation

OpenID4VP 1.0, presentation'ın verifier client_id ve nonce değerlerine bağlanmasını zorunlu kılar. Böylece bir check-in oturumu için üretilen cevap farklı bir havayolunda veya daha sonra yeniden kullanılamaz. Ayrıca kullanıcıya hangi verifier'ın hangi claim'leri istediği açıkça gösterilmelidir.

7. Credential verification ile seyahat kararı aynı değildir

Verifier aşağıdaki kontrolleri ayrı ayrı yürütmelidir:

1. Credential biçimi ve şeması beklenen profile uygun mu?
2. Issuer imzası güvenilen anahtarla doğrulanıyor mu?
3. Credential henüz geçerli mi ve süresi dolmuş mu?
4. Credential iptal edilmiş veya askıya alınmış mı?
5. Presentation nonce ve verifier kimliğine bağlı mı?
6. Holder, credential'a bağlı anahtarın kontrolünü kanıtlıyor mu?
7. Açıklanan claim'ler bu işlem için yeterli ve gerekli mi?
8. Travel Rules ve havayolu politikası seyahate izin veriyor mu?

İlk altı madde ağırlıklı olarak credential'ın özgünlüğü ve sunum güvenliğiyle ilgilidir. Son iki madde ise iş kararıdır. “İmza geçerli” sonucu hiçbir zaman tek başına “yolcu uçabilir” anlamına gelmemelidir.

8. Credential status ve mahremiyet

Pasaport kaybolabilir, iptal edilebilir veya credential yanlış cüzdana bağlanmış olabilir. Sadece exp kontrolü bu durumları çözmez. Credential status mekanizması iptal ve askıya alma durumlarını ifade edebilmelidir.

Ancak status kontrolü mahremiyet riski de doğurur. Verifier her sunumda issuer'a belirli bir credential için soru sorarsa issuer yolcunun nerede ve ne zaman işlem yaptığını izleyebilir. W3C VC Data Model 2.0, status mekanizmasının bireylerin kullanımını takip etmeye imkân vermemesi gerektiğini özellikle vurgular. Bitstring tabanlı toplu durum listeleri gibi mahremiyet koruyucu yöntemler bu nedenle önemlidir.

9. Referans prototip için güvenli evrim planı

• Passport Credential claim'lerini kullanıcı formundan değil doğrulanmış chip session'dan üretmek.
• HS256 yerine asimetrik issuer anahtarları, kid ve güvenilir metadata kullanmak.
• Wallet endpointlerine güçlü authentication, authorization ve tenant izolasyonu eklemek.
• Credential'ı wallet'ın cihaz anahtarına cryptographic holder binding ile bağlamak.
• Basit claim filtreleme yerine seçilen profile uygun SD-JWT VC veya başka bir selective disclosure formatı kullanmak.
• Presentation akışına verifier kimliği, nonce, audience ve replay cache eklemek.
• Mahremiyet koruyucu credential status ve anahtar rotasyonu süreçleri oluşturmak.
• Passport, Loyalty ve Order credential'ları için ayrı şema, issuer politikası ve yaşam döngüsü belirlemek.

Sonuç

Referans uygulama Issuer–Holder–Verifier zincirini görünür hale getiriyor: backend credential üretiyor, wallet saklıyor ve verifier için seçilmiş claim'ler sunuluyor. Üretim güvenliği için ise dört ek bağ zorunludur: credential'ın doğrulanmış pasaport oturumuna bağlanması, credential'ın holder anahtarına bağlanması, presentation'ın verifier ve nonce'a bağlanması, verifier kararının güncel travel rules politikasına bağlanması.

Serinin üçüncü bölümünde Loyalty Credential'ın uçuş tekliflerini nasıl etkilediğini ve Order Credential üretimini inceleyeceğiz. Özellikle fiyatın istemciden güvenilir veri gibi alınmasının neden riskli olduğunu ve offer–order bütünlüğünün nasıl kurulacağını göstereceğiz.

Resmî kaynaklar

• W3C Verifiable Credentials Data Model 2.0
• W3C Verifiable Credentials Overview
• OpenID for Verifiable Presentations 1.0
• OpenID for Verifiable Credential Issuance
• IETF OAuth WG — SD-JWT VC Internet-Draft