Bir EUDI Wallet sunumunu (presentation) kabul etmek bir güven kararıdır ve bu karar entegrasyon kodunuzda verilir. Bu makale, cüzdan geliştiren ekiplere değil, cüzdan sunumlarını kabul edecek relying party'lere (güvenen taraf) yani belediyelere ve hizmet sağlayıcılara yöneliktir. Cüzdanı gerçek kullanıcılar için etkinleştirmeden önce yanıtını almak isteyeceğimiz soruları listeler. Tamamlanmış bir tasarım değil, bir gözden geçirme kontrol listesidir.
Hangi spesifikasyona göre geliştirdiğinizi bilin
Teknik temel, Architecture and Reference Framework (ARF) belgesidir. ARF, herkese açık bir GitHub deposunda yayımlanır ve Common Union Toolbox kapsamında geliştirilir. Depoda, geçerli en güncel sürümün etiketlenmiş (tagged) en son sürüm olduğu belirtilir. Bir dal (branch) ya da bir blog özeti bağlayıcı kaynak değildir.
Hukuki dayanak, (AB) 2024/1183 sayılı Tüzük ile değiştirilmiş hâliyle (AB) No 910/2014 sayılı Tüzük ve buna bağlı Komisyon Uygulama Tüzükleridir. ARF, bunların güncel listesine Introduction ve References bölümlerinde yer verir.
Dolayısıyla ilk sorular idari niteliktedir, ancak önemlidir:
- Tedarikçiniz ya da entegratörünüz hangi ARF sürümüne göre geliştirme yaptı?
- Sizin tarafınızda yeni etiketlenmiş sürümleri ve uygulama tüzüklerini kim takip ediyor ve değişiklikler iş listenize (backlog) nasıl ulaşıyor?
- Kimlik sağlayıcıyla yaptığınız sözleşmede belirli bir sürüm geçiyor mu, yoksa yalnızca "eIDAS 2.0 uyumlu" ifadesi mi var?
Beyana (assertion) ilişkin sorular
Cüzdan, hizmetinize bir sunum iletir. Bu sunum bir oturuma dönüşmeden önce neyi doğruladığınızı bilmeniz gerekir.
- Kim düzenledi? Hizmetiniz yalnızca güvenmeye karar verdiğiniz düzenleyicilerden (issuer) ve kabul etmeye karar verdiğiniz nitelik türleri için sunum kabul etmelidir. "Geçerli olan her imza" bir politika değildir. Kabul listesini yazılı hâle getirin, bir sahip belirleyin ve kayıtların nasıl ekleneceğini ve çıkarılacağını tanımlayın.
- Bu işleme bağlı mı? Giriş uç noktanıza karşı yeniden oynatılabilen (replay) bir sunum, çalınmayı bekleyen bir kimlik bilgisidir. Sunumun oturumunuza nasıl bağlandığını tedarikçinizle doğrulayın ve eski bir sunumun reddedildiğini test edin.
- Doğrulama başarısız olduğunda ya da kullanılamadığında ne olur? Güvenli şekilde reddedip reddetmeyeceğinize (fail closed) karar verin. Hata yönetiminin ve yük koşullarının kullanıcıları daha zayıf bir yedek yola yönlendirmediğinden emin olun.
- Neyi logluyorsunuz? Bir olayı araştırmaya yetecek kadar kayıt tutmalısınız, ancak cüzdanın asgari düzeyde tutmak üzere tasarlandığı kişisel verileri saklamamalısınız.
İlk maddeyle ilgili bir not: düzenleyici ve nitelik kabul politikası, bizim önerdiğimiz bir kontroldür. ARF'den alıntılanmış bir gereklilik değildir.
Niteliklere (attribute) ilişkin sorular
Komisyon, cüzdanı kullanıcıların yalnızca yaş ya da uyruk gibi gerekli bilgileri paylaşıp diğer kişisel verilerini açıklamamasına imkân veren bir araç olarak tanımlıyor. Bu, relying party olarak entegrasyonunuzun karşılaması gereken beklentiyi belirler.
Hizmetinizin birinin belirli bir yaşın üzerinde olduğunu bilmesi yeterliyse doğum tarihini değil, bunu isteyin. Belediyenizde ikamet eden birine ihtiyacınız varsa tam adresi değil, bunu kanıtlayan niteliği isteyin. İstediğiniz her ek nitelik, korumanız ve kendi gizlilik değerlendirmenizde gerekçelendirmeniz gereken veriyi artırır.
Ardından niteliğin gerçekte neyi kanıtladığını sorun. Bir kamu düzenleyicisinden gelen nitelik ile özel bir düzenleyiciden gelen nitelik aynı cüzdanda bulunabilir ve kodunuzda birbirine benzeyebilir. Her birini desteklediği karara eşleyin. Bir kütüphane kart numarası, vergi beyanına erişim sağlamamalıdır.
Kabul politikasındaki tek bir satır şöyle görünebilir. Değerler biçimi göstermek için verilmiş bir örnektir, bir öneri değildir:
| Düzenleyici | Nitelik | Relying party kararı | Sahip | Gözden geçirme aralığı |
|---|---|---|---|---|
| Ulusal kimlik düzenleyicisi (örnek) | 18 yaş üzeri | Yaş sınırlı hizmete erişime izin ver; doğum tarihini saklama | Hizmet sahibi | Altı ayda bir |
Bir kayıt için beş sütunun hepsini dolduramıyorsanız, o kayıt listeye girmeye hazır değildir.
Kurumsal kullanım açısından, pilot uygulamalar kurumsal dijital kimlikleri bir kullanım senaryosu olarak test ediyor: yani bir kişinin bir kurumun yetkili temsilcisi olduğunu kanıtlamasını. İşletmelere hizmet veriyorsanız, bir şirket adına hareket eden kişiye nasıl davranacağınıza ve bu kişinin yetkisinin ne zaman sona erdiğini nasıl öğreneceğinize şimdiden karar verin.
İmza akışlarına ilişkin sorular
Sözleşme imzalama pilot senaryolardan biridir. Bu nedenle onu girişten ayrı bir güvence vakası olarak ele alın.
- İmza ya da mühür akışınız hangi hizmetlere bağımlı ve bunları kim işletiyor?
- İmzanın kanıtı olarak neyi, ne kadar süreyle saklıyorsunuz?
- Bir imza iki yıl sonra itiraza uğrarsa, o sırada neyin sunulduğunu ve doğrulandığını gösterebilir misiniz?
Başarılı bir girişin geçerli bir imza zincirini de garanti ettiğini varsaymayın. Bunlar ayrı kontrollerdir ve farklı hata modlarına sahiptir. Hukuk ve güvenlik ekipleriniz, ilk sözleşme imzalanmadan önce kabul edilebilir kanıtın ne olduğu konusunda uzlaşmalıdır.
Entegrasyonu test edin, sonra yeniden test edin
Komisyonun prototip cüzdanı kod kütüphaneleri ve bir örnek uygulama içerir, referans uygulama ise açık kaynaktır. ARF deposu bir uyumluluk (conformance) web sitesine bağlantı verir. Bunları test için kullanın, gözden geçirmediğiniz bir üretim bağımlılığı olarak değil.
Büyük ölçekli pilotlara 26 Üye Devlet, Norveç, İzlanda ve Ukrayna'dan 350'den fazla kuruluş katılıyor ve kamu hizmetleri, bankacılık ve ödemeler gibi alanları kapsıyor. Yine de kendi uç noktalarınızın, yedek yollarınızın ve oturum yönetiminizin ayrıca test edilmesi gerekir.
Entegrasyonu yeni bir kimlik doğrulama kodu olarak ele alın. Bu, bir tehdit modeli, yeniden oynatma, hatalı biçimlendirilmiş sunumlar ve beklenmeyen düzenleyicilere karşı kötüye kullanım senaryosu testleri ve canlıya almadan önce tamamlanmış akışın sızma testi anlamına gelir. Cüzdan tedarikçisi neyi test etmiş olursa olsun, relying-party hizmetinizin kendi gözden geçirmesine ihtiyacı vardır.
Nereden başlamalı
- Hedefinizi sabitleyin: entegrasyonunuzun dayandığı ARF sürümünü ve uygulama tüzüklerini kaydedin, değişiklikleri izlemesi için birini görevlendirin.
- Bir kabul politikası yazın: güveneceğiniz düzenleyicileri ve nitelik türlerini, her birinin desteklediği kararı, sahibini ve gözden geçirme aralığını listeleyin.
- Nitelik taleplerinizi her hizmetin ihtiyaç duyduğu asgari düzeye indirin ve sonucu kendi gizlilik değerlendirmenize kaydedin.
- Referans uygulama ve uyumluluk kaynakları üzerine bir test planı oluşturun; yeniden oynatma, yanlış düzenleyici, hata modu ve yedek yol senaryolarını dâhil edin.
- Girişi imzalamadan ayırın: her biri için hangi kanıtı sakladığınıza ve bunu kimin onayladığına karar verin.
- Canlıya almadan önce bağımsız bir gözden geçirme yaptırın. Kapsamını belirlemek için destek isterseniz danışmanlık ekibimizle görüşün.
