Häufig gestellte Fragen zu digitalen Identitäten und Anmeldedaten

Auf dieser Seite finden Sie Antworten auf häufig gestellte Fragen zur Integration in Google Wallet für digitale Identitäten und Ausweise.

Onboarding und erste Schritte

F: Wie läuft der Onboarding-Prozess für einen neuen Partner als Relying Party (RP) ab?

A: Folgen Sie der detaillierten Anleitung unter Weg auswählen.

F: Wie lange dauert der Onboarding-Prozess für RP normalerweise?

A: Das Onboarding dauert in der Regel 3–5 Arbeitstage.

F: Wie können wir den Status unseres Antrags als vertrauende Partei (Relying Party, RP) nach dem Einreichen verfolgen?

A: Wenn du nach 5 Tagen noch keine Antwort erhalten hast, wende dich bitte an unser Supportteam unter wallet-identity-rp-support@google.com.

F: Wo finden wir das Onboarding-Formular für vertrauende Seiten und die offizielle Entwicklerdokumentation?

A:

F: Wie werden die von uns bereitgestellten Informationen (z. B. Produktname und Logo) im Produkt verwendet?

A: Der Produktname und das Logo werden auf dem für Nutzer sichtbaren Zustimmungsbildschirm angezeigt, damit Nutzer erkennen können, welche vertrauende Seite ihre digitale ID anfordert. URLs und Links zu Richtlinien können auch im Produkt angezeigt werden.

F: Müssen wir die Nutzungsbedingungen unterzeichnen, wenn wir die Sandbox-Umgebung nur für die Entwicklung und Tests verwenden möchten?

A: Nein, das Akzeptieren der Nutzungsbedingungen ist für Tests nicht erforderlich.

F: Wo finden wir eine Referenzimplementierung, Beispielcode oder eine Demoanwendung für den Einstieg?

A:

Prüfende Registrare

F: Was ist die Verifier Registry und wie funktioniert sie?

A: Die Verifier Registrar fungiert als Zertifizierungsstelle, die nachgelagerte Clients (End-RPs) einbindet. Die End-RP interagiert nicht direkt mit Google Wallet.

F: Wie läuft das Onboarding für Prüfer-Registrare und ihre nachgelagerten Kunden ab?

A: Eine Anleitung finden Sie im Leitfaden für Prüfer-Registrare.

F: Wie unterscheidet sich das von einer direkten RP-Integration?

A: Prüfer-Registrare verwalten die Vertrauensbeziehung für ihre Kunden und übernehmen die Integration in Google Wallet in deren Namen. Direkte vertrauende Seiten verwalten ihre eigene Konfiguration mit Google.

F: Wer wird in der Google-Konfiguration im Verifier Registrar auf die Zulassungsliste gesetzt: der Verifier Registrar, die End-RP oder beide?

A: Google setzt das Root-CA-Zertifikat des Verifier Registrars auf die Zulassungsliste. Der Verifier Registrar stellt dann neue untergeordnete Zertifikate für jede nachgelagerte End-RP aus.

F: Wie fließen die Daten zwischen der End-RP, dem Verifier Registrar und Google Wallet?

A: Der Prüfer-Registrar sendet die API-Anfrage für die End-RP an Google Wallet. Google Wallet gibt verschlüsselte Anmeldedaten an die Prüfer-Registrierungsstelle zurück, die diese dann verarbeitet und das endgültige Signal an die End-RP sendet.

A: Nein. Der Verifier Registrar kann sich dafür entscheiden, seine Details nicht anzuzeigen.

F: Welche Schlüsseltypen und Kurven sind für Stammzertifizierungsstellen und RP-Zertifikate zulässig?

A: Zertifikate sollten mit P-256/ECDSA generiert werden.

F: Können wir zwischen unserer Stammzertifizierungsstelle und den untergeordneten Zertifikaten des vertrauenden Beteiligten Zwischenzertifikate verwenden?

A: Ja. Sie können ein langlebiges Root-Zertifikat sicher speichern (z.B. in einem HSM), um gelegentlich operative Zwischenzertifikate zu signieren. Diese Zwischenzertifikate können dann zum Signieren von untergeordneten Zertifikaten der End-RP verwendet werden. Das ermöglicht eine einfachere Rotation im Falle einer Sicherheitsverletzung, ohne dass das Root-Zertifikat betroffen ist.

F: Wie lange müssen Zertifikate gültig sein?

A: Eine Lebensdauer von 10 Jahren ist für ein Stamm-CA-Zertifikat völlig akzeptabel. Untergeordnete Zertifikate von End-RPs sollten im Allgemeinen etwa einmal pro Jahr erneuert werden, damit sie bei Problemen effizient rotiert werden können.

F: Müssen wir für jeden einzelnen Relying Party-Kunden (RP) ein separates untergeordnetes Zertifikat verwalten?

A: Ja. In der ersten Einführungsphase müssen Aggregatoren separate Zertifikate für jeden nachgelagerten RP verwalten. Dies ermöglicht die Konfiguration der Anzeige pro vertrauender Seite und ein genaues Tracking von Missbrauch. Dies bedeutet zwar einen gewissen Mehraufwand, wir beabsichtigen jedoch, nach der ersten Einführung mögliche Alternativen (z. B. die Verwendung von RP-Metadaten-Hashes) zu prüfen.

F: Dürfen Partner mehrere aktive Zertifikate gleichzeitig haben?

A: Ja, die Konfiguration unterstützt eine beliebige Anzahl aktiver Zertifikate pro RP oder Aggregator. Das ist nützlich für Partner, die unter verschiedenen Unternehmensnamen tätig sind.

F: Wie sollte der Distinguished Name (Subject) formatiert sein?

A: Der Distinguished Name muss pro Partner global eindeutig sein. Diese dient als statische Kennung, mit der Google eingehende Partneranfragen überwacht und das Vertrauen in das Ökosystem sicherstellt.

F: Wie funktioniert die Domainbindung? Müssen Ursprünge in das Zertifikat eingebettet werden?

A: Domains müssen nicht direkt in das Zertifikat eingebettet sein. Stattdessen wird die Domainbestätigung über den Parameter „expectedOrigins“ im API-Aufruf durchgeführt. Außerdem können mehrere Domains nahtlos mit einem einzigen Zertifikat verknüpft werden. Bei unsignierten Anfragen wird die Bindung mithilfe des Domain- oder App-Paketnamens zusammen mit einem Fingerabdruck ausgeführt.

F: Können die Details des Aggregators in der Benutzeroberfläche für die Überprüfung bei einer White-Label-Lösung weggelassen werden?

A: Ja, Informationen zum Aggregator (z. B. Name, Logo, URL und Datenschutzerklärung) sind in den Prüfer-Metadaten völlig optional. Dies ermöglicht eine vollständige White-Label-Lösung, bei der dem Nutzer nur die Details der endgültigen vertrauenden Seite angezeigt werden.

F: Was müssen wir bereitstellen, um mit dem Testen in der Sandbox-Umgebung zu beginnen?

A: Aus technischer Sicht müssen Sie nur Ihr Sandbox-Root-Zertifikat bereitstellen. Die Sandbox ist so konzipiert, dass sie die Produktionsumgebung identisch widerspiegelt.

F: Wie unterscheidet sich der Onboarding-Prozess für Prüfer-Registrare (Aggregatoren) von dem für direkte RPs?

A: Für Aggregatoren gilt ein leicht abgewandeltes Verfahren. Nachdem Sie die spezifischen Nutzungsbedingungen für Prüfer-Registrare akzeptiert haben, wird die Aufnahme in zwei Teile aufgeteilt: ein primäres Formular, um Ihren Status als Prüfer-Registrar festzulegen, gefolgt von einem optimierten Formular, das für jeden einzelnen RP erforderlich ist, den Sie aufnehmen. Für jede Einreichung ist in der Regel eine Videoaufzeichnung der Integration erforderlich. Die Überprüfung dauert normalerweise 2–3 Arbeitstage.

F: Können wir Kunden aufnehmen, die als Vermittler agieren oder Überprüfungsdienste an andere Unternehmen weiterverkaufen möchten?

A: Nein. Google arbeitet derzeit bevorzugt direkt mit Verifier Registrars (Aggregatoren) und deren direkten End-RPs zusammen, anstatt verschachtelte Reseller- oder Zwischenhändlermodelle zu unterstützen.

Technische Integration und API

F: Was ist das zugrunde liegende Protokoll für Anfragen? Welche Versionen werden unterstützt?

A: Das primäre Protokoll ist OpenID for Verifiable Presentations (OpenID4VP) Version 1.0.

F: Welche Anhänge der ISO 18013-7 (z.B. Anhang B, C, D) unterstützt Google für die Vorlage des mDL?

A: Google unterstützt Anhang D [derzeit im Entwurf] (OpenID4VP mit DC API).

F: Wie strukturieren wir eine API-Anfrage richtig, um mehrere Anmeldedaten in einer einzigen Nutzerpräsentation anzufordern?

A: Beide Arten von Anmeldedaten sollten in einem einzigen dcql-Abfrageobjekt in derselben JSON-Anfrage angefordert werden.

F: Können mit der API allgemeine Anmeldedaten angefordert werden, ohne dass alle möglichen Anmeldedatentypen aufgeführt werden müssen?

A: Nein.

F: Wie wird der Altersnachweis über die API abgewickelt? Können wir das genaue Geburtsdatum oder nur ein Signal „über X“ anfordern?

A: Beide werden unterstützt. Sie können birth_date, age_in_years oder ein datenschutzfreundliches „Über X“-Signal anfordern. Zero-Knowledge-Proofs (ZKPs) können auch für ein Wahr/Falsch-Signal verwendet werden.

F: Welche Anforderungen gelten für unsere PKI-Infrastruktur?

A: RPs benötigen eine PKI, um Anfragen zu signieren. Prüfer-Registrare fungieren als ihre eigene Zertifizierungsstelle.

F: Können wir unsere eigenen vorhandenen Zertifikate verwenden oder müssen wir ein neues von Google signiertes Zertifikat anfordern?

A: RPs benötigen ein neues Zertifikat, das von Google oder einem Verifier Registrar signiert wurde. Bei Prüfer-Registraren vertraut Google Ihrem Root-Zertifikat, wenn Sie die Schritte unter „Vertrauensaufbau“ in der Dokumentation ausführen.

A: Die gesamte Anfrage sollte serverseitig generiert werden. Verwenden Sie unter Android die Credman API und im Web die Digital Credentials (DC) API.

F: Welche Tools für Debugging, Logging und Beobachtbarkeit sind für Entwickler verfügbar?

A: Partner können den Support-Alias wallet-identity-rp-support@google.com verwenden. Es werden keine speziellen Logging- oder Beobachtbarkeitstools bereitgestellt.

Anmeldedaten und Daten

F: Welche digitalen Ausweise, Aussteller und Berechtigungsnachweise werden in den einzelnen Ländern und Regionen unterstützt?

A: Eine Liste der unterstützten Regionen finden Sie unter Unterstützte Aussteller und Zertifikate.

F: Wann planen Sie, Berechtigungsnachweise aus neuen Ländern oder Regionen zu unterstützen?

A: Wir fügen ständig neue Regionen hinzu. Auf der Seite mit den unterstützten Ausstellern finden Sie aktuelle Informationen.

F: Erhält der Endnutzer eine Benachrichtigung, wenn ein Ausweis vom Aussteller aktualisiert wird?

A: Ja, der Nutzer wird benachrichtigt und das Update wird automatisch angewendet.

Tests und Umgebungen

F: Wie erhalten wir Zugriff auf eine Sandbox-Umgebung, um den gesamten End-to-End-Ablauf zu testen?

A: Die Sandbox ist unter Sandbox-Modus verfügbar.

F: Wie können Partner, die nicht in einer Region ansässig sind, in der die Funktion offiziell eingeführt wurde, auf die Zulassungsliste für Tests gesetzt werden?

A: Senden Sie die Gmail-IDs der Test-Wallets per E-Mail an wallet-identity-rp-support@google.com.

F: Wie kann ich eine Testwebsite oder -app für Demozwecke aktivieren, damit sie von allen mit Produktionsanmeldedaten präsentiert werden kann?

A: Partner müssen das standardmäßige RP-Onboarding durchlaufen, einschließlich einer Videodemonstration in der Sandbox.

User Experience (UX)

F: Was passiert, wenn ein Nutzer keinen digitalen Ausweis hat oder die Google Wallet App nicht installiert ist, wenn er einen Bestätigungsvorgang startet?

Nutzer ohne die App werden zum Google Play Store weitergeleitet. Nutzer ohne ID können eine ID im Ablauf über die Benutzeroberfläche auf dem halben Bildschirm erstellen.

F: Können wir programmatisch erkennen, ob ein Nutzer einen digitalen amtlichen Ausweis in seinem Wallet hat, bevor wir ihm die Bestätigungsoption anzeigen?

A: Nein, die API muss vom Nutzer aufgerufen werden, um die Privatsphäre zu schützen.

F: Können wir vom Nutzer verlangen, dass er sein Gerät mit einem biometrischen Verfahren entsperrt, bevor ein Ausweis vorgelegt wird?

A: Die Nutzerauthentifizierung (biometrisch, PIN oder Muster) ist standardmäßig erforderlich und kann nicht deaktiviert werden.

A: Nein, Google Wallet sortiert sie alphabetisch.

Sicherheit und Compliance

F: Unser Anwendungsfall beinhaltet die Weitergabe von Nutzerdaten an Dritte. Ist das gemäß den Nutzungsbedingungen zulässig?

A: Ja, es können Einschränkungen gelten. Weitere Informationen finden Sie in unseren Nutzungsbedingungen.

F: Welche Dokumentation ist zur Sicherheit, Zuverlässigkeit und Barrierefreiheit der Lösungen für digitale Identitäten für unsere Compliance-Zwecke verfügbar?

A: Partner können sich auf die Sicherheitsüberprüfungen von Trail of Bits beziehen.

Erweiterte Funktionen und Roadmap

F: Welche Möglichkeiten bieten Zero-Knowledge-Proofs (ZKP) für den datenschutzfreundlichen Altersnachweis?

A: Ein Zero-Knowledge-Proof (ZKP) ist eine kryptografische Methode, mit der eine Person (der Prüfling) einem Prüfer nachweisen kann, dass sie über bestimmte Identitätsinformationen verfügt oder ein bestimmtes Kriterium erfüllt (z.B. über 18 Jahre alt ist oder einen gültigen Berechtigungsnachweis besitzt), ohne die zugrunde liegenden Daten selbst offenzulegen.

F: Wie werden verschiedene Versionen der ZK-Schaltkreise gehandhabt?

A: Die vertrauenden Seiten müssen ZK-Prüfdienste implementieren, um die neuesten verfügbaren Schaltkreise anzufordern.

F: Wie funktioniert die Freigabe und Verwaltung von Anmeldedaten auf mehreren Geräten, z. B. einem Smartphone und einem Wearable?

A: Anmeldedaten werden für ein einzelnes Gerät bereitgestellt und können nicht freigegeben werden.

Sonstiges

F: Wie geht Google mit dem Widerruf von digitalen Identitätsnachweisen um, wenn ein Reisepass widerrufen wird?

A: Nutzer können Karten/Tickets in den Google-Kontoeinstellungen löschen. Verlorene Geräte können gemeldet werden, um die Anmeldedaten zu widerrufen.

F: Wie wird der Widerruf von mDLs gehandhabt? Werden die Daten in Echtzeit angezeigt?

A: Sie kann vom Nutzer ausgelöst oder vom Aussteller (DMV) per Push-Benachrichtigung gesendet werden. Die Überprüfung erfolgt in Echtzeit, wenn das Gerät online ist. Andernfalls laufen die kurzlebigen Sicherheitsobjekte (MSOs) ab.

F: Wie lautet die Schlüsselrotationsrichtlinie für RPs?

A: Eine jährliche Rotation wird empfohlen.

F: Welche Android-Version ist mindestens erforderlich, um die Digital Credentials API zu verwenden?

A: Android 9 (API-Level 28) und höher.

F: Welche Chrome-Version ist mindestens erforderlich, um die Digital Credentials API zu unterstützen?

A: Chrome-Version 128 und höher.

F: Welche Browser unterstützen die Digital Credentials API?

A: Details zur Browserunterstützung finden Sie hier: https://digitalcredentials.dev/ecosystem-support

F: Welche Nutzer können einen Ausweis hinzufügen, wenn ein neues Land eingeführt wird?

A: Der Zugriff richtet sich nach der Ländereinstellung des Nutzers im Google Play Store.

F: Funktioniert die Digital Credentials API mit iOS?

A: Ja, die API funktioniert mit unterstützten Browsern wie Safari. OpenID4VP wird jedoch nicht von Apple unterstützt.