Najczęstsze pytania dotyczące tożsamości cyfrowej i dokumentów tożsamości

Na tej stronie znajdziesz odpowiedzi na najczęstsze pytania dotyczące integracji z Portfelem Google na potrzeby cyfrowych dokumentów tożsamości i danych uwierzytelniających.

Wprowadzenie i pierwsze kroki

P: Jak krok po kroku wygląda proces rejestracji nowego partnera jako strony zależnej?

O: Postępuj zgodnie ze szczegółowym przewodnikiem: Wybierz swoją ścieżkę.

P: Ile zwykle trwa proces wdrażania dostawcy usług?

O: Wprowadzenie trwa zwykle 3–5 dni roboczych.

P: Jak możemy śledzić stan naszej aplikacji strony uzależnionej po jej przesłaniu?

O: Jeśli nie otrzymasz odpowiedzi w ciągu 5 dni, skontaktuj się z naszym zespołem pomocy pod adresem wallet-identity-rp-support@google.com.

P: Gdzie znajdziemy formularz rejestracji dostawcy usług i oficjalną dokumentację dla deweloperów?

A:

P: Jak podane przez nas informacje (takie jak nazwa produktu i logo) będą wykorzystywane w usłudze?

Nazwa produktu i logo są wyświetlane na ekranie zgody dla użytkownika, aby pomóc mu zidentyfikować stronę uzależnioną, która prosi o jego cyfrowy dokument tożsamości. Adresy URL i linki do zasad mogą też być wyświetlane w usłudze.

P: Czy musimy podpisać Warunki korzystania z usługi, jeśli planujemy używać środowiska piaskownicy tylko do programowania i testowania?

O: Nie, zaakceptowanie Warunków korzystania z usługi nie jest wymagane do przeprowadzenia testów.

P: Gdzie znajdziemy przykładową implementację, przykładowy kod lub aplikację demonstracyjną, aby rozpocząć?

A:

Rejestratorzy weryfikatorów

P: Czym jest rejestrator weryfikatora i jak działa?

O: Rejestrator weryfikatorów działa jako urząd certyfikacji, który wprowadza klientów niższego poziomu (strony zależne). Strona zależna nie wchodzi w bezpośrednią interakcję z Portfelem Google.

P: Jak wygląda proces rejestracji weryfikatora i jego klientów?

O: Zapoznaj się z instrukcjami w przewodniku dla rejestratorów weryfikatorów.

P: Czym różni się to od bezpośredniej integracji z RP?

O: Rejestratorzy weryfikujący zarządzają relacją zaufania dla swoich klientów i obsługują integrację z Portfelem Google w ich imieniu, natomiast bezpośrednie strony zależne zarządzają własną konfiguracją z Google.

P: Kto jest dodawany do listy dozwolonych w konfiguracji Google w przypadku rejestratora weryfikatora: rejestrator weryfikatora, strona zależna czy obie te strony?

O: Google dodaje do listy dozwolonych certyfikat główny CA rejestratora weryfikatora. Następnie rejestrator weryfikatora wydaje nowe certyfikaty wierzchołka ścieżki dla każdej platformy RP.

P: Jak wygląda przepływ danych między stroną zależną, rejestratorem weryfikatora i Portfelem Google?

Odp.: Rejestrator weryfikatorów wysyła żądanie do interfejsu API do Portfela Google w imieniu strony zależnej. Portfel Google zwraca zaszyfrowane dane uwierzytelniające do rejestratora weryfikatora, który następnie je przetwarza i wysyła ostateczny sygnał do strony zależnej.

O: Nie. Rejestrator weryfikatora może zdecydować, że nie chce wyświetlać swoich danych.

P: Jakie są dozwolone typy kluczy i krzywe w przypadku głównych urzędów certyfikacji i certyfikatów RP?

O: Certyfikaty powinny być generowane przy użyciu P-256 / ECDSA.

P: Czy między certyfikatem głównego urzędu certyfikacji a certyfikatami wierzchołka ścieżki RP można używać certyfikatów pośrednich?

O: Tak. Możesz bezpiecznie przechowywać długotrwały certyfikat główny (np. w module HSM), aby rzadko podpisywać operacyjne certyfikaty pośrednie. Te certyfikaty pośrednie mogą być następnie używane do podpisywania certyfikatów wierzchołka ścieżki platformy, co ułatwia rotację w przypadku naruszenia bezpieczeństwa bez wpływu na certyfikat główny.

P: Jaki jest wymagany okres ważności certyfikatów?

O: 10-letni okres ważności jest całkowicie akceptowalny w przypadku certyfikatu głównego CA. Certyfikaty wierzchołka ścieżki dla platformy RP powinny być odnawiane co około rok, aby można było je skutecznie rotować w razie problemów.

P: Czy musimy zarządzać osobnym certyfikatem wierzchołka ścieżki dla każdego klienta będącego stroną uzależnioną?

O: Tak. W początkowym okresie po wprowadzeniu tej funkcji agregatory muszą zarządzać osobnymi certyfikatami dla każdej platformy RP. Umożliwia to konfigurację wyświetlania dla poszczególnych dostawców tożsamości i dokładne śledzenie nadużyć. Chociaż zwiększa to obciążenie operacyjne na dużą skalę, po początkowym wdrożeniu zamierzamy rozważyć potencjalne alternatywy (np. użycie haszy metadanych RP).

P: Czy partnerzy mogą mieć jednocześnie kilka aktywnych certyfikatów?

O: Tak, konfiguracja obsługuje dowolną liczbę aktywnych certyfikatów na dostawcę usług lub agregatora, co jest przydatne w przypadku partnerów działających pod różnymi nazwami firm.

P: Jak powinna być sformatowana nazwa wyróżniająca (temat)?

O: Nazwa wyróżniająca musi być globalnie unikalna dla każdego partnera. Służy on jako statyczny identyfikator, którego Google używa do monitorowania przychodzących żądań partnerów i zapewniania zaufania w ekosystemie.

P: Jak działa powiązanie domeny? Czy źródła muszą być umieszczone w certyfikacie?

O: Domeny nie muszą być umieszczone bezpośrednio w samym certyfikacie. Zamiast tego weryfikacja domeny jest przeprowadzana za pomocą parametru oczekiwanego źródła w wywołaniu interfejsu API. Ponadto z jednym certyfikatem można bezproblemowo powiązać wiele domen. W przypadku żądań niepodpisanych powiązanie jest wykonywane przy użyciu nazwy domeny lub pakietu aplikacji oraz odcisku cyfrowego.

P: Czy w interfejsie weryfikacji można pominąć informacje o pośredniku, aby uzyskać rozwiązanie bez oznaczeń marki?

O: Tak, informacje o agregatorze (takie jak nazwa, logo, adres URL i polityka prywatności) są całkowicie opcjonalne w metadanych weryfikatora. Umożliwia to korzystanie z rozwiązania typu white label, w którym użytkownikowi wyświetlane są tylko szczegóły dotyczące platformy docelowej.

P: Co musimy dostarczyć, aby rozpocząć testowanie w środowisku piaskownicy?

O: Z technicznego punktu widzenia musisz podać tylko certyfikat główny piaskownicy. Piaskownica została zaprojektowana tak, aby odzwierciedlała środowisko produkcyjne.

P: Czym różni się proces wprowadzania w przypadku rejestratorów weryfikatorów (agregatorów) od procesu wprowadzania w przypadku bezpośrednich dostawców usług?

O: Pośrednicy przechodzą nieco inny proces. Po zaakceptowaniu Warunków korzystania z usługi dla rejestratorów weryfikatorów proces rejestracji jest podzielony na 2 części: formularz podstawowy, który pozwala uzyskać status rejestratora weryfikatorów, oraz uproszczony formularz wymagany w przypadku każdej osoby, którą chcesz zarejestrować. Każde zgłoszenie RP zwykle wymaga nagrania wideo integracji, a proces sprawdzania trwa zwykle 2–3 dni robocze.

P: Czy możemy rejestrować klientów, którzy zamierzają działać jako pośrednicy lub odsprzedawać usługi weryfikacji innym podmiotom?

O: Nie. Obecny model i preferencje Google polegają na bezpośredniej współpracy z rejestratorami weryfikatorów (agregatorami) i ich bezpośrednimi klientami, a nie na obsłudze modeli zagnieżdżonych sprzedawców lub pośredników.

Integracja techniczna i interfejs API

P: Jaki jest podstawowy protokół żądań? Które wersje są obsługiwane?

O: Głównym protokołem jest OpenID for Verifiable Presentations (OpenID4VP) w wersji 1.0.

P: Które załączniki do normy ISO 18013-7 (np. załącznik B, C, D) obsługuje Google w przypadku prezentacji mDL?

O: Google obsługuje załącznik D [obecnie w wersji roboczej] (OpenID4VP z użyciem interfejsu DC API).

P: Jak prawidłowo sformułować żądanie do interfejsu API, aby poprosić o kilka dokumentów w ramach jednej prezentacji użytkownika?

Odp.: O oba typy danych uwierzytelniających należy prosić w jednym obiekcie zapytania dcql w tym samym żądaniu JSON.

P: Czy interfejs API umożliwia żądanie ogólnych danych logowania bez podawania wszystkich możliwych typów danych logowania?

O: Nie.

P: Jak interfejs API obsługuje weryfikację wieku? Czy możemy poprosić o dokładną datę urodzenia czy tylko o sygnał „powyżej X lat”?

Odp.: Obsługiwane są oba rozwiązania. Możesz poprosić o birth_date, age_in_years lub sygnał „powyżej X” chroniący prywatność. Do sygnału prawda/fałsz można też używać dowodów z wiedzą zerową (ZKP).

Pytanie: Jakie są wymagania dotyczące naszej infrastruktury PKI?

O: Strony uzależnione potrzebują infrastruktury kluczy publicznych do podpisywania żądań. Rejestratorzy weryfikatorów działają jako własny urząd certyfikacji.

P: Czy możemy używać własnych certyfikatów, czy musimy uzyskać nowy certyfikat podpisany przez Google?

O: Dostawcy usług potrzebują nowego certyfikatu podpisanego przez Google lub rejestratora weryfikatorów. W przypadku rejestratorów weryfikatorów Google będzie ufać Twojemu certyfikatowi głównemu, jeśli wykonasz czynności opisane w sekcji „Ustanawianie zaufania” w dokumentacji.

O: Całe żądanie powinno być generowane po stronie serwera. Na Androidzie używaj interfejsu Credman API, a w internecie – interfejsu Digital Credentials (DC) API.

P: Jakie narzędzia do debugowania, logowania i obserwacji są dostępne dla deweloperów?

O: Partnerzy mogą korzystać z aliasu pomocy wallet-identity-rp-support@google.com. Nie są dostępne żadne konkretne narzędzia do logowania ani obserwowania.

Dane logowania i inne dane

P: Które cyfrowe dokumenty tożsamości, wydawcy i dane uwierzytelniające są obsługiwane w poszczególnych krajach i regionach?

O: Obsługiwane regiony znajdziesz tutaj: Obsługiwani wydawcy i certyfikaty.

P: Kiedy planujecie obsługę dokumentów z nowych krajów lub regionów?

O: Cały czas dodajemy nowe regiony. Aktualne informacje znajdziesz na stronie obsługiwanych wydawców.

P: Czy użytkownik otrzymuje powiadomienie, gdy wydawca aktualizuje dokument?

O: Tak, użytkownik zostanie powiadomiony, a aktualizacja zostanie zastosowana automatycznie.

Testowanie i środowiska

P: Jak uzyskać dostęp do środowiska piaskownicy, aby przetestować cały proces?

O: Piaskownica jest dostępna tutaj: Tryb piaskownicy.

P: Jak partnerzy spoza regionu, w którym usługa została oficjalnie wprowadzona, mogą zostać dodani do listy dozwolonych na potrzeby testów?

Odp.: Wyślij e-maila z identyfikatorami Gmaila testowych portfeli na adres wallet-identity-rp-support@google.com.

P: Jak wygląda proces włączania testowej witryny lub aplikacji do celów demonstracyjnych, aby każdy, kto ma dane logowania do wersji produkcyjnej, mógł ją zaprezentować?

O: Partnerzy muszą przejść standardowy proces wprowadzania do programu RP, w tym demonstrację wideo w środowisku testowym.

Wrażenia użytkowników (UX)

P: Jak wygląda proces weryfikacji, jeśli użytkownik nie ma cyfrowego dokumentu tożsamości lub zainstalowanej aplikacji Portfel Google?

O: Użytkownicy, którzy nie mają aplikacji, są przekierowywani do Sklepu Play. Użytkownicy, którzy nie mają dokumentu tożsamości, mogą go utworzyć w procesie za pomocą interfejsu na połowie ekranu.

P: Czy możemy automatycznie wykryć, czy użytkownik ma cyfrowy dokument tożsamości w Portfelu, zanim wyświetlimy mu opcję weryfikacji?

O: Nie, interfejs API musi być wywoływany przez użytkownika, aby chronić prywatność.

P: Czy możemy wymagać od użytkownika odblokowania urządzenia za pomocą danych biometrycznych przed wyświetleniem dokumentu?

O: Uwierzytelnianie użytkownika (biometryczne, kodem PIN lub wzorem) jest domyślnie wymagane i nie można go wyłączyć.

O: Nie, Portfel Google porządkuje je alfabetycznie.

Bezpieczeństwo i zgodność z przepisami

P: Nasz przypadek użycia obejmuje ponowne udostępnianie danych użytkownika osobom trzecim. Czy jest to dozwolone zgodnie z Warunkami korzystania z usługi?

O: Tak, mogą obowiązywać ograniczenia. Więcej informacji znajdziesz w naszych warunkach korzystania z usługi.

P: Jaka dokumentacja dotycząca bezpieczeństwa, niezawodności i dostępności rozwiązań do cyfrowej tożsamości jest dostępna na potrzeby zapewnienia zgodności z przepisami?

O: Partnerzy mogą zapoznać się z kontrolami bezpieczeństwa Trail of Bits.

Funkcje zaawansowane i harmonogram

Pytanie: Jakie są możliwości dowodów z wiedzą zerową (ZKP) w zakresie weryfikacji wieku z zachowaniem prywatności?

Odp.: Dowód z wiedzą zerową (ZKP) to metoda kryptograficzna, która pozwala osobie (udowadniającej) udowodnić weryfikatorowi, że posiada określone informacje o tożsamości lub spełnia określone kryterium (np. ma ukończone 18 lat, posiada ważne uprawnienia) bez ujawniania rzeczywistych danych.

P: Jak są obsługiwane różne wersje obwodów ZK?

O: Platformy muszą wdrożyć usługi weryfikatora ZK, aby żądać najnowszych dostępnych obwodów.

P: Jak działa udostępnianie danych logowania i zarządzanie nimi na wielu urządzeniach, takich jak telefon i urządzenie do noszenia?

O: Dane logowania są udostępniane na jednym urządzeniu i nie można ich udostępniać.

Inne

P: Jak Google postępuje w przypadku unieważnienia cyfrowego dokumentu tożsamości, jeśli paszport został unieważniony?

O: Użytkownicy mogą usuwać karty w ustawieniach konta Google. Zgubione urządzenia można zgłosić, aby unieważnić dane logowania.

P: Jak jest obsługiwane unieważnienie mDL? Czy działa w czasie rzeczywistym?

Odp.: Może to zrobić użytkownik lub wydawca (DMV). Jeśli urządzenie jest online, odbywa się to w czasie rzeczywistym. W przeciwnym razie krótkotrwałe obiekty zabezpieczeń (MSO) wygasną.

P: Jakie są zasady rotacji kluczy dla dostawców tożsamości?

O: Zalecamy rotację co roku.

P: Jaka jest minimalna wersja Androida obsługiwana przez interfejs Digital Credentials API?

O: Android 9 (poziom API 28) lub nowszy.

Pyt.: Jaka jest minimalna wersja Chrome, która obsługuje interfejs Digital Credentials API?

Odp.: Chrome w wersji 128 lub nowszej.

P: Które przeglądarki obsługują interfejs Digital Credentials API?

O: Informacje o obsługiwanych przeglądarkach znajdziesz tutaj: https://digitalcredentials.dev/ecosystem-support.

P: Którzy użytkownicy będą mogli dodać dokument tożsamości, gdy usługa zostanie uruchomiona w nowym kraju?

O: Dostęp zależy od ustawienia kraju użytkownika w Sklepie Play.

P: Czy interfejs Digital Credentials API działa na iOS?

O: Tak, interfejs API działa w obsługiwanych przeglądarkach, takich jak Safari. Jednak Apple nie obsługuje protokołu OpenID4VP.