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 w zakresie tożsamości cyfrowej i dokumentów.

Wprowadzenie i pierwsze kroki

P: Jak wygląda proces wdrażania nowego partnera jako podmiotu ufającego?

O: Postępuj zgodnie z instrukcjami w artykule Akceptowanie dokumentów tożsamości z Portfela online.

P: Ile zwykle trwa proces wdrażania RP?

O: Zwykle proces wprowadzania trwa 3–5 dni roboczych.

P: Jak możemy śledzić stan naszego zgłoszenia podmiotu ufającego po jego przesłaniu?

O: Jeśli po 5 dniach nie otrzymasz odpowiedzi, skontaktuj się z naszym zespołem pomocy na stronie wallet-identity-rp-support@google.com.

P: Gdzie znajdę formularz rejestracyjny RP i oficjalną dokumentację dla deweloperów?

A:

P: Jak informacje, które podajemy (np. nazwa produktu i logo), będą wykorzystywane w usłudze?

Nazwa i logo usługi są wyświetlane na ekranie zgody widocznym dla użytkownika, aby pomóc mu zidentyfikować podmiot, który prosi o jego cyfrowy dokument tożsamości. Adresy URL i linki do zasad mogą też być widoczne 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 w przypadku testowania.

P: Gdzie znajdę implementację referencyjną, przykładowy kod lub aplikację demonstracyjną, aby rozpocząć pracę?

A:

Rejestratorzy weryfikatorów

P: Co to jest rejestrator weryfikatorów i jak działa?

O: Rejestrator weryfikujący pełni funkcję urzędu certyfikacji, który wprowadza klientów niższego szczebla (końcowe podmioty polegające). Podmiot RP nie wchodzi w bezpośrednią interakcję z Portfelem Google.

Pytanie: Jak wygląda proces wdrażania w przypadku rejestratora weryfikującego i jego klientów niższego szczebla?

O: Wykonaj czynności opisane w przewodniku dla rejestratorów weryfikujących.

P: Czym różni się od bezpośredniej integracji z platformą wydawców?

O: Rejestratorzy weryfikatorów zarządzają relacją zaufania w imieniu swoich klientów i odpowiadają za integrację z Portfelem Google, natomiast bezpośredni dostawcy tożsamości zarządzają własną konfiguracją w Google.

P: Kto jest dodawany do listy dozwolonych w konfiguracji Google w przypadku rejestratora weryfikatora: rejestrator weryfikatora, końcowa strona ufająca czy obie te strony?

Google dodaje certyfikat głównego urzędu certyfikacji rejestratora weryfikatora do listy dozwolonych. Rejestrator weryfikujący wydaje następnie nowe certyfikaty końcowe dla każdego podrzędnego dostawcy usług końcowych.

P: Jak przepływ danych odbywa się między końcową usługą RP, rejestratorem weryfikatora a Portfelem Google?

Rejestrator weryfikatora wysyła żądanie do interfejsu API do Portfela Google dla końcowej strony RP. Portfel Google zwraca zaszyfrowane dane dokumentu tożsamości do rejestratora weryfikatora, który je przetwarza i wysyła sygnał końcowy do podmiotu końcowego.

Nie. Rejestrator weryfikujący może zdecydować, że nie będzie wyświetlać swoich danych.

Pytanie: 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 możemy używać pośrednich certyfikatów sygnujących między naszym głównym urzędem certyfikacji a certyfikatami liści RP?

O: Tak. Możesz bezpiecznie przechowywać długoterminowy 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 końcowych RP, 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?

10-letni okres ważności jest w przypadku certyfikatu głównego urzędu certyfikacji w pełni akceptowalny. Certyfikaty liściowe End-RP powinny być odnawiane co około rok, aby w razie problemów można było je skutecznie wymieniać.

P: Czy musimy zarządzać oddzielnym certyfikatem końcowym dla każdego klienta Relying Party (RP)?

O: Tak. W początkowym okresie wdrażania agregatorzy muszą zarządzać oddzielnymi certyfikatami dla każdego podmiotu RP niższego szczebla. Umożliwia to konfiguracje wyświetlania dla poszczególnych platform wydawców i dokładne śledzenie nadużyć. Chociaż na dużą skalę zwiększa to obciążenie operacyjne, po początkowym wdrożeniu zamierzamy ponownie rozważyć potencjalne alternatywy (np. używanie skrótów 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ę tożsamości lub agregatora, co jest przydatne dla partnerów działających pod różnymi nazwami firm.

P: Jak powinien być sformatowany atrybut Nazwa wyróżniająca (podmiot)?

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

P: Jak działa powiązanie domeny? Czy pochodzenie musi być osadzone w certyfikacie?

O: Domeny nie muszą być osadzone bezpośrednio w certyfikacie. Zamiast tego weryfikacja domeny jest przeprowadzana za pomocą parametru oczekiwanych punktów początkowych w wywołaniu interfejsu API. Poza tym z jednym certyfikatem można bezproblemowo powiązać wiele domen. W przypadku niepodpisanych żądań powiązanie jest wykonywane przy użyciu nazwy domeny lub nazwy pakietu aplikacji wraz z odciskiem cyfrowym.

P: Czy w przypadku interfejsu weryfikacji w ramach usługi white label można pominąć szczegóły dotyczące agregatora?

O: Tak, informacje o agregatorze (takie jak nazwa, logo, adres URL i polityka prywatności) są w metadanych weryfikatora całkowicie opcjonalne. Umożliwia to w pełni markowe rozwiązanie, w którym użytkownikowi wyświetlane są tylko szczegóły dostawcy tożsamości.

Pytanie: Co musimy podać, aby rozpocząć testowanie w środowisku piaskownicy?

O: Z technicznego punktu widzenia wystarczy, że podasz główny certyfikat piaskownicy. Piaskownica jest zaprojektowana tak, aby identycznie odzwierciedlać ś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 tożsamości?

O: W przypadku agregatorów stosujemy nieco zmodyfikowany proces. Po zaakceptowaniu Warunków usługi dla podmiotu weryfikującego proces rejestracji jest podzielony na 2 części: podstawowy formularz, który potwierdza status podmiotu weryfikującego, oraz uproszczony formularz wymagany w przypadku każdego podmiotu polegającego na tożsamości, który zostanie przez Ciebie zarejestrowany. Każde zgłoszenie RP wymaga zwykle nagrania wideo przedstawiającego integrację, a proces sprawdzania trwa zwykle 2–3 dni robocze.

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

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

Integracja techniczna i interfejs API

Pytanie: Jaki protokół jest używany do przesyłania żą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. B, C, D) są obsługiwane przez 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 skonstruować żądanie do interfejsu API, aby poprosić o wiele dokumentów tożsamości w ramach jednej prezentacji użytkownika?

Oba typy danych logowania należy przesłać 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.

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

O: Oba są obsługiwane. Możesz poprosić o sygnał birth_date, age_in_years lub sygnał „ponad X” chroniący prywatność. Do sygnału typu prawda/fałsz można też używać dowodów zerowej wiedzy (ZKPs).

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

O: Podmioty ufające potrzebują infrastruktury kluczy publicznych do podpisywania żądań. Rejestratorzy weryfikujący 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 muszą mieć nowy certyfikat podpisany przez Google lub rejestratora weryfikującego. W przypadku rejestratorów weryfikatorów Google będzie ufać Twojemu certyfikatowi głównemu, jeśli wykonasz kroki opisane w sekcji „Ustanawianie zaufania” w dokumentacji.

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

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

O: Partnerzy mogą używać wallet-identity-rp-support@google.com aliasu e-mail do pomocy. Nie udostępniamy żadnych konkretnych narzędzi do logowania ani obserwacji.

Dane logowania i dane

P: Jakie dokumenty tożsamości, wydawcy i poświadczenia cyfrowe są obsługiwane w poszczególnych krajach i regionach?

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

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

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

P: Czy gdy wystawca zaktualizuje dokument, użytkownik otrzyma powiadomienie?

O: Tak, użytkownik jest powiadamiany, a aktualizacja jest stosowana automatycznie.

P: Jakie dane logowania, jeśli w ogóle, Google przechowuje na swoich serwerach, zwłaszcza w kontekście RODO?

O: Google nie zapisuje danych związanych z informacjami logowania na swoich serwerach. Są one przechowywane lokalnie i bezpiecznie na urządzeniu użytkownika.

Testowanie i środowiska

Pytanie: Jak uzyskać dostęp do środowiska testowego, aby przetestować pełny proces?

O: Piaskownica jest otwarta w sekcji Tryb piaskownicy.

P: Jak partnerzy, którzy nie mają siedziby w regionie, w którym oficjalnie uruchomiono program, mogą zostać dodani do listy dozwolonych w celu testowania?

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

P: Jak włączyć testową witrynę lub aplikację do celów demonstracyjnych, aby każda osoba z danymi logowania do wersji produkcyjnej mogła ją zaprezentować?

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

Wrażenia użytkowników (UX)

P: Co się stanie, jeśli użytkownik nie ma cyfrowego dokumentu tożsamości lub aplikacji Portfel Google, gdy rozpocznie proces weryfikacji?

O: Użytkownicy, którzy nie mają aplikacji, są kierowani do Sklepu Play. Osoby, które nie mają identyfikatora, mogą go utworzyć w trakcie procesu za pomocą interfejsu użytkownika na pół ekranu.

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

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

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

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

O: Nie, Portfel Google zmienia ich kolejność na alfabetyczną.

Bezpieczeństwo i zgodność z przepisami

Pyt.: W naszym przypadku chodzi o ponowne udostępnianie danych użytkowników innym firmom. Czy jest to dozwolone w Warunkach korzystania z usługi?

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

P: Jakie dokumenty dotyczące bezpieczeństwa, niezawodności i dostępności rozwiązań w zakresie tożsamości cyfrowej są dostępne na potrzeby zapewnienia zgodności z przepisami?

O: Partnerzy mogą korzystać z kontroli bezpieczeństwa przeprowadzonych przez Trail of Bits.

Funkcje zaawansowane i plan rozwoju

P: Jakie możliwości w zakresie ochrony prywatności daje weryfikacja wieku oparta na dowodach z zerową wiedzą?

O: Dowód z zerową wiedzą (ZKP) to metoda kryptograficzna, która umożliwia osobie (udowadniającej) udowodnienie 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 poświadczenie), bez ujawniania rzeczywistych danych bazowych.

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

O: Usługodawcy muszą wdrożyć usługi weryfikacji ZK, aby poprosić o najnowsze dostępne obwody.

P: Jak działa udostępnianie i zarządzanie danymi logowania na wielu urządzeniach, np. telefonie i urządzeniu do noszenia?

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

Inne

P: Co się stanie z dokumentem tożsamości, jeśli paszport zostanie unieważniony?

O: Użytkownicy mogą usuwać karty z ustawień konta Google. W przypadku zgubienia urządzenia można zgłosić ten fakt, aby cofnąć dane logowania.

P: Jak przebiega odwoływanie mDL? Czy jest to w czasie rzeczywistym?

O: Może być wywołane przez użytkownika lub przesłane przez wydawcę (DMV). Jeśli urządzenie jest online, ochrona jest realizowana w czasie rzeczywistym. W przeciwnym razie krótkotrwałe obiekty zabezpieczeń (MSO) wygasną.

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

O: Zalecamy rotację roczną.

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

O: Android 9 (poziom 28 interfejsu API) i nowszy.

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

O: Chrome w wersji 128 lub nowszej.

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

O: Szczegółowe informacje o obsłudze przeglądarek znajdziesz tutaj: https://digitalcredentials.dev/ecosystem-support

P: Którzy użytkownicy będą mogli dodać dokument tożsamości po wprowadzeniu usługi w nowym kraju?

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

Pyt.: Czy interfejs Digital Credentials API działa na urządzeniach z iOS?

O: Tak. Interfejs API działa w obsługiwanych przeglądarkach, takich jak Safari. Apple nie obsługuje jednak OpenID4VP.