Domande frequenti su identità e credenziali digitali

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

Onboarding e primi passi

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

R: Consulta i passaggi riportati in Accettare documenti di identità da Wallet online.

D: Qual è la durata tipica della procedura di onboarding di 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 RP e la documentazione ufficiale per gli sviluppatori?

A:

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

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 documento d'identità digitale. Gli URL e i link ai criteri possono essere visualizzati anche 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 registrar del verificatore e come funziona?

R: Il registrar del verificatore funge da autorità di certificazione che integra i client downstream (RP finali). L'RP finale non interagisce direttamente con Google Wallet.

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

R: Consulta i passaggi riportati nella guida per i registrar di verifica.

D: In che cosa differisce da un'integrazione RP diretta?

R: I registrar verificatori gestiscono la relazione di fiducia per i propri clienti e gestiscono l'integrazione con Google Wallet per loro conto, mentre i RP diretti gestiscono la propria configurazione con Google.

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

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

D: Come avviene il flusso di dati tra la RP finale, il registrar del verificatore e Google Wallet?

R: Il registrar del verificatore invia la richiesta API a Google Wallet per l'RP finale. Google Wallet restituisce i dati delle credenziali criptati al registrar del verificatore, che li elabora e invia il segnale finale alla RP finale.

R. No. Il registrante verificatore può scegliere di non mostrare i propri dettagli.

D: Quali sono i tipi di chiavi e le curve consentiti per le CA radice 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 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 validità di 10 anni è perfettamente accettabile per un certificato CA radice. I certificati foglia End-RP devono generalmente seguire una tempistica di rinnovo di circa un anno per garantire che possano essere ruotati in modo efficiente in caso di problemi.

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

R: Sì. Per il periodo di lancio iniziale, gli aggregatori devono gestire certificati separati per ogni RP downstream. Ciò consente configurazioni di visualizzazione per RP e un monitoraggio accurato degli abusi. Sebbene ciò aumenti il sovraccarico operativo su larga scala, intendiamo rivedere le potenziali alternative (come l'utilizzo degli 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 commerciali.

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

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 entrata e garantire l'affidabilità dell'ecosistema.

D: Come funziona il binding del dominio? Le origini devono essere incorporate nel certificato?

R: I domini non devono essere incorporati direttamente nel certificato. La verifica del dominio viene invece eseguita utilizzando il parametro expected origins all'interno della chiamata API. Inoltre, più domini possono essere associati senza problemi a un singolo certificato. Per le richieste non firmate, il binding viene eseguito utilizzando il nome del pacchetto di dominio o del pacchetto applicativo insieme a un'impronta.

D: I dettagli dell'aggregatore possono essere omessi dall'interfaccia utente 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 si ottiene una soluzione completamente white label in cui all'utente vengono mostrati solo i dettagli del RP finale.

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

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

D: In che modo la procedura di onboarding è diversa per i registrar di verifica (aggregatori) rispetto ai RP diretti?

R: Gli aggregatori sono soggetti a una procedura leggermente modificata. Dopo l'esecuzione dei Termini di servizio specifici per i registranti verificatori, l'inserimento viene suddiviso in due parti: un modulo principale per stabilire il tuo stato di registrante verificatore, seguito da un modulo semplificato richiesto per ogni RP che inserisci. In genere, ogni invio di RP richiede una registrazione video dell'integrazione e la procedura di revisione richiede 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. Il modello e la preferenza attuali di Google sono di collaborare direttamente con i registrar dei verificatori (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. allegati B, C, D) sono supportati da Google per la presentazione di mDL?

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

D: Come strutturiamo correttamente una richiesta API per richiedere più credenziali in una singola presentazione utente?

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

D: L'API consente di richiedere una credenziale generica senza elencare ogni possibile tipo di credenziale?

R: No.

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

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

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

R: I RP hanno bisogno di una PKI per firmare le richieste. I registrar di verifica fungono da CA.

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

R: I RP hanno bisogno di un nuovo certificato firmato da Google o da un registrar verificatore. Per i registrar di verifica, Google considererà attendibile il tuo certificato radice se segui i passaggi di "Stabilimento dell'attendibilità" nella 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 di logging o osservabilità specifici.

Credenziali e dati

D: Quali documenti di identità digitali, emittenti e credenziali sono supportati per paese e regione?

R. Trova le regioni supportate qui: Emittenti e certificati supportati.

D: Quando prevedete di supportare le credenziali di nuovi paesi o regioni?

R. Stiamo aggiungendo attivamente nuove regioni. Controlla la pagina delle società emittenti supportate 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.

D: Quali dati delle credenziali, se presenti, vengono memorizzati da Google sui suoi server, in particolare nel contesto del GDPR?

R. Google non salva i dati relativi alle credenziali sui suoi server. Questi vengono archiviati localmente e in modo sicuro sul dispositivo dell'utente.

Test e ambienti

D: Come possiamo accedere a un ambiente sandbox per testare il flusso end-to-end completo?

R: La sandbox è aperta in Modalità sandbox.

D: Qual è la procedura per aggiungere all'allowlist per i test i partner non con sede in una regione in cui è stato eseguito il lancio ufficiale?

R: Invia per email gli ID Gmail dei wallet di test a 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 disponga di una credenziale di produzione di presentarla?

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

User Experience (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. Chi non ha un ID può crearne uno in-flow utilizzando l'interfaccia utente a metà schermo.

D: Possiamo rilevare a livello di programmazione se un utente ha un documento d'identità digitale in 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 una biometria 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 ai sensi dei Termini di servizio?

R: Sì, potrebbero essere applicate limitazioni. Per ulteriori dettagli, consulta i nostri Termini di servizio.

D: Quale documentazione è disponibile in merito a sicurezza, affidabilità e accessibilità delle soluzioni di identità digitale ai fini della conformità?

R: I partner possono fare riferimento alle revisioni della sicurezza di Trail of Bits.

Funzionalità avanzate e roadmap

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

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

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

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

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

R: Le credenziali vengono sottoposte a provisioning su un singolo dispositivo e non possono essere condivise.

Altro

D: Come gestisce Google le revoche delle tessere ID se un passaporto viene revocato?

R: Gli utenti possono eliminare le tessere dalle impostazioni dell'Account Google; i dispositivi smarriti possono essere segnalati per revocare le credenziali.

D: Come viene gestita la revoca della mDL? È in tempo reale?

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

D: Quali sono le norme di rotazione delle chiavi per i fornitori di servizi di pagamento?

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 del browser qui: https://digitalcredentials.dev/ecosystem-support

D: Quali utenti avranno la possibilità di 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 con browser supportati come Safari. Tuttavia, OpenID4VP non è supportato da Apple.