Domande frequenti su identità e credenziali digitali

Questa pagina risponde alle domande frequenti sull'integrazione con Google Wallet per l'identità e le credenziali digitali.

Onboarding e introduzione

D: Qual è la procedura passo passo per l'onboarding di un nuovo partner come componente di supporto (RP)?

R: Segui la guida passo passo disponibile alla pagina Scegli il tuo percorso.

D: Qual è la durata tipica della procedura di onboarding per i RP?

R: In genere, l'onboarding richiede 3-5 giorni lavorativi.

D: Come possiamo monitorare lo stato della nostra richiesta di Relying Party (RP) dopo l'invio?

R: Se non ricevi una risposta dopo 5 giorni, contatta il nostro team di assistenza all'indirizzo wallet-identity-rp-support@google.com.

D: Dove possiamo trovare il modulo di onboarding per RP e la documentazione per lo sviluppo ufficiale?

A:

D: In che modo le informazioni che forniamo (come il nome e il logo del prodotto) verranno utilizzate nell'esperienza del prodotto?

R: Il nome e il logo del prodotto vengono visualizzati nella schermata per il consenso rivolta agli utenti per aiutarli a identificare la Relying Party che richiede il loro ID digitale. Anche gli URL e i link alle norme possono essere inclusi nell'esperienza del prodotto.

D: Dobbiamo firmare i Termini di servizio se prevediamo di utilizzare l'ambiente sandbox solo per lo sviluppo e i test?

R: No, l'accettazione dei Termini di servizio non è un passaggio obbligatorio per i test.

D: Dove possiamo trovare un'implementazione di riferimento, un codice campione o un'applicazione demo per iniziare?

A:

Registrar di verifica

D: Che cos'è il Verifier Registrar e come funziona?

R: Il Verifier Registrar funge da autorità di certificazione che esegue l'onboarding dei client downstream (RP finali). La RP finale non interagisce direttamente con Google Wallet.

D: Qual è la procedura di onboarding specifica per un registrar di verificatori e i suoi clienti downstream?

R: Consulta i passaggi descritti nella guida per il registrar del verificatore.

D: In che modo si differenzia da un'integrazione RP diretta?

R: I registrar dei verificatori gestiscono la relazione di attendibilità per i loro clienti e si occupano dell'integrazione con Google Wallet per loro conto, mentre le RP dirette gestiscono la propria configurazione con Google.

D: Nel Verifier Registrar, chi viene inserito nella lista consentita nella configurazione di Google: il Verifier Registrar, l'RP finale o entrambi?

R: Google inserisce nella lista consentita il certificato CA radice del registrar del verificatore. Il Verifier Registrar emette quindi nuovi certificati foglia per ogni RP finale downstream.

D: Come avviene il flusso di dati tra la RP finale, il registro dei verificatori e Google Wallet?

R: Il Verifier Registrar invia la richiesta API a Google Wallet per l'End RP. Google Wallet restituisce i dati delle credenziali criptati al Verifier Registrar, che li elabora e invia l'indicatore finale all'RP finale.

R: No. Il registrar del verificatore può scegliere di non mostrare i propri dettagli.

D: Quali sono i tipi di chiavi e le curve consentiti per le CA principali e i certificati RP?

R: I certificati devono essere generati utilizzando P-256/ECDSA.

D: Possiamo utilizzare certificati di firma intermedi tra la nostra CA radice e i certificati foglia RP?

R: Sì. Puoi archiviare in modo sicuro un certificato radice di lunga durata (ad esempio in un HSM) per firmare raramente i certificati intermedi operativi. Questi certificati intermedi possono poi essere utilizzati per firmare i certificati foglia degli RP finali, consentendo una rotazione più semplice in caso di violazione senza influire sulla radice.

D: Qual è la durata richiesta per i certificati?

R: Una durata di 10 anni è perfettamente accettabile per un certificato CA radice. In genere, i certificati foglia degli RP finali devono seguire una sequenza temporale di rinnovo di circa 1 anno per garantire che possano essere ruotati in modo efficiente in caso di problemi.

D: Dobbiamo gestire un certificato foglia separato per ogni singolo cliente Relying Party (RP)?

R: Sì. Per il periodo di lancio iniziale, gli aggregatori devono gestire certificati separati per ogni RP downstream. In questo modo è possibile configurare la visualizzazione per RP e monitorare con precisione gli abusi. Sebbene ciò aggiunga un overhead operativo su larga scala, intendiamo rivedere le potenziali alternative (come l'utilizzo di hash dei metadati RP) dopo l'implementazione iniziale.

D: I partner possono avere più certificati attivi contemporaneamente?

R: Sì, la configurazione supporta un numero qualsiasi di certificati attivi per RP o aggregatore, il che è utile per i partner che operano con vari nomi di attività.

D: Come deve essere formattato il nome distinto (oggetto)?

R: Il nome distinto deve essere univoco a livello globale per partner. Questo funge da identificatore statico che Google utilizza per monitorare le richieste dei partner in arrivo e garantire la fiducia nell'ecosistema.

D: Come funziona l'associazione dei domini? Le origini devono essere incorporate nel certificato?

R: Non è necessario che i domini siano incorporati direttamente nel certificato. La verifica del dominio viene invece eseguita utilizzando il parametro delle origini previste all'interno della chiamata API. Inoltre, è possibile associare facilmente più domini a un singolo certificato. Per le richieste non firmate, l'associazione viene eseguita utilizzando il nome del dominio o del pacchetto applicativo insieme a un'impronta.

D: I dettagli dell'aggregatore possono essere omessi dalla UI di verifica per un'esperienza white label?

R: Sì, le informazioni sull'aggregatore (come nome, logo, URL e norme sulla privacy) sono completamente facoltative nei metadati del verificatore. In questo modo, è possibile ottenere una soluzione completamente white label in cui all'utente vengono mostrati solo i dettagli della RP finale.

D: Cosa dobbiamo fornire per iniziare i test nell'ambiente sandbox?

R: Dal punto di vista tecnico, devi solo fornire il certificato principale della sandbox. La sandbox è progettata per rispecchiare in modo identico l'ambiente di produzione.

R: In che modo la procedura di onboarding per i registrar di verificatori (aggregatori) differisce da quella per le RP dirette?

R: Gli aggregatori seguono una procedura leggermente diversa. Dopo aver accettato i Termini di servizio specifici per i Verifier Registrar, l'onboarding viene suddiviso in due parti: un modulo principale per stabilire il tuo stato di Verifier Registrar, seguito da un modulo semplificato richiesto per ogni singola RP di cui esegui l'onboarding. Ogni invio di RP richiede in genere una registrazione video dell'integrazione e la procedura di revisione richiede generalmente 2-3 giorni lavorativi.

D: Possiamo eseguire l'onboarding di clienti che intendono agire come intermediari o rivendere servizi di verifica ad altre entità?

R: No. L'attuale modello e la preferenza di Google è collaborare direttamente con i Verifier Registrar (aggregatori) e i loro RP finali diretti, anziché supportare modelli di rivenditori o intermediari nidificati.

Integrazione tecnica e API

D: Qual è il protocollo sottostante per le richieste? Quali versioni sono supportate?

R: Il protocollo principale è OpenID for Verifiable Presentations (OpenID4VP) versione 1.0.

D: Quali allegati ISO 18013-7 (ad es. Allegato B, C, D) supporta Google per la presentazione della patente di guida digitale?

Assistenza Google supporta l'allegato D [attualmente in bozza] (OpenID4VP che utilizza l'API DC).

D: Come si struttura correttamente una richiesta API per richiedere più credenziali in un'unica presentazione utente?

R: Entrambi i tipi di credenziali devono essere richiesti all'interno di un singolo oggetto di query dcql nella stessa richiesta JSON.

D: L'API consente di richiedere una credenziale generica senza elencare tutti i tipi di credenziali possibili?

R: No.

D: In che modo l'API gestisce la verifica dell'età? Possiamo richiedere la data di nascita esatta o solo un indicatore "maggiore di X"?

R: Sono supportati entrambi. Puoi richiedere birth_date, age_in_years o un indicatore che tutela la privacy "superiore a X". Le prove a conoscenza zero (ZKP) possono essere utilizzate anche per un indicatore vero/falso.

D: Quali sono i requisiti per la nostra infrastruttura PKI?

R: Le RP hanno bisogno di una PKI per firmare le richieste. I registrar di verifica agiscono come CA.

D: Possiamo utilizzare i nostri certificati esistenti o dobbiamo ottenerne uno nuovo firmato da Google?

R: Le RP hanno bisogno di un nuovo certificato firmato da Google o da un Verifier Registrar. Per i registrar di verificatori, Google considererà attendibile il tuo certificato radice se segui i passaggi descritti nella sezione "Trust Establishment" della documentazione.

R: L'intera richiesta deve essere generata lato server. Su Android, utilizza l'API Credman; sul web, utilizza l'API Digital Credentials (DC).

D: Quali strumenti di debug, logging e osservabilità sono disponibili per gli sviluppatori?

R: I partner possono utilizzare l'alias di assistenza wallet-identity-rp-support@google.com. Non vengono forniti strumenti specifici di logging o osservabilità.

Credenziali e dati

D: Quali ID digitali, emittenti e credenziali sono supportati per paese e regione?

R: Puoi trovare le regioni supportate qui: Emittenti e certificati supportati.

D: Quando prevedete di supportare i documenti di identità di nuovi paesi o regioni?

R: Stiamo aggiungendo attivamente nuove regioni. Controlla la pagina degli emittenti supportati per gli aggiornamenti.

D: Quando una credenziale viene aggiornata dall'emittente, l'utente finale riceve una notifica?

R: Sì, l'utente riceve una notifica e l'aggiornamento viene applicato automaticamente.

Test e ambienti

D: Come possiamo accedere a un ambiente sandbox per testare l'intero flusso end-to-end?

R: La sandbox è aperta all'indirizzo: Modalità sandbox.

D: Qual è la procedura per aggiungere alla lista consentita per i test i partner che non hanno sede in una regione in cui è stato lanciato ufficialmente il programma?

R: Invia un'email con gli ID Gmail dei wallet di test all'indirizzo wallet-identity-rp-support@google.com.

D: Qual è la procedura per attivare un sito web o un'app di test a scopo dimostrativo, consentendo a chiunque abbia una credenziale di produzione di presentarla?

R: I partner devono completare l'onboarding standard per i RP, inclusa una dimostrazione video in sandbox.

Esperienza utente (UX)

D: Qual è l'esperienza utente se un utente non ha un documento d'identità digitale o l'app Google Wallet installata quando avvia un flusso di verifica?

R: Gli utenti che non hanno l'app vengono indirizzati al Play Store. Gli utenti che non hanno un ID possono crearne uno durante il flusso utilizzando la UI a metà schermo.

D: Possiamo rilevare in modo programmatico se un utente ha un documento di identità digitale nel suo Wallet prima di mostrargli l'opzione di verifica?

R: No, l'API deve essere richiamata dall'utente per proteggere la privacy.

D: Possiamo richiedere all'utente di sbloccare il dispositivo con un dato biometrico prima di presentare una credenziale?

R: L'autenticazione utente (biometrica, PIN o sequenza) è obbligatoria per impostazione predefinita e non può essere disattivata.

R: No, Google Wallet li riordina in ordine alfabetico.

Sicurezza e conformità

D: Il nostro caso d'uso prevede la ricondivisione dei dati utente con terze parti. È consentito dai Termini di servizio?

R: Sì, potrebbero essere applicate delle restrizioni. Per maggiori dettagli, consulta i nostri Termini di servizio.

D: Quale documentazione è disponibile in merito alla sicurezza, all'affidabilità e all'accessibilità delle soluzioni di identità digitale per i nostri scopi di conformità?

R: I partner possono fare riferimento ai controlli della sicurezza di Trail of Bits.

Funzionalità avanzate e roadmap

D: Quali sono le funzionalità delle prove a conoscenza zero (ZKP) per la verifica dell'età che tutela la privacy?

R: La prova a conoscenza zero (ZKP) è un metodo crittografico che consente a un individuo (il prover) di dimostrare a un verificatore di possedere una determinata informazione di identità o di soddisfare un criterio specifico (ad esempio, avere più di 18 anni, possedere una credenziale valida) senza rivelare i dati sottostanti effettivi.

D: Come vengono gestite le diverse versioni dei circuiti ZK?

R: Le RP devono implementare i servizi di verifica ZK per richiedere i circuiti più recenti disponibili.

D: Come funzionano la condivisione e la gestione delle credenziali su più dispositivi, ad esempio uno smartphone e un wearable?

R: Le credenziali vengono fornite a un singolo dispositivo e non possono essere condivise.

Altri

D: In che modo Google gestisce le revoche dei pass ID se un passaporto viene revocato?

R: Gli utenti possono eliminare le tessere dalle impostazioni dell'Account Google. In caso di smarrimento dei dispositivi, è possibile segnalarlo per revocare le credenziali.

D: Come viene gestita la revoca della patente di guida digitale? È in tempo reale?

R: Può essere attivato dall'utente o inviato dall'emittente (DMV). È in tempo reale se il dispositivo è online; in caso contrario, gli oggetti di sicurezza di breve durata (MSO) scadranno.

D: Qual è la policy di rotazione delle chiavi per gli RP?

R: È consigliabile una rotazione annuale.

D: Qual è la versione minima di Android supportata per l'API Digital Credentials?

R: Android 9 (livello API 28) e versioni successive.

D: Qual è la versione minima di Chrome che supporta l'API Digital Credentials?

R: Chrome versione 128 e successive.

D: Quali browser supportano l'API Digital Credentials?

R: Puoi trovare i dettagli sul supporto dei browser qui: https://digitalcredentials.dev/ecosystem-support

D: Quali utenti potranno aggiungere un documento di identità quando viene lanciato un nuovo paese?

R: L'accesso si basa sull'impostazione del paese dell'utente nel Play Store.

D: L'API Digital Credentials funziona con iOS?

R: Sì, l'API funziona utilizzando browser supportati come Safari. Tuttavia, OpenID4VP non è supportato da Apple.