Offrire un'esperienza di accesso e credenziali digitali senza interruzioni su Android

Ciao,

Grazie per aver deciso di partecipare oggi.

Oggi siamo felici di parlare del futuro dell'autenticazione e dell'identità digitale.

Sono Tom Colvin.

Sono CTO di Apptaura e GDE su Android. Sono qui con Chiping Yeh, Senior Android Developer Relations Engineer di Google.

La venerabile password è morta.

O, almeno, dovrebbe esserlo.

Oggi vi parlerò di un mondo senza password.

Le password sono una vulnerabilità ben nota nella nostra infrastruttura di sicurezza.

Anche se vengono archiviate in modo sicuro, sono vulnerabili a phishing, violazioni dei server e attacchi automatici come il credential stuffing.

Come settore, abbiamo cercato di risolvere questo problema imponendo la complessità: caratteri speciali, numeri, rotazioni obbligatorie.

I dati dimostrano che questo approccio ha fallito, in parte perché più rendi difficile la creazione di una password, più, paradossalmente, incoraggi un comportamento non sicuro.

Perché una password complessa che viene modificata regolarmente è una password che probabilmente verrà scritta su un post-it.

Inoltre, anche l'autenticazione a due fattori basata su SMS si è dimostrata vulnerabile a intercettazioni come lo scambio di SIM.

Oggi, tuttavia, questo problema è stato ampiamente risolto.

Le passkey sono basate sugli standard FIDO e utilizzano la crittografia con chiavi pubbliche e private.

Sono altamente resistenti al phishing, non vengono esposte in caso di violazione del server e sono collegate direttamente alla sicurezza dello smartphone dell'utente tramite il blocco schermo, che, nella maggior parte dei casi, si basa sui nostri dati biometrici, impronte ecc. Inoltre, migliorano attivamente l'esperienza utente con un'esperienza unificata su tutte le piattaforme e senza la necessità di ricordare password complesse.

Il nostro manifesto oggi è semplice.

È arrivato il momento di passare a un mondo senza password.

E gli strumenti per farlo sono già nelle nostre mani.

Per fare questo salto su Android, abbiamo Gestore delle credenziali di Jetpack.

È supportata fino ad Android 4.4 e, con le passkey supportate da Android 9, fornisce un'unica API unificata che supporta le passkey e l'autenticazione tradizionale, come l'accesso federato, ad esempio Accedi con Google, e include un fallback graduale alle password, se necessario.

Chiami l'API Credential Manager, che gestisce l'UI per selezionare il metodo di autenticazione che l'utente vuole vedere.

Quindi, esegue il lavoro più oneroso per restituire la credenziale corretta, ottenuta in modo sicuro.

Supporta l'accesso, la registrazione e il backup delle credenziali.

Puoi utilizzarla per aggiornare ed eliminare le credenziali.

Inoltre, aiuta gli utenti a spostare le password e le passkey tra i provider di credenziali in pochi clic, senza dover scaricare file.

È progettato per offrire agli utenti il controllo completo sui propri dati e la libertà di cambiare provider ogni volta che ne hanno bisogno.

Inoltre, Gestore delle credenziali supporta molti fattori di forma, tra cui smartwatch, TV, XR, auto, smartphone, pieghevoli e tablet.

E, cosa più importante per noi, ha un flusso dedicato per le passkey.

Ecco cosa vede l'utente durante la registrazione.

La mia app comunica a Gestore delle credenziali che l'autenticazione tramite passkey è disponibile e fornisce i dettagli raccolti dal backend.

Tocchi Registrati e Gestore delle credenziali ti mostra un riquadro inferiore con un prompt di blocco schermo.

In genere, si sblocca con la biometria, ad esempio con l'impronta o la scansione del volto.

Gestore delle credenziali si occupa poi del complesso lavoro di crittografia, come la creazione effettiva della passkey.

La passkey viene salvata nel mio gestore delle credenziali, che in questo caso è il Gestore delle password di Google, ma potrebbe essere un altro.

Ecco come si presenta il codice.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

Innanzitutto, creiamo questo oggetto createPublicKeyCredentialRequest utilizzando i dettagli forniti dal backend, ovvero questo registerRequestJson.

Quindi, chiamiamo il metodo magico credentialManager.createCredential.

Passiamo la richiesta e il Local Context, che consente di mostrare l'UI.

Tieni presente che non ho dovuto scrivere alcun codice UI.

Gestore delle credenziali se ne occupa interamente per noi.

Questa è la procedura di accesso.

Per l'utente, è molto simile alla procedura di registrazione.

Basta un solo prompt di sblocco e il gioco è fatto.

Per gli sviluppatori, la situazione è leggermente diversa.

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

Innanzitutto, recuperiamo i dettagli dell'accesso dal backend per creare un'istanza GetPublicKeyCredential.

Comunichiamo a Gestore delle credenziali i tipi di credenziali che supportiamo.

In questo caso, si tratta solo di passkey.

Tuttavia, se vogliamo, possiamo aggiungere anche altri tipi di credenziali.

Poi chiamiamo credentialManager.getCredential passando l'elenco di credenziali che abbiamo appena richiesto.

Anche in questo caso, non è necessario scrivere codice per la UI.

Non è necessario scrivere codice per la UI.

Gestore delle credenziali se ne occupa completamente per noi.

Spinge l'utente verso l'opzione utilizzata più di frequente, lasciando le altre disponibili come backup.

In questo modo, uno dei problemi di autenticazione più fastidiosi di oggi viene risolto automaticamente.

Hai notato?

ovvero memorizza l'ultimo metodo utilizzato per accedere.

Ecco la risposta, presentata in modo chiaro in un riquadro inferiore.

Tra l'altro, questo non è solo un fastidio per l'utente.

È un vero e proprio punto di attrito.

Questo causa recuperi dell'account non necessari e ha un impatto commerciale, come i carrelli degli acquisti abbandonati.

Ecco il codice della mia applicazione demo, che puoi utilizzare per provare Gestore delle credenziali.

Puoi visualizzare questi flussi sul tuo dispositivo.

A sinistra sono presenti gli esempi di codice ufficiali di Google.

che gestisce la creazione delle passkey.

E per quanto riguarda l'upgrade degli utenti esistenti con password alle passkey?

Uno strumento efficace per farlo è la creazione condizionale.

Se l'utente ha appena eseguito l'accesso utilizzando la password, che è stata compilata automaticamente da un provider di credenziali supportato, sappiamo che è attivamente coinvolto e abbiamo appena verificato la sua identità.

In questo caso, la creazione condizionale ci consente di richiedere la creazione di una passkey automaticamente in background.

Non interrompe il flusso di lavoro dell'utente.

La passkey viene generata automaticamente e memorizzata.

Il Gestore delle password di Google mostra una notifica per confermare l'avvenuta operazione.

Altri gestori delle password potrebbero comportarsi diversamente.

Il codice per la creazione condizionale è molto simile a quello per la registrazione.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

Il flag magico è isConditional true, il che garantisce che l'utente non veda la UI.

E poiché funziona in modo opportunistico, lo inseriremo in un blocco try-catch.

Gestiremo gli eventuali errori in modo silenzioso, così non disturberemo l'utente se il processo non va a buon fine.

La passkey viene quindi salvata nel Gestore delle credenziali dell'utente, dove sarà disponibile per l'utilizzo successivo.

Gestore delle credenziali consente inoltre ai provider di credenziali di importare ed esportare le proprie credenziali in modo sicuro.

Bastano pochi clic.

Non è necessario eseguire alcun download.

Questo offre una maggiore flessibilità, mantenendo al contempo le informazioni al sicuro.

Il flusso è il seguente.

Nel nuovo provider di credenziali, l'utente richiede di importare le credenziali.

A questo punto, Gestore delle credenziali gestisce la UI di importazione, consentendo all'utente di selezionare l'origine dei dati delle credenziali.

Il provider di credenziali di esportazione può quindi fornire la propria UI, che consente di informare l'utente e fornire gli avvisi pertinenti.

Infine, il nuovo provider di credenziali dell'utente riceve i dati tramite un canale sicuro.

In questo modo, è in grado di importarlo senza alcuna interazione da parte dell'utente.

Ma cosa succede se l'utente revoca una passkey dalla sua app o dal suo sito web?

In questo caso, il provider di credenziali non sa necessariamente che ciò è avvenuto.

La prossima volta che tenteranno di accedere, Gestore delle credenziali offrirà la passkey non valida e il tentativo verrà rifiutato.

Allo stesso modo, quando un utente aggiorna il proprio nome utente o nome visualizzato, è necessaria una sincronizzazione.

Ora, con l'API Signal, la tua app può segnalare questi stati specifici al provider di credenziali.

Prendiamo ad esempio il caso dell'accesso con una password revocata.

La tua app può rilevare questo stato di errore specifico e utilizzarlo per informare il provider di credenziali dell'utente.

Il provider di credenziali può quindi aggiornarsi in modo che quella passkey specifica non venga offerta.

Queste sono alcune delle funzionalità di Gestore delle credenziali, che è incredibilmente utile per consentire agli utenti di registrarsi utilizzando le passkey e per dare priorità alle passkey rispetto ad altri metodi durante l'accesso.

Ma ricorda che il nostro obiettivo finale è eliminare completamente le password.

In che modo Gestore delle credenziali aiuta a raggiungere questo obiettivo?

Ecco la nostra proposta di processo in cinque passaggi.

Nei primi due passaggi, esegui l'upgrade degli utenti con password alle passkey.

Innanzitutto, proviamo in modo opportunistico, utilizzando la creazione condizionale.

Se questa opportunità non si presenta, alla fine avremo bisogno dell'intervento dell'utente, quindi di inviti in-app che chiedono agli utenti di configurare la passkey.

Possiamo iniziare gradualmente a mostrare questi elementi in modo sempre più evidente.

Dopotutto, dal punto di vista dell'utente, di solito è sufficiente fornire il blocco schermo, ad esempio la biometria.

Una volta che i dati di analisi mostrano che la stragrande maggioranza dei tuoi utenti ha account che utilizzano le passkey, queste possono essere rese obbligatorie per tutti i nuovi utenti.

Ma questi utenti precedenti sono quelli con cui abbiamo a che fare in questi ultimi tre passaggi.

Incoraggiamo gli utenti di passkey a rimuovere le proprie password.

Pertanto, nel passaggio 3, consentiamo loro di farlo manualmente, con un'opzione Elimina password molto chiara nelle impostazioni dell'account.

Nel passaggio 4, iniziamo a promuovere l'eliminazione delle password, utilizzando, ad esempio, notifiche in-app, abbinate a un testo informativo.

Infine, l'eliminazione delle password passa da opt-in a disattivazione.

Alla fine, anche quest'ultima opzione di disattivazione potrebbe scomparire.

Analytics ci darà la certezza di poter rimuovere completamente i flussi di password dall'app.

Pertanto, il passaggio a un mondo senza password non è più un concetto di sicurezza teorico per un futuro indefinito.

È ampiamente supportato.

Le API sono solide e l'esperienza utente è eccellente.

Ti invito a iniziare a integrare i flussi delle passkey con Gestore delle credenziali oggi stesso.

Inizia a eseguire l'upgrade dei tuoi utenti e lasciamo finalmente le password nel passato.

Grazie.

Ora vorrei passare la parola a Chiping, che parlerà della prossima evoluzione della migrazione e dell'identità dei dispositivi.

Perfetto.

Va bene, grazie, Tom.

Come ha sottolineato Tom, l'autenticazione senza interruzioni sui dispositivi degli utenti è fondamentale.

Ma cosa succede quando un utente acquista un nuovo smartphone?

Oggi, il calo maggiore nel percorso dell'utente si verifica spesso quando cambia dispositivo.

Oggi voglio innanzitutto parlare di come stiamo risolvendo questo problema e illustrare rapidamente un requisito del Play Store in arrivo relativo al ripristino delle credenziali.

A partire da aprile 2027, Google Play richiederà alle app di soddisfare i requisiti di accesso zero-tap per mantenere le funzionalità di pubblicazione complete e una visibilità ottimale nel Play Store.

Che cos'è l'accesso zero-tap?

In pratica, ciò significa che gli utenti non devono eseguire nuovamente l'autenticazione manuale nella tua app quando passano a un nuovo dispositivo.

Come si implementa?

Il metodo principale che consigliamo per farlo è tramite l'API Restore Credentials di Android tramite Gestore delle credenziali.

Questa API ti consente di generare una cosiddetta chiave di ripristino, che viene salvata sul dispositivo dell'utente o nel cloud in base alle impostazioni di backup dell'utente.

Ti consigliamo di generare questa chiave in background una volta che l'utente ha eseguito l'accesso.

In questo diagramma, illustriamo un utente che accede all'app.

In seguito, la chiave di ripristino viene creata mentre l'utente utilizza l'app.

Questa chiave viene poi archiviata localmente o, se abilitata, da remoto nel cloud.

Quando l'utente configura il nuovo dispositivo, la credenziale di ripristino viene trasferita in modo invisibile in background durante la procedura di configurazione del dispositivo.

Gli utenti possono scegliere di ripristinare i dati dal cloud o tramite trasferimento da dispositivo a dispositivo.

In seguito, quando l'app viene aperta, puoi chiamare l'API Credential Manager per utilizzare questa chiave di ripristino per far accedere l'utente sul nuovo dispositivo al primo avvio.

In questo modo, l'utente può accedere alla tua app in modo rapido e sicuro.

Se vuoi che la tua app venga ripristinata immediatamente dopo la configurazione senza essere aperta, puoi implementare un agente di backup personalizzato per farlo.

In questo modo, l'utente potrà accedere alla tua app senza aprirla manualmente.

Alcuni dei nostri partner hanno già implementato questa funzionalità nella loro app.

Uber è la più grande azienda di ride sharing al mondo, che fornisce trasporti a milioni di persone e supporta anche la consegna di cibo, il trasporto sanitario e la logistica delle merci.

La semplicità di accesso è fondamentale.

Inoltre, quando gli utenti passano a un nuovo dispositivo, si aspettano una transizione fluida senza dover accedere nuovamente all'app Uber o eseguire ogni volta l'autenticazione una tantum tramite SMS.

Questo frequente ricambio di dispositivi rappresenta una sfida per la fidelizzazione degli utenti.

In seguito a una valutazione della domanda degli utenti e alla prototipazione del codice, Uber ha introdotto il supporto di Restore Credentials nell'app Uber Rider e i risultati sono stati molto positivi.

Si stima che ciò consentirà di risparmiare 4 milioni di accessi giornalieri medi al giorno e si prevede che questo numero aumenterà con l'adozione.

Consulta questo codice QR e questo link per scoprire di più su queste norme imminenti e su come la tua app può soddisfare i requisiti di ripristino zero-tap.

Anche in questo caso, la modifica verrà introdotta ad aprile 2027, quindi assicurati di segnare questa data sul calendario.

Se vuoi iniziare a implementare Restore Credentials nella tua app, scansiona questo codice QR e visita il link per accedere alla nostra skill Restore Credentials.

Questa skill può essere utilizzata per sviluppare o testare rapidamente la funzionalità con l'agente che preferisci.

Ora guardiamo alla prossima frontiera dell'identità digitale: l'API Digital Credentials tramite Gestore delle credenziali.

Vediamo cosa sono le credenziali digitali e come funzionano.

Le credenziali digitali sono documenti digitali verificabili tramite crittografia che gli utenti possono utilizzare per fornire informazioni su di sé.

Questi documenti vengono archiviati all'interno di contenitori digitali sul dispositivo di un utente e possono essere richiesti da altre app sul dispositivo o presentati al mondo in modo ibrido, ad esempio tramite un codice QR.

Gli utilizzi sono ampi e variegati, dalla verifica dell'identità all'accesso ai servizi fino all'acquisto di articoli online.

Le credenziali digitali offrono un modo sicuro e pratico per condividere informazioni senza bisogno di carte fisiche.

Le credenziali digitali coinvolgono tre parti: l'emittente, il titolare e il verificatore.

La vita di una credenziale digitale generalmente si sviluppa da sinistra a destra.

Esaminiamo ciascuna di queste entità e il ruolo che svolgono.

Il primo è l'emittente, che, come suggerisce il nome, è una parte che emette una credenziale, proprio come il governo emette il tuo passaporto.

Tuttavia, nel mondo digitale, per impedire lo spoofing, queste credenziali vengono firmate anche dall'emittente con il suo certificato digitale, in modo che chiunque riceva la credenziale possa sapere esattamente da chi proviene.

In realtà, chiunque può essere un emittente, che si tratti di una palestra, di un hotel o anche di te.

Devi solo creare una credenziale e firmarla.

Ok, quindi l'emittente crea ed emette le credenziali, ma queste devono essere archiviate da qualche parte, proprio come devi conservare il tuo documento di identità ufficiale nel tuo portafoglio.

Si tratta della parte successiva, chiamata titolare, che viene comunemente descritta anche come portafoglio digitale.

I titolari, come suggerisce il nome, conservano principalmente le credenziali emesse dagli emittenti.

Vengono memorizzati come un'app sul tuo dispositivo e possono essere presentati alle parti richiedenti.

E, analogamente agli emittenti, chiunque può essere un titolare.

In effetti, non è raro che emittenti e titolari siano gestiti dalla stessa entità.

Pensa a una palestra che vuole creare la propria credenziale di abbonamento digitale e gestirla tramite la propria app.

In questo caso, saresti sia emittente che titolare.

Ok, la terza parte è il verificatore o la parte che richiede le credenziali digitali.

I verificatori effettuano richieste di credenziali di solito per controllare gli attributi di un utente, come i requisiti di età, il cognome e così via.

Si tratta di attività o app che richiedono dati utente aggiuntivi per eseguire un servizio, ad esempio l'acquisto di alcolici o la verifica di un'età minima.

Su Android, le interazioni tra queste tre parti e l'utente vengono coordinate tramite Gestore delle credenziali con l'API Digital Credentials.

L'emittente può chiamare l'API per emettere le credenziali per un titolare, anche se non è necessario se si tratta della stessa entità.

Dopo l'emissione della credenziale, un verificatore può chiamare un'API per richiederla.

Gestore delle credenziali abbina la richiesta a tutti i titolari disponibili e li presenta all'utente per selezionare la credenziale e fornire il consenso.

Una volta selezionato, il titolare viene richiamato e può eseguire ulteriori controlli, se necessario, prima di condividere la credenziale con il verificatore.

Una volta ricevuta la credenziale, il verificatore può anche eseguire vari controlli sulla legittimità della credenziale, tra cui il controllo dell'emittente originale.

Ora potresti chiederti: in che modo le credenziali digitali sono sicure?

La sicurezza è integrata in ogni fase del processo e ora ne esamineremo alcune.

Quindi, dal lato dell'emittente, quando quest'ultimo vuole condividere una credenziale con un titolare, deve verificare che il titolare non possa essere manomesso o copiato, in pratica che sia affidabile.

Come può verificarlo?

Prima che un emittente rilasci la credenziale, deve richiedere al titolare di dimostrare la propria identità e la sicurezza del dispositivo su cui opera.

Il titolare invia l'attestazione del wallet, di solito sotto forma di catena di certificati verificabile.

Il titolare genera anche una coppia di chiavi associate all'hardware.

Invia all'emittente la chiave pubblica di questa coppia di chiavi con l'attestazione di chiavi Android, in modo che l'emittente possa convalidare la legittimità dell'hardware.

L'emittente firmerà questa chiave pubblica nella credenziale emessa, in modo che la credenziale sia ufficialmente associata al singolo dispositivo.

Per quanto riguarda il titolare, una volta ottenuta una nuova credenziale, registra solo i metadati della credenziale con Gestore delle credenziali.

Gestore delle credenziali utilizza questi metadati per determinare quali titolari mostrare quando un verificatore effettua una richiesta di credenziali.

Nessun dato utente reale viene mai registrato con Gestore delle credenziali o esposto a Google.

Inoltre, anche quando Gestore delle credenziali seleziona i wallet da mostrare all'utente, i contenuti di ogni wallet non vengono rivelati in quel momento.

Ora, quando viene effettuata una richiesta di credenziali e un utente acconsente alla condivisione di una credenziale, viene richiamato il titolare selezionato e il controllo del flusso di lavoro viene trasferito al titolare.

Come forse ricorderai, un holder è semplicemente un'app, quindi viene richiamata l'app.

A questo punto, il titolare può visualizzare informazioni come il verificatore richiedente e la credenziale richiesta e può decidere se condividere la credenziale con il verificatore, anche se l'utente ha già concesso l'autorizzazione.

I dati delle credenziali non sono accessibili a Google.

Vengono registrati solo i metadati di routing e il payload è criptato end-to-end tra il titolare e il verificatore.

In questo modo, il titolare ha il controllo sulle parti con cui vuole condividere le proprie credenziali.

Infine, dal lato del verificatore, dopo che la credenziale è stata richiesta e il titolare la condivide, il verificatore riceve la presentazione della credenziale da un titolare.

Ora, l'autorità di verifica può controllare se la risposta è stata generata di recente dal titolare originale delle credenziali per la richiesta.

Può confermare che la risposta della credenziale è firmata utilizzando la chiave associata al dispositivo del titolare, inclusa la richiesta di un token monouso e l'origine della chiamata osservata dal titolare.

Il verificatore può anche controllare l'autenticità dell'emittente della credenziale verificando il certificato dell'emittente, assicurandosi che provenga da una fonte attendibile.

In breve, gli emittenti ottengono garanzie hardware, i titolari ottengono il controllo su quali credenziali vogliono condividere, i verificatori ottengono la prova crittografica dell'emittente e del titolare e gli utenti mantengono il pieno consenso su quali dati vogliono condividere.

Ora che abbiamo visto come le credenziali digitali sono sicure, passiamo ad alcuni dei casi d'uso delle credenziali digitali disponibili oggi tramite l'API Digital Credentials su Android.

Il primo di questi che tratterò si chiama verifica email.

Questa API recupera l'indirizzo Gmail con cui l'utente ha eseguito l'accesso direttamente dal suo dispositivo e lo presenta alla tua app come credenziale digitale verificata da Google, eliminando la necessità di inviare password monouso o link magici.

Ciò significa che l'utente non abbandona mai la tua app e deve solo fornire il consenso con un tocco nel familiare riquadro inferiore di Gestore delle credenziali.

Ecco una registrazione demo dell'API in azione.

Questa è un'app di esempio che implementa la verifica email tramite l'API Digital Credentials.

Quando tocco "Richiedi email verificata", Gestore delle credenziali richiede una credenziale digitale email verificata ai titolari sul dispositivo che possiedono questo tipo di credenziale.

In questo caso, solo Google è il titolare di questa credenziale email verificata, che viene visualizzata nel riquadro inferiore.

Questo è uno degli indirizzi email con cui l'utente ha eseguito l'accesso sul dispositivo.

In effetti, in questo caso Google è sia l'emittente che il titolare della credenziale digitale.

Una volta selezionata la credenziale che voglio condividere, questa viene restituita all'app, che al momento mostra solo i campi contenuti nella credenziale, ovvero l'indirizzo email verificato.

Nella tua app, puoi utilizzare queste informazioni per passare alla schermata successiva, ad esempio per creare una passkey o altri passaggi di creazione dell'account.

Per l'utente, è sufficiente dare il consenso e passare alla schermata successiva.

Se vuoi provarla, puoi andare al nostro esempio su GitHub e installarla sul tuo dispositivo.

Prova a utilizzarla su un dispositivo fisico e tieni presente che dovrai aver eseguito l'accesso ad almeno un account Gmail sul tuo dispositivo.

Quindi, darò un po' più di tempo se le persone sono interessate.

Okay.

Interessante, vero?

E quando pensi alla verifica email, qual è la forma successiva di verifica dell'utente che ti viene in mente?

Esatto, la verifica del numero di telefono.

L'API Digital Credentials supporta anche in modo nativo la verifica del numero di telefono, eliminando l'attrito e la vulnerabilità delle OTP via SMS.

Anche la verifica del numero di telefono avviene tramite l'API Digital Credentials e, in questo caso, il numero di telefono sul dispositivo viene richiesto e presentato come credenziale digitale.

L'utente vede solo il familiare riquadro inferiore di Gestore delle credenziali per condividere o verificare il proprio numero di telefono, rimanendo all'interno dell'app e richiedendo solo pochi tocchi per completare la verifica.

Qui puoi vedere un'app di esempio in cui il cliente può condividere il proprio numero di telefono con un solo tocco, senza uscire dall'app.

Come funziona questa configurazione?

Se mappiamo questo scenario alle parti coinvolte nelle credenziali digitali, l'emittente, in questo caso, è l'operatore telefonico del numero di telefono sulla scheda SIM del dispositivo e il titolare è Android Telephony.

Quando un verificatore, ad esempio la tua app, richiede il numero di telefono dell'utente, questo viene recuperato da Google Telephony con una chiamata API Digital Credentials.

Ti starai chiedendo come funziona la fatturazione.

Esiste un passaggio aggiuntivo, specifico per questo flusso, in cui la credenziale viene trasmessa al tuo operatore o aggregatore per scopi di fatturazione.

Questo avviene dopo che il numero di telefono viene recuperato da Google Telephony, dove viene archiviato in stato criptato.

Questo viene poi trasmesso all'operatore, che lo decripta e restituisce il numero di telefono direttamente al backend della tua app, durante il quale ti viene addebitato il costo.

Il vantaggio è che l'operatore ti addebiterà solo le verifiche andate a buon fine, che vengono trasferite tramite dati o Wi-Fi e sono molto più affidabili degli SMS.

Ecco una demo della verifica del numero di telefono in azione, con Firebase come aggregatore di operatori.

L'app richiede il numero di telefono di un utente nell'ambito della procedura di accesso.

Questo utente ha più schede SIM e ne sceglie una da condividere con l'app.

Una volta che l'utente conferma la sua scelta, lo scambio avviene in background.

Dopodiché, vedrai la schermata successiva con il numero di telefono recuperato.

L'utente non ha mai dovuto uscire dall'app e ha dovuto solo selezionare e confermare il numero di telefono da condividere per procedere nel flusso senza problemi, il tutto con pochi tocchi.

Lascia che l'operazione venga completata per vedere ancora una volta il completamento.

In questo modo, vedrai il numero di telefono nella schermata finale.

Questo è tutto.

Oggi abbiamo trattato molti argomenti.

Abbiamo prima esplorato l'utilizzo di Gestore delle credenziali per migliorare l'implementazione delle passkey e passare a un mondo senza password.

Consulta le nostre risorse su Gestore delle credenziali e passkey qui per saperne di più e accedere alle nostre app di esempio.

Poi abbiamo parlato del prossimo requisito di accesso zero-tap per le tue app, che consente agli utenti di accedere senza problemi durante la configurazione di un nuovo dispositivo.

Questo requisito diventerà obbligatorio nel Play Store entro aprile 2027, quindi ti invitiamo a segnare questa data sul calendario.

Infine, abbiamo spiegato come funzionano le credenziali digitali e alcune delle loro funzionalità più utili su Android.

Per un approfondimento sui contenuti e per accedere ai nostri esempi, consulta le nostre risorse sulle credenziali digitali qui.

Tutto ciò che abbiamo condiviso oggi è disponibile e pronto per essere utilizzato.

Il futuro dell'identità su Android è qui ed è più entusiasmante che mai.

Grazie per il tempo che mi avete dedicato. So che è ora di pranzo, quindi vi invito a gustare il cibo all'esterno.

E non esitate a rivolgervi a me o a Tom per domande sulle passkey o sulle credenziali digitali.

A presto.