Dijital Kimlik ve Kimlik Bilgileri SSS

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, güvenen taraf (RP) olarak hizmete alım sürecinin adımları nelerdir?

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 oryantasyon 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 içinde 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:

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:

Doğrulayıcı Kayıt Operatörleri

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

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

Doğrulayıcı kayıt operatörleri 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: Veri akışı, son RP, doğrulayıcı kayıt kuruluşu ve Google Cüzdan arasında nasıl gerçekleşir?

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.

Y: Hayır. Doğrulayıcı 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 varlık sertifikalarını imzalamak için kullanılabilir. Böylece, kökü etkilemeden ihlal durumunda daha kolay döngü 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 bir yenileme zaman çizelgesine uyması gerekir.

S: Her bir Relying Party (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, parmak iziyle birlikte alan veya uygulama paket adı kullanılarak yürütülür.

S: Beyaz etiketli deneyim için doğrulama kullanıcı arayüzünde toplayıcı ayrıntıları atlanabilir 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, yalnızca son RP ayrıntılarının kullanıcıya gösterildiği tamamen beyaz etiketli bir çözüm sağlar.

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

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ı 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 değiştirilmiş 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.

Teknik Entegrasyon ve API

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?

Her iki kimlik bilgisi türü de aynı JSON isteğindeki tek bir dcql sorgu nesnesi içinde 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: RPs, istekleri imzalamak için PKI'ye ihtiyaç duyar. Doğrulayıcı kayıt kuruluşları 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 Memurları için Google, dokümandaki "Güven Oluşturma" adımlarını uygulamanız durumunda kök sertifikanıza güvenir.

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.

Kimlik bilgileri ve veriler

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: Google, özellikle GDPR bağlamında, sunucularında hangi kimlik bilgisi verilerini saklar?

Y: Google, kimlik bilgileriyle ilgili verileri sunucularına kaydetmez. Bu veriler, kullanıcının cihazında yerel olarak ve güvenli bir şekilde saklanır.

Test ve Ortamlar

S: Uçtan uca akışın tamamını test etmek için nasıl bir test 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: Canlı sürüm kimlik bilgisine sahip herkesin sunmasına izin vererek demo amacıyla bir test web sitesini veya uygulamasını etkinleştirme süreci nedir?

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

Kullanıcı deneyimi (UX)

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

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: 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?

Y: 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 verilerle 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.

Y: 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ı uyarınca 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 hakkında hangi belgeler mevcuttur?

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

Gelişmiş Özellikler ve Yol Haritası

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 cihazda sağlanır ve paylaşılamaz.

Diğer

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

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

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

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: Dijital Kimlik Bilgileri API'sini destekleyen minimum Chrome sürümü nedir?

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

S: Hangi tarayıcılar Dijital Kimlik Bilgileri API'sini 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: Dijital Kimlik Bilgileri API'si iOS ile çalışır mı?

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