Bu sayfada, Dijital Kimlik ve Kimlik Bilgileri için Google Cüzdan ile entegrasyon hakkında sık sorulan soruların yanıtları yer almaktadır.
Oryantasyon ve Başlangıç
S: Yeni bir iş ortağının, bağlı taraf (RP) olarak oryantasyon sürecinde izlemesi gereken adımlar nelerdir?
Y: Yolunuzu Seçin sayfasındaki adım adım açıklamalı kılavuzu uygulayın.
S: RP ilk katılım süreci genellikle ne kadar sürer?
C: İlk katılım süreci genellikle 3-5 iş günü sürer.
S: Gönderimden sonra Güvenen Taraf (GT) başvurumuzun durumunu nasıl takip edebiliriz?
Y: 5 gün içinde yanıt almazsanız lütfen wallet-identity-rp-support@google.com adresinden destek ekibimizle iletişime geçin.
S: Bağlı taraf oryantasyon formunu ve resmi geliştirici belgelerini nerede bulabiliriz?
C:
- İlk katılım formu: Google Cüzdan Kimlik Bilgilerine Güvenen İş Ortakları İletişim Formu
- Geliştirici Belgeleri: Dijital Kimliğe Genel Bakış
S: Sağladığımız bilgiler (ör. ürün adı ve logo) ürün deneyiminde nasıl kullanılacak?
Ürün adı ve logo, kullanıcıların dijital kimliklerini hangi bağlı tarafın istediğini belirlemelerine yardımcı olmak için kullanıcılara yönelik kullanıcı rızası ekranında gösterilir. URL'ler ve politika bağlantıları da ürün deneyiminde yer alabilir.
S: Korumalı alanı yalnızca geliştirme ve test için kullanmayı planlıyorsak Hizmet Şartları'nı imzalamamız gerekir mi?
C: Hayır, Hizmet Şartları'nı kabul etmek test için zorunlu 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
Doğrulayıcı Kayıt Operatörleri
S: Doğrulayıcı Kayıt Operatörü nedir ve nasıl çalışır?
Y: Doğrulayıcı Kayıt Birimi, alt istemcileri (Son RP'ler) kaydeden bir Sertifika Yetkilisi olarak görev yapar. Son bağlı taraf, Google Cüzdan ile doğrudan etkileşimde bulunmaz.
S: Doğrulayıcı kayıt operatörü ve alt müşterileri için özel oryantasyon süreci nedir?
Y: Doğrulayıcı Kayıt Operatörü Kılavuzu'ndaki adımları uygulayın.
S: Doğrudan RP entegrasyonundan farkı nedir?
A: Doğrulayıcı Kayıt Kuruluşları, müşterileri için güven ilişkisini yönetir ve Google Cüzdan ile entegrasyonu onlar adına gerçekleştirir; doğrudan Kayıt Kuruluşları ise Google ile kendi yapılandırmalarını kendileri yönetir.
S: Doğrulayıcı Kayıt Sorumlusu'nda, Google'ın yapılandırmasında kimler izin verilenler listesine eklenir: Doğrulayıcı Kayıt Sorumlusu mu, son bağlı taraf mı yoksa her ikisi mi?
Y: Google, Doğrulayıcı Kayıt Şirketi'nin kök CA sertifikasını izin verilenler listesine ekler. Doğrulayıcı Kayıt Sorumlusu, her bir alt uç bağlı taraf için yeni varlık sertifikaları düzenler.
S: Son kullanıcı noktası (RP), Doğrulayıcı Kayıt Kuruluşu ve Google Cüzdan arasında veri akışı nasıl gerçekleşir?
C: Doğrulayıcı Kayıt Operatörü, Son Bağlı Taraf için Google Cüzdan'a API isteği gönderir. Google Cüzdan, şifrelenmiş kimlik bilgisi verilerini Doğrulayıcı Kayıt Sorumlusu'na döndürür. Doğrulayıcı Kayıt Sorumlusu, bu verileri işler ve son sinyali Son Bağlı Taraf'a gönderir.
S: Beyaz etiketli çözümlerde, kullanıcı rızası akışında Doğrulayıcı Kayıt Şirketi'nin adının gösterilmesi zorunlu mu yoksa yalnızca son bağlı tarafın adı gösterilebilir mi?
C: Hayır. Doğrulayıcı Kayıt Şirketi, bilgilerini göstermemeyi seçebilir.
S: Kök CA'lar ve RP sertifikaları için izin verilen anahtar türleri ve eğriler nelerdir?
C: Sertifikalar P-256/ECDSA kullanılarak oluşturulmalıdır.
S: Kök CA ve RP varlık 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 saklayarak operasyonel ara sertifikaları seyrek olarak imzalayabilirsiniz. Bu ara sertifikalar daha sonra son RP varlık sertifikalarını imzalamak için kullanılabilir. Böylece, ihlal durumunda kök sertifikayı etkilemeden daha kolay rotasyon yapılabilir.
S: Sertifikalar için gereken kullanım ömrü nedir?
Y: Kök CA sertifikası için 10 yıllık bir kullanım ömrü tamamen kabul edilebilir. Son bağlı taraf varlık sertifikaları, sorun çıkması durumunda verimli bir şekilde değiştirilebilmeleri için genellikle yaklaşık 1 yıllık yenileme zaman çizelgesine uymalıdır.
S: Her bir Güvenen Taraf (RP) müşterisi için ayrı bir varlık sertifikası yönetmemiz gerekir mi?
Y: Evet. İlk lansman döneminde toplayıcılar, her alt RP için ayrı sertifikalar yönetmelidir. Bu sayede, bağlı taraf başına görüntüleme yapılandırmaları ve doğru kötüye kullanım takibi yapılabilir. Bu durum, geniş ölçekte operasyonel ek yük getirse de ilk kullanıma sunma aşamasından sonra olası alternatifleri (ör. RP meta veri karmalarını kullanma) yeniden değerlendirmeyi planlıyoruz.
S: İş ortaklarının aynı anda birden fazla etkin sertifikaya sahip olmasına izin verilir mi?
C: 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 kullanışlıdır.
S: Ayırt Edici Ad (Konu) nasıl biçimlendirilmelidir?
C: Ayırt Edici Ad, her iş ortağı için global olarak benzersiz olmalıdır. Bu, Google'ın gelen iş ortağı isteklerini izlemek ve ekosistemin güvenilirliğini sağlamak için kullandığı statik bir tanımlayıcıdır.
S: Alan bağlama nasıl çalışır? Kaynakların sertifikaya yerleştirilmesi gerekir mi?
C: Alanların doğrudan sertifikaya yerleştirilmesi gerekmez. Bunun yerine, alan doğrulaması 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ış isteklerde bağlama işlemi, alan adı veya uygulama paketi adı ve parmak izi kullanılarak gerçekleştirilir.
S: Beyaz etiketli bir deneyim için toplayıcı ayrıntıları doğrulama kullanıcı arayüzünden çıkarılabilir mi?
C: Evet, toplayıcı bilgileri (ör. ad, logo, URL ve gizlilik politikası) doğrulayıcı meta verilerinde tamamen isteğe bağlıdır. Bu sayede, kullanıcıya yalnızca son tarafın ayrıntılarının gösterildiği, tamamen beyaz etiketli bir çözüm sunulur.
S: Korumalı alan ortamında test yapmaya başlamak için ne sağlamamız gerekiyor?
Y: Teknik açıdan yalnızca korumalı alan kök sertifikanızı sağlamanız gerekir. Korumalı alan, üretim ortamını bire bir yansıtacak şekilde tasarlanmıştır.
S: Doğrulayıcı Kayıt Operatörleri (Toplayıcılar) için oryantasyon süreci, doğrudan bağlı olan taraflara kıyasla nasıl farklılık gösterir?
C: Toplayıcılar biraz farklı bir süreçten geçer. Doğrulayıcı Kayıt Şirketi Hizmet Şartları'nı uyguladıktan sonra, katılım süreci iki bölüme ayrılır: Doğrulayıcı Kayıt Şirketi olarak durumunuzu belirlemek için birincil form ve ardından, katıldığınız her bir RP için gereken basitleştirilmiş 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 etmek veya doğrulama hizmetlerini diğer tüzel kişilere yeniden satmak isteyen müşterileri kabul edebilir miyiz?
C: Hayır. Google'ın mevcut modeli ve tercihi, iç içe geçmiş bayi veya aracı modellerini desteklemek yerine doğrudan Doğrulayıcı Kayıt Operatörleri (toplayıcılar) ve bunların doğrudan son bağlı tarafları ile çalışmaktır.
Teknik Entegrasyon ve API
S: İstekler için temel protokol nedir? Hangi sürümler destekleniyor?
Y: Birincil protokol, Doğrulanabilir Sunumlar için OpenID (OpenID4VP) sürüm 1.0'dır.
S: Google, mDL sunumu için hangi ISO 18013-7 eklerini (ör. Ek B, C, D) destekler?
Y: Google, Ek D'yi [şu anda taslak halinde] (DC API kullanan OpenID4VP) destekler.
S: Tek bir kullanıcı sunumunda birden fazla kimlik bilgisi istemek için API isteğini nasıl doğru şekilde yapılandırabiliriz?
Y: Her iki kimlik bilgisi türü de aynı JSON isteğindeki tek bir dcql sorgu nesnesi içinde istenmelidir.
S: API, olası her kimlik bilgisi türünü listelemeden genel bir kimlik bilgisi istemeye izin veriyor mu?
C: Hayır.
S: API, yaş doğrulama işlemini nasıl gerçekleştirir? Tam doğum tarihini mi yoksa yalnızca "X yaşından büyük" sinyalini mi isteyebiliriz?
C: İkisi de desteklenir. birth_date, age_in_years veya gizliliği korumaya yönelik "X yaşından büyük" sinyali isteyebilirsiniz. Sıfır bilgi kanıtları (ZKP'ler), doğru/yanlış sinyali için de kullanılabilir.
S: PKI altyapımız için gereksinimler nelerdir?
C: Geçiş anahtarı tarafının, istekleri imzalamak için bir PKI'ya ihtiyacı vardır. Doğrulayıcı kayıt operatörleri kendi CA'ları olarak hareket eder.
S: Mevcut sertifikalarımızı kullanabilir miyiz yoksa Google tarafından imzalanmış yeni bir sertifika almamız gerekir mi?
Y: Güvenen tarafların, Google veya bir doğrulayıcı tescil ettiren tarafından imzalanmış yeni bir sertifikaya ihtiyacı vardır. Doğrulayıcı Kayıt Operatörleri için Google, dokümanlardaki "Güven Oluşturma" adımlarını uygularsanız kök sertifikanıza güvenir.
S: Web ve 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 hangi hata ayıklama, günlük kaydı ve gözlemlenebilirlik araçlarını kullanabilir?
Y: İş ortakları wallet-identity-rp-support@google.com destek takma adını kullanabilir. Belirli bir günlük kaydı veya gözlemlenebilirlik aracı sağlanmaz.
Kimlik Bilgileri ve Veriler
S: Ülke ve bölgeye göre hangi dijital kimlikler, veren kuruluşlar ve kimlik bilgileri desteklenir?
Y: Desteklenen bölgeleri Desteklenen Verenler ve Sertifikalar sayfasında bulabilirsiniz.
S: Yeni ülkelerden veya bölgelerden kimlik bilgilerini ne zaman desteklemeyi planlıyorsunuz?
C: Aktif olarak yeni bölgeler ekliyoruz. Güncellemeler için desteklenen kart veren kuruluşlar sayfasını kontrol edin.
S: Kimlik bilgisi veren kuruluş tarafından güncellendiğinde son kullanıcı bildirim alır mı?
C: Evet, kullanıcı bilgilendirilir ve güncelleme otomatik olarak uygulanır.
Test ve Ortamlar
S: Uçtan uca akışın tamamını test etmek için korumalı alan ortamına nasıl erişebiliriz?
C: Korumalı alan Korumalı Alan Modu'nda açılır.
S: Resmi olarak lansmanı yapılan bir bölgede bulunmayan iş ortaklarının test için izin verilenler listesine eklenmesi süreci nasıldır?
C: Test cüzdanlarının Gmail kimliklerini wallet-identity-rp-support@google.com adresine e-posta ile gönderin.
S: Demo amaçlı bir test web sitesini veya uygulamasını etkinleştirme ve üretim kimlik bilgisine sahip herkesin bunu sunmasına izin verme süreci nedir?
C: İş ortakları, korumalı alan video gösterimi de dahil olmak üzere standart RP oryantasyonunu tamamlamalıdır.
Kullanıcı Deneyimi (UX)
S: Doğrulama akışını başlatan kullanıcının dijital kimliği veya Google Cüzdan uygulaması yoksa kullanıcı deneyimi nasıl olur?
C: Uygulamayı yüklememiş olan kullanıcılar Google Play Store'a yönlendirilir. Kimliği olmayanlar, yarım ekran kullanıcı arayüzünü kullanarak akış içinde kimlik oluşturabilir.
S: Kullanıcılara doğrulama seçeneğini göstermeden önce Cüzdan'larında dijital kimlik olup olmadığını programatik olarak tespit edebilir miyiz?
C: Hayır, gizliliği korumak için API'nin kullanıcı tarafından çağrılması gerekir.
S: Kimlik bilgisi sunmadan önce kullanıcının cihazının kilidini biyometrik veriyle açmasını zorunlu kılabilir miyiz?
C: Kullanıcı kimlik doğrulaması (biyometrik, PIN veya desen) varsayılan olarak zorunludur ve devre dışı bırakılamaz.
S: Kullanıcı rızası ekranında istenen özelliklerin sırasını özelleştirmek mümkün mü?
C: Hayır, Google Cüzdan bunları alfabetik olarak yeniden sıralar.
Güvenlik ve Uygunluk
S: Kullanım alanımız, kullanıcı verilerinin üçüncü taraflarla yeniden paylaşılmasını içeriyor. Hizmet Şartları kapsamında buna izin veriliyor 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 ile ilgili hangi belgeler mevcut?
C: İş ortakları, Trail of Bits güvenlik incelemelerine başvurabilir.
İleri Seviye Özellikler ve Yol Haritası
S: Gizliliği korumaya yönelik yaş doğrulaması için Sıfır Bilgi Kanıtları'nın (ZKP) özellikleri nelerdir?
Y: Sıfır Bilgi Kanıtı (ZKP), bir kişinin (kanıtlayan) belirli bir kimlik bilgisine sahip olduğunu veya belirli bir ölçütü karşıladığını (ör.18 yaşından büyük olduğunu, geçerli bir kimlik bilgisine sahip olduğunu) doğrulayıcıya kanıtlamasını sağlayan bir şifreleme yöntemidir. Bu yöntem, temel verilerin kendisini ifşa etmeden çalışır.
S: ZK devrelerinin farklı sürümleri nasıl işlenir?
C: Sorumlu taraflar, 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?
C: Kimlik bilgileri tek bir cihaz için sağlanır ve paylaşılamaz.
Diğer
S: Pasaport iptal edilirse Google, dijital kimlik iptallerini nasıl işler?
C: Kullanıcılar, kartları Google Hesabı ayarlarından silebilir. Kayıp cihazlar, kimlik bilgilerinin iptal edilmesi için bildirilebilir.
S: mDL iptali nasıl yapılır? Gerçek zamanlı mı?
C: Kullanıcı tarafından tetiklenebilir veya veren kuruluş (DMV) tarafından gönderilebilir. Cihaz internete bağlıysa gerçek zamanlıdır. Aksi takdirde, kısa süreli güvenlik nesnelerinin (MSO'lar) süresi dolar.
S: Bağlı taraflar için anahtar rotasyonu politikası nedir?
C: Yıllık rotasyon önerilir.
S: Digital Credentials API 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?
C: Chrome 128 ve sonraki sürümler.
S: Digital Credentials API'yi hangi tarayıcılar destekler?
Y: Tarayıcı desteğiyle ilgili ayrıntıları https://digitalcredentials.dev/ecosystem-support adresinde bulabilirsiniz.
S: Yeni bir ülke kullanıma sunulduğunda hangi kullanıcılar kimlik ekleyebilecek?
C: Erişim, kullanıcının Play Store'daki ülke ayarına bağlıdır.
S: Digital Credentials API, iOS ile çalışır mı?
A: Evet, API, Safari gibi desteklenen tarayıcılarla çalışır. Ancak OpenID4VP, Apple tarafından desteklenmez.