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

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

Onboarding und erste Schritte

F: Wie sieht der Onboarding-Prozess für einen neuen Partner als vertrauende Partei aus?

A: Folgen Sie der Anleitung unter Ausweise von Wallet online akzeptieren.

F: Wie lange dauert das Onboarding für das RP-Programm in der Regel?

A: Das Onboarding dauert in der Regel drei bis fünf Arbeitstage.

F: Wie können wir den Status unseres Antrags als vertrauende Partei nach der Einreichung verfolgen?

A: Wenn Sie nach fünf Tagen noch nichts gehört haben, wenden Sie sich bitte unter wallet-identity-rp-support@google.com an unser Supportteam.

F: Wo finden wir das RP-Onboarding-Formular 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 Zustimmungsbildschirm für Nutzer angezeigt, damit diese erkennen können, welche vertrauende Partei ihre digitale ID anfordert. URLs und Richtlinienlinks können auch in der Produktoberfläche angezeigt werden.

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

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

F: Wo finden wir eine Referenzimplementierung, Beispielcode oder eine Demoanwendung, um loszulegen?

A:

Registrare für Verifizierer

F: Was ist der Verifier Registrar und wie funktioniert er?

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

F: Wie sieht das Onboarding-Verfahren für einen Verifier Registrar und seine nachgelagerten Kunden aus?

A: Folgen Sie der Anleitung im Verifier Registrar Guide.

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

A: Verifier Registrars verwalten die Vertrauensbeziehung für ihre Kunden und kümmern sich in ihrem Namen um die Integration mit Google Wallet. Direkte RPs verwalten ihre eigene Konfiguration mit Google.

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

A: Google fügt das Root-CA-Zertifikat des Prüfer-Registrars auf die Zulassungsliste. Der Verifier Registrar stellt dann neue Blattzertifikate für jeden nachgelagerten End-RP aus.

F: Wie erfolgt der Datenfluss zwischen dem End-RP, dem Verifier Registrar und Google Wallet?

A: Der Verifier Registrar sendet die API-Anfrage für den End-RP an Google Wallet. Google Wallet gibt verschlüsselte Anmeldedaten an den Verifier-Registrar zurück, der sie verarbeitet und das endgültige Signal an den End-RP sendet.

A: Nein. Der Verifier Registrar kann 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 Zwischenzertifikate zwischen unserer Stammzertifizierungsstelle und den RP-Blattzertifikaten verwenden?

A: Ja. Sie können ein langlebiges Root-Zertifikat sicher speichern (z.B. in einem HSM), um selten operative Zwischenzertifikate zu signieren. Diese Zwischenzertifikate können dann zum Signieren von untergeordneten Zertifikaten für End-RPs verwendet werden, was eine einfachere Rotation im Falle einer Sicherheitsverletzung ermöglicht, 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 Root-CA-Zertifikat vollkommen akzeptabel. End-RP-Leaf-Zertifikate sollten in der Regel jährlich erneuert werden, damit sie bei Problemen effizient rotiert werden können.

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

A: Ja. Während des ersten Einführungszeitraums müssen Aggregatoren separate Zertifikate für jeden nachgelagerten RP verwalten. Dies ermöglicht Displaykonfigurationen pro RP und eine genaue Missbrauchserkennung. Das führt zwar zu einem erhöhten Betriebsaufwand, aber wir werden nach der ersten Einführung potenzielle Alternativen (z. B. die Verwendung von RP-Metadaten-Hashes) in Betracht ziehen.

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 muss der Distinguished Name (Antragsteller) formatiert sein?

A: Der Distinguished Name muss pro Partner global eindeutig sein. Dies dient als statische Kennung, die Google verwendet, um eingehende Partneranfragen zu überwachen und das Vertrauen in das Ökosystem zu stärken.

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

A: Domains müssen nicht direkt in das Zertifikat eingebettet werden. Stattdessen erfolgt die Domainbestätigung über den Parameter „expected origins“ im API-Aufruf. Außerdem können mehrere Domains nahtlos mit einem einzelnen Zertifikat verknüpft werden. Bei nicht signierten Anfragen wird die Bindung mit dem Domain- oder App-Paketnamen zusammen mit einem Fingerabdruck ausgeführt.

F: Können Aggregatordetails in der Verifizierungs-UI für eine White-Label-Lösung ausgelassen werden?

A: Ja, Aggregatorinformationen wie Name, Logo, URL und Datenschutzerklärung sind in den Metadaten des Prüfers optional. So kann eine vollständig als White-Label-Lösung gekennzeichnete Lösung bereitgestellt werden, bei der dem Nutzer nur die Details des End-RP 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 angeben. Die Sandbox ist so konzipiert, dass sie die Produktionsumgebung identisch widerspiegelt.

F: Wie unterscheidet sich der Onboarding-Prozess für Verifier Registrars (Aggregators) von dem für direkte RPs?

A: Für Dienstleister gilt ein leicht modifizierter Prozess. Nachdem Sie die spezifischen Nutzungsbedingungen für Verifier Registrars ausgeführt haben, wird die Aufnahme in zwei Teile unterteilt: ein primäres Formular, um Ihren Status als Verifier Registrar festzustellen, gefolgt von einem vereinfachten Formular, das für jeden einzelnen RP erforderlich ist, den Sie einbinden. Für jede Einreichung für das RP ist in der Regel eine Videoaufzeichnung der Integration erforderlich. Die Überprüfung dauert in der Regel zwei bis drei Arbeitstage.

F: Können wir Kunden registrieren, die als Vermittler fungieren oder Bestätigungsdienste an andere Unternehmen weiterverkaufen möchten?

A: Nein. Google arbeitet derzeit lieber direkt mit Verifier Registrars (Aggregatoren) und ihren direkten End-RPs zusammen, anstatt verschachtelte Reseller- oder Vermittlermodelle zu unterstützen.

Technische Integration und API

F: Welches Protokoll wird für Anfragen verwendet? Welche Versionen werden unterstützt?

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

F: Welche Anhänge von ISO 18013-7 (z.B. Anhang B, C, D) unterstützt Google für die Präsentation von mDLs?

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 Anmeldedatentypen sollten in derselben JSON-Anfrage in einem einzelnen dcql-Abfrageobjekt angefordert werden.

F: Kann mit der API eine allgemeine Anmeldedatenanfrage gestellt werden, ohne jeden möglichen Anmeldedatentyp aufzulisten?

A: Nein.

F: Wie wird die Altersüberprüfung über die API gehandhabt? 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 Signal „über X“ anfordern. Zero-Knowledge-Beweise (Zero-Knowledge Proofs, ZKPs) können auch für ein Signal vom Typ „wahr/falsch“ verwendet werden.

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

A: RPs benötigen eine PKI, um Anfragen zu signieren. Registrare für die Überprüfung fungieren als eigene Zertifizierungsstelle.

F: Können wir unsere eigenen vorhandenen Zertifikate verwenden oder benötigen wir ein neues, das von Google signiert wurde?

A: RPs benötigen ein neues Zertifikat, das von Google oder einem Verifier Registrar signiert wurde. Für Verifier Registrars vertraut Google Ihrem Root-Zertifikat, wenn Sie die Schritte unter „Trust Establishment“ (Vertrauensaufbau) in der Dokumentation ausführen.

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

F: Welche Tools für Debugging, Logging und Observability stehen Entwicklern zur Verfügung?

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

Anmeldedaten und Daten

F: Welche digitalen IDs, Aussteller und Anmeldedaten werden nach Land und Region unterstützt?

A: Hier finden Sie eine Liste der unterstützten Regionen.

F: Wann werden Anmeldedaten aus neuen Ländern oder Regionen unterstützt?

A: Wir fügen aktiv neue Regionen hinzu. Auf der Seite „Unterstützte Aussteller“ finden Sie aktuelle Informationen.

F: Erhält der Endnutzer eine Benachrichtigung, wenn Anmeldedaten vom Aussteller aktualisiert werden?

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

F: Welche Anmeldedaten speichert Google auf seinen Servern, insbesondere im Zusammenhang mit der DSGVO?

A: Google speichert keine anmeldedatenbezogenen Daten auf seinen Servern. Sie werden lokal und sicher auf dem Gerät des Nutzers gespeichert.

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 im Sandbox-Modus geöffnet.

F: Wie können Partner, die nicht in einer offiziell eingeführten Region ansässig sind, 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, sodass sie von jedem mit Produktionsanmeldedaten präsentiert werden kann?

A: Partner müssen das Standard-Onboarding für das Revenue Program durchlaufen, einschließlich einer Sandbox-Videodemonstration.

Nutzerfreundlichkeit

F: Wie sieht die Nutzererfahrung aus, wenn ein Nutzer keinen digitalen Ausweis oder die Google Wallet App installiert hat, wenn er einen Bestätigungsvorgang startet?

A: Nutzer, die die App nicht haben, werden zum Play Store weitergeleitet. Nutzer ohne ID können eine ID über die Halbseiten-Benutzeroberfläche 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 den Datenschutz zu gewährleisten.

F: Können wir den Nutzer auffordern, sein Gerät biometrisch zu entsperren, bevor wir Anmeldedaten präsentieren?

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: In unserem Anwendungsfall werden Nutzerdaten an Dritte weitergegeben. 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 in Bezug auf die Sicherheit, Zuverlässigkeit und Barrierefreiheit der digitalen Identitätslösungen für unsere Compliance-Zwecke verfügbar?

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

Erweiterte Funktionen und Roadmap

F: Welche Möglichkeiten bieten Zero-Knowledge-Beweise (ZKP) für die datenschutzfreundliche Altersüberprüfung?

A: Der Zero-Knowledge-Beweis (ZKP) ist eine kryptografische Methode, mit der eine Person (der Beweiser) einem Prüfer beweisen kann, dass sie bestimmte Identitätsinformationen besitzt oder ein bestimmtes Kriterium erfüllt (z.B. über 18 Jahre alt ist oder einen gültigen Ausweis besitzt), ohne die tatsächlichen zugrunde liegenden Daten preiszugeben.

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

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

F: Wie funktioniert das Teilen und Verwalten 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 geteilt 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 Anmeldedaten zu widerrufen.

F: Wie wird der Widerruf von mobilen Führerscheinen gehandhabt? Werden die Daten in Echtzeit aktualisiert?

A: Sie kann vom Nutzer ausgelöst oder vom Aussteller (DMV) gesendet werden. Die Sperrung erfolgt in Echtzeit, wenn das Gerät online ist. Andernfalls laufen kurzlebige Sicherheitsobjekte (Mobile Security Objects, MSOs) ab.

F: Wie lautet die Richtlinie zur Schlüsselrotation für RPs?

A: Eine jährliche Rotation wird empfohlen.

F: Welche Android-Mindestversion wird für die Digital Credentials API unterstützt?

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

F: Welche Chrome-Mindestversion unterstützt die Digital Credentials API?

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 eine ID hinzufügen, wenn ein neues Land eingeführt wird?

A: Der Zugriff richtet sich nach der Ländereinstellung des Nutzers im 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.