Dijital Kimlik ve Kimlik Bilgileri SSS

S: Yeni bir iş ortağının güvenen taraf (RP) olarak hizmete alınması için adım adım süreç nedir?

Y: Accepting IDs from Wallet Online (Cüzdan'daki kimlikleri online olarak kabul etme) başlıklı makaledeki adımları inceleyin.

S: RP'nin ilk katılım süreci genellikle ne kadar sürer?

Y: Genellikle ilk katılım 3-5 iş günü sürer.

S: Gönderdikten sonra, Relying Party (RP) uygulamamızın durumunu nasıl takip edebiliriz?

Y: 5 gün sonra yanıt almazsanız lütfen wallet-identity-rp-support@google.com adresinden destek ekibimizle iletişime geçin.

S: RP onboarding formunu ve resmi geliştirici belgelerini nerede bulabiliriz?

C:

• İlk katılım formu: Google Cüzdan Kimliği Güvenen Taraf İş Ortağı İletişim Formu
• Geliştirici belgeleri: Dijital Kimliğe Genel Bakış

S: Sağladığımız bilgiler (ör. ürün adı ve logosu) ürün deneyiminde nasıl kullanılacak?

Ürün adı ve logosu, kullanıcılara yönelik kullanıcı rızası ekranında gösterilerek kullanıcıların hangi güvenen tarafın dijital kimliklerini istediğini belirlemelerine yardımcı olur. URL'ler ve politika bağlantıları da ürün deneyiminde yer alabilir.

S: Yalnızca geliştirme ve test için korumalı alan ortamını kullanmayı planlıyorsak Hizmet Şartları'nı imzalamamız gerekir mi?

Y: Hayır, Hizmet Şartları'nı kabul etmek test için gerekli bir adım değildir.

S: Başlamak için referans uygulama, örnek kod veya demo uygulamayı nerede bulabiliriz?

C:

• GitHub deposu: Identity Reference Implementation.
• Test web sitesi: verifier.multipaz.org

S: Doğrulayıcı kayıt operatörü nedir ve nasıl çalışır?

Doğrulayıcı Kayıt Operatörü, alt istemcileri (Son RP'ler) dahil eden bir Sertifika Yetkilisi olarak hareket eder. Son RP, Google Cüzdan ile doğrudan etkileşime girmez.

S: Doğrulayıcı Tescil Memuru ve alt müşterileri için özel ilk katılım süreci nedir?

Y: Verifier Registrar Guide'daki (Doğrulayıcı Tescil Ettiren Kılavuzu) adımlara bakın.

S: Bu entegrasyonun doğrudan RP entegrasyonundan farkı nedir?

Y: Doğrulayıcı tescil ettirenler, müşterilerinin güven ilişkisini yönetir ve Google Cüzdan ile entegrasyonu onlar adına gerçekleştirir. Doğrudan RP'ler ise Google ile kendi yapılandırmalarını yönetir.

S: Doğrulayıcı Kayıt Operatörü'nde, Google'ın yapılandırmasında kim izin verilenler listesine eklenir: Doğrulayıcı Kayıt Operatörü, son RP veya her ikisi de mi?

Y: Google, doğrulayıcı tescil ettirenin kök CA sertifikasını izin verilenler listesine ekler. Doğrulayıcı Kayıt Operatörü daha sonra her bir aşağı akış Son RP'si için yeni varlık sertifikaları düzenler.

S: Veriler, son RP, doğrulayıcı kayıt kuruluşu ve Google Cüzdan arasında nasıl akar?

Y: Doğrulayıcı Kayıt Kuruluşu, API isteğini Son RP için Google Cüzdan'a gönderir. Google Cüzdan, şifrelenmiş kimlik bilgisi verilerini Doğrulayıcı Kayıt Memuru'na döndürür. Doğrulayıcı Kayıt Memuru bu verileri işler ve son sinyali Son RP'ye gönderir.

S: Beyaz etiketli çözümlerde, doğrulayıcı tescil ettirenin adının kullanıcı izni akışında gösterilmesi mi gerekir yoksa yalnızca son RP'nin adı gösterilebilir mi?

Y: Hayır. Doğrulayan kayıt operatörü, ayrıntılarını göstermemeyi seçebilir.

S: Kök CA'lar ve RP sertifikaları için izin verilen anahtar türleri ve eğriler nelerdir?

Y: Sertifikalar P-256 / ECDSA kullanılarak oluşturulmalıdır.

S: Kök CA ve RP yaprak sertifikalarımız arasında ara imzalayan sertifikaları kullanabilir miyiz?

Y: Evet. Uzun ömürlü bir kök sertifikayı (ör. HSM'de) güvenli bir şekilde depolayarak operasyonel ara sertifikaları seyrek olarak imzalayabilirsiniz. Bu ara sertifikalar daha sonra uç RP yaprak sertifikalarını imzalamak için kullanılabilir. Böylece, kökü etkilemeden ihlal durumunda daha kolay rotasyon yapılabilir.

S: Sertifikaların geçerlilik süresi ne kadar olmalıdır?

Y: Kök CA sertifikası için 10 yıllık bir kullanım süresi tamamen kabul edilebilir. Sorun çıkması durumunda verimli bir şekilde döndürülebilmeleri için End-RP yaprak sertifikalarının genellikle yaklaşık 1 yıllık yenileme zaman çizelgesine uyması gerekir.

S: Her bir güvenen taraf (RP) müşterisi için ayrı bir yaprak sertifika yönetmemiz gerekiyor mu?

Y: Evet. İlk lansman döneminde toplayıcılar, her bir aşağı akış RP'si için ayrı sertifikalar yönetmelidir. Bu, RP başına görüntüleme yapılandırmalarını ve kötüye kullanımın doğru şekilde izlenmesini sağlar. Bu durum, ölçekli olarak operasyonel ek yük getirse de ilk kullanıma sunma işleminden sonra olası alternatifleri (ör. RP meta verileri karmalarını kullanma) tekrar değerlendirmeyi planlıyoruz.

S: İş ortaklarının aynı anda birden fazla etkin sertifikası olabilir mi?

Y: Evet, yapılandırma, RP veya toplayıcı başına herhangi bir sayıda etkin sertifikayı destekler. Bu, çeşitli işletme adları altında faaliyet gösteren iş ortakları için yararlıdır.

S: Ayırt Edici Ad (Konu) nasıl biçimlendirilmelidir?

Y: Ayırt Edici Ad, iş ortağı başına global olarak benzersiz olmalıdır. Bu, Google'ın gelen iş ortağı isteklerini izlemek ve ekosistem güvenini sağlamak için kullandığı statik bir tanımlayıcıdır.

S: Alan bağlama nasıl çalışır? Kökenlerin sertifikaya yerleştirilmesi gerekir mi?

Y: Alanların doğrudan sertifikanın içine yerleştirilmesi gerekmez. Bunun yerine, alan doğrulama işlemi API çağrısındaki beklenen kaynaklar parametresi kullanılarak gerçekleştirilir. Ayrıca, birden fazla alan tek bir sertifikayla sorunsuz bir şekilde ilişkilendirilebilir. İmzalanmamış istekler için bağlama, alan adı veya uygulama paket adı ile birlikte parmak izi kullanılarak yürütülür.

S: Beyaz etiketli bir deneyim için toplayıcı ayrıntıları doğrulama kullanıcı arayüzünden çıkarılabilir mi?

Y: Evet, doğrulayıcı meta verilerinde toplayıcı bilgileri (ad, logo, URL ve gizlilik politikası gibi) tamamen isteğe bağlıdır. Bu sayede, kullanıcıya yalnızca son RP ayrıntılarının gösterildiği tamamen beyaz etiketli bir çözüm sağlanır.

S: Korumalı alan ortamında test yapmaya başlamak için ne sağlamamız gerekir?

Y: Teknik açıdan bakıldığında, yalnızca korumalı alan kök sertifikanızı sağlamanız gerekir. Korumalı alan, üretim ortamını birebir yansıtacak şekilde tasarlanmıştır.

S: Doğrulayıcı Tescil Memurları (Toplayıcılar) için oryantasyon süreci, doğrudan RP'lere kıyasla nasıl farklılık gösterir?

Y: Toplayıcılar biraz farklı bir süreçten geçer. Belirli Doğrulayıcı Tescil Ettiren Hizmet Şartları'nı uyguladıktan sonra, alım iki bölüme ayrılır: Doğrulayıcı Tescil Ettiren olarak durumunuzu belirlemek için kullanılan birincil form ve ardından, dahil ettiğiniz her bir RP için gerekli olan basitleştirilmiş bir form. Her RP gönderimi için genellikle entegrasyonun video kaydı gerekir ve inceleme süreci genellikle 2-3 iş günü sürer.

S: Aracı olarak hareket etmeyi veya doğrulama hizmetlerini diğer kuruluşlara yeniden satmayı amaçlayan müşterileri kullanıma alabilir miyiz?

Y: Hayır. Google'ın mevcut modeli ve tercihi, iç içe yerleştirilmiş bayi veya aracı modellerini desteklemek yerine doğrudan doğrulayıcı tescil ettirenler (toplayıcılar) ve bunların doğrudan son RP'leri ile çalışmaktır.

S: İsteklerin temel protokolü nedir? Hangi sürümler desteklenir?

Y: Birincil protokol, Doğrulanabilir Sunumlar için OpenID (OpenID4VP) 1.0 sürümüdür.

S: Google, mDL sunumu için hangi ISO 18013-7 eklerini (ör. Ek B, C, D) destekliyor?

Y: Google, Ek D'yi [şu anda taslak halinde] (DC API'yi kullanan OpenID4VP) desteklemektedir.

S: Tek bir kullanıcı sunumunda birden fazla kimlik bilgisi istemek için API isteğini nasıl doğru şekilde yapılandırırız?

Y: Her iki kimlik bilgisi türü de aynı JSON isteğindeki tek bir dcql sorgu nesnesinde istenmelidir.

S: API, olası tüm kimlik bilgisi türlerini listelemeden genel bir kimlik bilgisi isteğinde bulunmaya izin veriyor mu?

Y: Hayır.

S: API, yaş doğrulama işlemini nasıl gerçekleştirir? Tam doğum tarihi mi yoksa yalnızca "X yaşından büyük" sinyali mi istenebilir?

Y: Her ikisi de desteklenir. birth_date, age_in_years veya gizliliği korumaya yönelik "X'ten fazla" sinyali isteyebilirsiniz. Doğru/yanlış sinyali için sıfır bilgi kanıtları (ZKPs) da kullanılabilir.

S: PKI altyapımız için hangi şartlar geçerlidir?

Y: RP'lerin istekleri imzalamak için PKI'ya ihtiyacı vardır. Doğrulayıcı tescil ettirenler kendi CA'ları gibi hareket eder.

S: Mevcut sertifikalarımızı kullanabilir miyiz yoksa Google tarafından imzalanmış yeni bir sertifika mı almamız gerekiyor?

RP'lerin Google veya bir doğrulayıcı kayıt operatörü tarafından imzalanmış yeni bir sertifikaya ihtiyacı vardır. Doğrulayıcı Tescil Ettirenler için Google, dokümandaki "Güven Oluşturma" adımlarını uygulamanız durumunda kök sertifikanıza güvenir.

S: Web ile Android uygulaması için önerilen entegrasyon stratejisi nedir?

Y: İsteğin tamamı sunucu tarafında oluşturulmalıdır. Android'de Credman API'yi, web'de ise Digital Credentials (DC) API'yi kullanın.

S: Geliştiriciler için hangi hata ayıklama, günlük kaydı ve gözlemlenebilirlik araçları kullanılabilir?

Y: İş ortakları wallet-identity-rp-support@google.com destek e-posta adresini kullanabilir. Belirli bir günlük kaydı veya gözlemlenebilirlik aracı sağlanmaz.

S: Hangi dijital kimlikler, veren kuruluşlar ve kimlik bilgileri ülke ve bölgeye göre desteklenir?

Y: Desteklenen bölgeleri Desteklenen Düzenleyen Kuruluşlar ve Sertifikalar sayfasında bulabilirsiniz.

S: Yeni ülkelerdeki veya bölgelerdeki kimlik bilgilerini ne zaman desteklemeyi planlıyorsunuz?

Y: Yeni bölgeler eklemek için çalışıyoruz. Güncellemeler için desteklenen kart verenler sayfasını kontrol edin.

S: Bir kimlik bilgisi veren kuruluş tarafından güncellendiğinde son kullanıcı bildirim alır mı?

Y: Evet, kullanıcı bilgilendirilir ve güncelleme otomatik olarak uygulanır.

S: Uçtan uca akışın tamamını test etmek için nasıl bir hazırlık ortamına erişebiliriz?

Y: Korumalı alan şu adreste açık: Sandbox Mode.

S: Resmi olarak kullanıma sunulan bir bölgede bulunmayan iş ortaklarının test için izin verilenler listesine eklenme süreci nasıldır?

Y: Test cüzdanlarının Gmail kimliklerini wallet-identity-rp-support@google.com adresine e-postayla gönderin.

S: Test web sitesini veya uygulamasını demo amaçlı olarak etkinleştirme ve üretim kimlik bilgisine sahip herkesin bunu sunmasına izin verme süreci nedir?

Y: İş ortakları, sandbox video demosu da dahil olmak üzere standart RP oryantasyonunu tamamlamalıdır.

S: Kullanıcı, doğrulama akışını başlattığında dijital kimliği yoksa veya Google Cüzdan uygulaması yüklü değilse kullanıcı deneyimi nasıl olur?

Y: Uygulamayı yüklememiş olan kullanıcılar Play Store'a yönlendirilir. Kimliği olmayan kullanıcılar, yarım ekranlı kullanıcı arayüzünü kullanarak akış içinde kimlik oluşturabilir.

S: Doğrulama seçeneğini göstermeden önce kullanıcının Cüzdan'ında dijital kimliği olup olmadığını programatik olarak tespit edebilir miyiz?

Y: Hayır, gizliliği korumak için API kullanıcı tarafından çağrılmalıdır.

S: Kimlik bilgisi sunmadan önce kullanıcının cihazının kilidini biyometriyle açmasını zorunlu tutabilir miyiz?

Y: Kullanıcı kimlik doğrulaması (biyometrik, PIN veya desen) varsayılan olarak gereklidir ve devre dışı bırakılamaz.

S: Kullanıcı rızası ekranında istenen özelliklerin sırasını özelleştirmek mümkün mü?

Y: Hayır, Google Cüzdan bunları alfabetik sıraya göre yeniden düzenler.

S: Kullanım alanımız, kullanıcı verilerinin üçüncü taraflarla yeniden paylaşılmasını içeriyor. Bu durum, Hizmet Şartları kapsamında izin verilen bir durum mu?

Y: Evet, kısıtlamalar geçerli olabilir. Daha fazla bilgi için Hizmet Şartlarımızı inceleyin.

S: Uygunluk amaçlarımız doğrultusunda dijital kimlik çözümlerinin güvenliği, güvenilirliği ve erişilebilirliği hakkında hangi belgeler mevcuttur?

Y: İş ortakları, Trail of Bits güvenlik incelemelerine başvurabilir.

S: Gizliliği korumaya yönelik yaş doğrulama için sıfır bilgi kanıtlarının (ZKP) özellikleri nelerdir?

Sıfır bilgi kanıtı (ZKP), bir kişinin (kanıtlayıcı) doğrulayıcıya, belirli bir kimlik bilgisine sahip olduğunu veya belirli bir ölçütü karşıladığını (ör. 18 yaşından büyük olmak, geçerli bir yeterlilik belgesine sahip olmak) temelindeki gerçek verileri açıklamadan kanıtlamasına olanak tanıyan bir kriptografi yöntemidir.

S: ZK devrelerinin farklı sürümleri nasıl işlenir?

Y: RP'ler, mevcut en son devreleri istemek için ZK doğrulayıcı hizmetlerini uygulamalıdır.

S: Kimlik bilgisi paylaşımı ve yönetimi, telefon ve giyilebilir cihaz gibi birden fazla cihazda nasıl çalışır?

Y: Kimlik bilgileri tek bir cihaza sağlanır ve paylaşılamaz.

S: Pasaport iptal edilirse Google, dijital kimlik iptallerini nasıl ele alır?

Y: Kullanıcılar, kartları Google Hesabı ayarlarından silebilir. Kaybolan cihazlar, kimlik bilgilerinin iptal edilmesi için bildirilebilir.

S: mDL iptali nasıl ele alınır? Gerçek zamanlı mı?

Y: Kullanıcı tarafından tetiklenebilir veya kartı veren kuruluş (DMV) tarafından gönderilebilir. Cihaz internete bağlıysa gerçek zamanlıdır. Aksi takdirde kısa ömürlü güvenlik nesnelerinin (MSO'lar) süresi dolar.

S: RP'ler için anahtar rotasyonu politikası nedir?

Y: Yıllık rotasyon önerilir.

S: Dijital Kimlik Bilgileri API'si için desteklenen minimum Android sürümü nedir?

Y: Android 9 (API düzeyi 28) ve sonraki sürümler.

S: Digital Credentials API'yi destekleyen minimum Chrome sürümü nedir?

Y: Chrome 128 ve sonraki sürümler.

S: Hangi tarayıcılar Digital Credentials API'yi destekler?

Y: Tarayıcı desteğiyle ilgili ayrıntıları şu adreste bulabilirsiniz: https://digitalcredentials.dev/ecosystem-support

S: Yeni bir ülke kullanıma sunulduğunda hangi kullanıcılar kimlik ekleyebilir?

Y: Erişim, kullanıcının Play Store'daki ülke ayarına göre belirlenir.

S: Digital Credentials API, iOS ile çalışır mı?

Y: Evet, API, Safari gibi desteklenen tarayıcılarla çalışır. Ancak OpenID4VP, Apple tarafından desteklenmez.