FastAPI prototipindeki JWT üretimi, MongoDB wallet ve claim presentation akışını inceliyor; gerçek Verifiable Credential mimarisi için asimetrik imza, holder binding, selective disclosure, replay koruması ve credential status gereksinimlerini açıklıyoruz.
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.
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şlemiIssuer, 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.
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.
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.
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.
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.
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ı presentationOpenID4VP 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.
Verifier aşağıdaki kontrolleri ayrı ayrı yürütmelidir:
İ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.
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.
kid ve güvenilir metadata kullanmak.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.
Üretim sistemlerinde güncel sürümleri ve kurumunuzun onaylı politikalarını esas alın.
Bu makaleyi nasıl değerlendirirsin?
Geri bildirimin sonraki içerikleri geliştirmeme yardımcı olur.
DİJİTAL KİMLİK VE CÜZDANLAR
Registra'nın kimlik kartı ve pasaport çipinden doğrulanmış veriyi web'de hazırlanan şablonlarla birleştirip PDF'i telefonda üretme akışını; biyometrik giriş, ekranlar, kullanım senaryoları ve teknik sınırlarıyla inceliyoruz.
DİJİTAL KİMLİK VE CÜZDANLAR
22 test, canlı SoftHSM doğrulaması, kurum izolasyonu ve kalıcı şablon kayıtlarından hareketle mevcut demoyu değerlendiriyor; donanımsal HSM ve standartlara geçişte kalan işleri açıklıyoruz.
DİJİTAL KİMLİK VE CÜZDANLAR
İki QR, kurum ve oturuma bağlı eşleştirme, Secure Enclave cihaz imzası, şablon sürümü sabitleme ve SoftHSM ile imzalanan paylaşım sonucunu adım adım inceliyoruz.