Digital Credentials API (2025): Supporto Live su Chrome e Safari

Ultimo aggiornamento: 30 ottobre 2025

Una rapida panoramica del supporto della Digital Credentials API nei principali browser:

Il mondo delle credenziali digitali si muove velocemente. Ecco un'istantanea degli sviluppi chiave e delle proiezioni:

Want to experience digital credentials in action?

Try Digital Credentials

Cosa è cambiato da luglio 2025?

• Rilasciati: Chrome 141 (30 settembre 2025) e Safari 26 (15 settembre 2025).
• Chrome: Protocol-agnostic (OpenID4VP e ISO 18013-7 Allegato C), cross-device su desktop tramite CTAP.
• Safari: solo-mdoc (org-iso-mdoc), flusso cross-device tramite CTAP.
• Forma dell'API: navigator.credentials.get(); denominazione requests/data; feature detection DigitalCredential.

Le credenziali digitali sono un tema caldo nel settore dell'identità in questo momento. Man mano che le nostre vite diventano sempre più connesse al mondo digitale, la necessità di modi sicuri, incentrati sull'utente e rispettosi della privacy per affermare la nostra identità e le nostre qualifiche online non è mai stata così critica. I metodi tradizionali mostrano i segni del tempo e la domanda di soluzioni più robuste è palpabile.

In questo articolo, discuteremo lo stato attuale della Digital Credentials API, uno sviluppo importante che promette di rimodellare il modo in cui interagiamo con le informazioni sull'identità sul web. Esploreremo i suoi meccanismi sottostanti, i protocolli che supporta, l'attuale adozione da parte dei browser e offriremo raccomandazioni sia per le relying parties sia per gli emittenti di wallet che si muovono in questo panorama in rapida evoluzione.

Dimostrare la propria identità in modo affidabile e sicuro è stata una sfida persistente nell'architettura del web per molti anni. Sebbene Internet abbia facilitato una connettività e uno scambio di informazioni senza precedenti, ha anche aperto nuove strade per la falsa rappresentazione e la frode.

In alcuni paesi sono emerse soluzioni, principalmente guidate da consorzi bancari pionieristici che hanno sviluppato servizi per sfruttare le relazioni di fiducia esistenti per l'identificazione online. Anche i governi sono intervenuti, imponendo o fornendo wallet e servizi di identità digitale nazionali. Tuttavia, queste soluzioni erano spesso isolate, geograficamente limitate e non universalmente interoperabili.

L'alternativa per la verifica dell'identità in molte regioni ha tradizionalmente comportato processi ad alto attrito. La verifica fisica presso un ufficio postale, ad esempio, introduce ritardi e disagi significativi. Le videochiamate abbinate al caricamento di documenti sono diventate un'alternativa più digitale, seguite dalla più recente ascesa della scansione automatizzata dei documenti e dei liveness checks. Nonostante i loro progressi, questi metodi presentano notevoli svantaggi. Possono richiedere molto tempo, essere soggetti a errori umani o pregiudizi e si sono rivelati spesso vulnerabili a falsificazioni sofisticate.

La sfida si sta intensificando drasticamente con l'avvento dei deepfake, delle tecniche avanzate di impersonificazione basate sull'IA e di attacchi di phishing sempre più sofisticati. Queste tecnologie possono creare prove video, audio e documentali altamente realistiche ma interamente fabbricate, rendendo incredibilmente difficile per i sistemi tradizionali, e persino per gli strumenti di verifica basati sull'IA, distinguere gli utenti autentici da quelli fraudolenti. Il potenziale per creare identità sintetiche o manipolare dati biometrici per aggirare i controlli è una minaccia grave, in particolare per le istituzioni finanziarie e qualsiasi servizio che richieda robusti processi Know Your Customer (KYC). Questo scenario di minaccia in crescita sottolinea l'urgente necessità di meccanismi di identità e verifica online più sicuri e verificabili crittograficamente.

Want to experience digital credentials in action?

Try Digital Credentials

Per capire come funzionano le credenziali digitali, è necessario esaminare gli attori chiave coinvolti e i diversi livelli tecnologici che ne consentono la funzionalità.

Alla base, il concetto di credenziali digitali, specialmente nel contesto delle nuove API web, ruota attorno a un modello a tre parti:

1. Emittente (Issuer): Un'entità (es. governo, università, datore di lavoro) che è autorevole per determinate informazioni su un soggetto e può emettere una credenziale digitale che attesta tali informazioni.
2. Titolare (Holder): Il soggetto delle informazioni (cioè l'utente) che riceve la credenziale dall'emittente e la conserva in un wallet digitale. Il titolare controlla quando e quali informazioni della credenziale vengono condivise.
3. Verificatore (Verifier) (o Relying Party): Un'entità (es. un sito web, un servizio online) che ha bisogno di verificare determinate informazioni sul titolare per concedere l'accesso a un servizio o una risorsa. Il verificatore richiede le informazioni necessarie al titolare.

Questo modello a tre parti è importante perché mira a mettere l'utente (titolare) in controllo dei propri dati. A differenza dei sistemi di identità tradizionali in cui i dati potrebbero essere archiviati centralmente o condivisi tra le parti senza l'intermediazione diretta dell'utente, questo modello enfatizza il consenso dell'utente e la divulgazione selettiva. Il titolare decide quali informazioni condividere da una credenziale per una transazione specifica, anziché rivelare l'intera credenziale.

Un aspetto fondamentale di questi sistemi è il coinvolgimento di coppie di chiavi crittografiche. L'emittente firma digitalmente la credenziale, garantendone l'autenticità e l'integrità. Il titolare, a sua volta, utilizza la propria chiave privata, spesso protetta all'interno del suo wallet digitale (che è protetto dall'hardware del dispositivo), per dimostrare il controllo sulla credenziale e per autorizzarne la presentazione a un verificatore. Ciò comporta tipicamente che il verificatore presenti una sfida (una stringa di dati casuale) che il wallet del titolare firma utilizzando la chiave privata associata alla credenziale. Il verificatore può quindi utilizzare la chiave pubblica corrispondente per confermare la firma, autenticando così la presentazione.

Questa spiegazione è neutrale rispetto al protocollo, poiché i principi fondamentali di emissione, possesso e verifica tramite sfide crittografiche sono comuni a diverse tecnologie sottostanti.

Questo articolo si concentra sulla verifica delle credenziali digitali e sul principio della divulgazione selettiva, che consente agli utenti di dimostrare attributi specifici (ad esempio, "Ho più di 18 anni", "Possiedo una patente di guida valida") senza rivelare l'intero documento di origine. Sebbene i sistemi sottostanti per le credenziali digitali possano supportare funzionalità come le Firme Elettroniche Qualificate (FEQ) e le capacità di firma remota (come si vede in soluzioni complete come il Wallet di Identità Digitale dell'UE per firme legalmente vincolanti), il focus qui, in particolare per la Digital Credentials API, è sull'asserzione di identità e sulla verifica degli attributi per le interazioni online, non primariamente su queste funzionalità di firma più ampie.

Per capire come funzionano le credenziali digitali, è utile visualizzare un modello a più livelli. Ogni livello affronta un aspetto diverso dell'ecosistema, dal formato dei dati stessi a come vengono presentati a un utente in un browser web. Questo articolo si concentra principalmente sulla Digital Credentials API, che opera al livello di presentazione.

Terminologia Fondamentale:

• Credenziale digitale: Qualsiasi credenziale leggibile da una macchina (PDF con un codice a barre, ISO mDL, W3C VC, SD-JWT, ecc.). "Digitale" non dice nulla sulla verificabilità crittografica.
• Credenziale Verificabile (Verifiable Credential): Un tipo di credenziale digitale, definita dal W3C VC Data Model. Aggiunge la prova di non manomissione e la prova crittografica, e vive sempre in un mondo a tre parti: emittente → titolare → verificatore.
• Verifiable Credential API: Un'interfaccia di servizio REST/HTTP per emettere, archiviare, presentare e verificare VC tra sistemi back-end (emittenti, wallet, verificatori).
• Digital Credentials API (DC API): Un'API a livello di browser/sistema operativo (JavaScript + meccanismi nativi) che consente a un sito web di chiedere al wallet sul dispositivo dell'utente di presentare qualsiasi credenziale digitale supportata (VC, ISO mDoc, SD-JWT...) in modo rispettoso della privacy.

Pensiamo alle VC come a un modello di dati, alla VC API come a una specifica per il back-end e alla DC API come all'implementazione front-end che presenta le credenziali al Web. Tutto ciò che si trova sopra il livello 1 (Livello del modello dei dati) è indipendente dal formato; tutto ciò che si trova al di sotto dipende dal formato della credenziale.

Flusso end-to-end (esempio: verifica dell'età online):

1. Emissione (VC API - emittente ↔ wallet): La motorizzazione civile emette una Credenziale Verificabile che dice "Il titolare ha più di 18 anni".
2. Archiviazione (App Wallet - SO): La credenziale risiede nel wallet dell'utente con la sua prova crittografica.
3. Richiesta (navigator.credentials.get() tramite DC API - sito web → browser): Il sito web di un negozio di birra chiede: "Mostrami la prova che l'utente ha ≥18 anni."
4. Presentazione (DC API invia al wallet → OpenID4VP (protocollo) → payload VC): Il wallet mostra un'interfaccia di consenso, l'utente approva, il wallet invia in risposta una presentazione verificabile.
5. Verifica (VC API - back-end del negozio di birra): Il back-end del sito verifica la firma e il DID/chiave pubblica dell'emittente; concede l'accesso.

Notiamo come i dati siano una VC, il trasporto sul Web sia la DC API, il protocollo di scambio sottostante sia OpenID4VP e il controllo lato server utilizzi la VC API.

Perché esiste questa suddivisione:

• Modello di dati interoperabile (prove crittografiche, divulgazione selettiva): Risolto dal VC Data Model (e altri formati).
• Endpoint REST standard per sistemi back-end: Risolto dalla VC API.
• Handshake Wallet ↔ Sito web che preserva la privacy: Risolto dalla DC API.
• Diversi livelli di fiducia / tipi di documento (documento d'identità governativo vs. certificato di un corso): Risolto utilizzando il formato giusto (ISO mDoc per documenti ad alta affidabilità; W3C VC per dichiarazioni generiche) sotto la DC API.

Punti chiave da ricordare:

1. "Credenziale digitale" è il termine generico.
2. Una Credenziale Verificabile è un tipo di credenziale digitale con verificabilità crittografica integrata.
3. La VC API è l'infrastruttura server-to-server per le operazioni sul ciclo di vita delle VC.
4. La Digital Credentials API è il ponte browser-to-wallet che finalmente consente a quelle credenziali di fluire senza problemi nelle app web, qualunque sia il formato concreto in cui si trovano.
5. I tre pezzi sono complementari, non in competizione: si trovano a diversi livelli dello stesso stack e insieme abilitano un'identità sicura e incentrata sull'utente sul web aperto.

Dopo aver esplorato i partecipanti e l'architettura a più livelli delle credenziali digitali, questo articolo approfondirà ora il livello di presentazione, concentrandosi specificamente sulla Digital Credentials API e sul suo stato attuale.

Essendo il componente cruciale a livello di presentazione, la Digital Credentials API è uno standard web attualmente in fase di sviluppo per fornire un modo sicuro e standardizzato per i siti web di richiedere e ricevere informazioni di identità digitale dai wallet digitali degli utenti. Questo sforzo è principalmente ospitato all'interno del Federated Identity Working Group (FedID WG) del W3C, essendo migrato dal FedID Community Group nell'aprile 2025. La bozza di specifica ufficiale può essere trovata qui: https://w3c-fedid.github.io/digital-credentials/.

Ad ottobre 2025, l'API è stata rilasciata in versioni stabili sia di Chrome 141 (30 settembre 2025) sia di Safari 26 (15 settembre 2025). L'implementazione di Chrome è protocol-agnostic, supportando sia OpenID4VP che ISO 18013-7 Allegato C, mentre Safari supporta esclusivamente il protocollo org-iso-mdoc. Chrome lo supporta nativamente su Android attraverso il suo sistema Credential Manager e supporta anche la Cross-Device Digital Credentials API su desktop tramite un passaggio QR supportato da CTAP/BLE.

L'API estende la Credential Management API esistente abilitando le richieste di credenziali digitali tramite navigator.credentials.get(). Secondo il W3C FedID WG Digital Credentials Explainer (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md), l'API è tornata a utilizzare questa interfaccia consolidata anziché il navigator.identity precedentemente proposto. Un sito web richiede una credenziale digitale chiamando navigator.credentials.get() con parametri specifici per le credenziali digitali.

Ecco un esempio illustrativo di come un sito web potrebbe chiamare l'API per richiedere una credenziale utilizzando OpenID4VP:

async function requestCredential() {
    // Verifica il supporto della Digital Credentials API
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // Questi parametri vengono tipicamente recuperati dal backend.
            // Definiti staticamente qui a scopo illustrativo dell'estensibilità del protocollo.
            const oid4vp = {
                protocol: "oid4vp", // Un esempio di richiesta OpenID4VP ai wallet. // Basato su https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Richiesta di Presentation Exchange, omessa per brevità
                    },
                },
            };
 
            // crea un Abort Controller
            const controller = new AbortController();
 
            // Chiama la Digital Credentials API utilizzando la richiesta di presentazione dal backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Invia la risposta crittografata al backend per la decrittazione e la verifica
            // Omesso per brevità
        } catch (error) {
            console.error("Errore:", error);
        }
    } else {
        // scenario di fallback, solo a scopo illustrativo
        alert("La Digital Credentials API non è supportata in questo browser.");
    }
}

Questo esempio è tratto da qui.

La Digital Credentials API agisce essenzialmente come un wrapper o intermediario sicuro. Permette al browser di mediare la richiesta di informazioni sull'identità, sfruttando le capacità del sistema operativo sottostante per scoprire i wallet e le credenziali disponibili che corrispondono alla richiesta. Il browser e il sistema operativo possono quindi presentare un'interfaccia utente coerente per selezionare la credenziale e autorizzarne il rilascio, migliorando la sicurezza e la privacy garantendo il consenso dell'utente e impedendo ai siti web di accedere silenziosamente a dati sensibili. I dati effettivi della credenziale nella risposta sono pensati per essere opachi (crittografati) per il browser stesso, con la decrittazione e l'interpretazione gestite dal relying party e dal wallet/titolare.

La Digital Credentials API è progettata per essere agnostica rispetto al protocollo, il che significa che può supportare vari protocolli sottostanti per lo scambio di credenziali. Tuttavia, due principali famiglie di protocolli sono centrali per le implementazioni e le discussioni attuali: org.iso.mdoc (derivato da ISO 18013-5 e la sua estensione ISO 18013-7 "Allegato C") e le specifiche della OpenID Foundation OpenID for Verifiable Presentations (OpenID4VP) e OpenID for Verifiable Credential Issuance (OpenID4VCI).

• Origine e Standardizzazione: org.iso.mdoc si riferisce al formato dei dati e al modello di interazione per i documenti mobili, principalmente le Patenti di Guida Mobili (mDL), standardizzati dall'Organizzazione Internazionale per la Standardizzazione (ISO) e dalla Commissione Elettrotecnica Internazionale (IEC). Lo standard fondamentale è ISO/IEC 18013-5, che definisce l'applicazione mDL, la struttura dei dati e i protocolli per la presentazione di persona (prossimità) utilizzando tecnologie come NFC, Bluetooth o codici QR. ISO/IEC 18013-7 estende questo per consentire la presentazione online/remota delle mDL. La stringa di protocollo "org.iso.mdoc" è definita specificamente in ISO/IEC TS 18013-7 (Allegato C) per l'uso con API come la Digital Credentials API.

• Modello dei Dati: Gli mdocs hanno una struttura dati rigorosamente definita basata su CBOR (Concise Binary Object Representation) per compattezza ed efficienza. Specifica namespace ed elementi di dati per gli attributi comuni della patente di guida e supporta forti caratteristiche di sicurezza crittografica, tra cui l'autenticazione dell'emittente, il binding al dispositivo, l'autenticazione del titolare (tramite ritratto), la crittografia della sessione e la divulgazione selettiva.

• Casi d'Uso Tipici: Principalmente documenti d'identità emessi dal governo come patenti di guida e carte d'identità nazionali. È progettato per scenari ad alta affidabilità, sia di persona (es. controlli stradali, verifica dell'età per beni soggetti a restrizioni) che online (es. accesso a servizi governativi, verifica dell'identità remota per l'apertura di conti bancari).

• Origine e Standardizzazione: OpenID4VP (per la presentazione) e OpenID4VCI (per l'emissione) sono specifiche sviluppate dalla OpenID Foundation. Estendono OAuth 2.0 per supportare lo scambio di credenziali verificabili. Si tratta di standard aperti volti a un'ampia interoperabilità per vari tipi di credenziali, non solo quelle governative. All'inizio del 2025, OpenID4VP è in fase di bozza avanzata (es. bozza 28 ad aprile). Anche OpenID4VCI sta maturando.
• Modello dei Dati: OpenID4VP/VCI sono progettati per essere agnostici rispetto al formato delle credenziali. Possono trasportare Credenziali Verificabili (VC) W3C in formati JSON/JSON-LD o JWT, mdocs, SD-JWT e altri formati. Il modello di interazione prevede una Richiesta di Autorizzazione dal Verificatore (RP) e una risposta dal Wallet del Titolare contenente un vp_token (Verifiable Presentation Token). La divulgazione selettiva è tipicamente gestita utilizzando linguaggi di query come Presentation Exchange (DIF PE) o il più recente Digital Credentials Query Language (DCQL).
• Casi d'Uso Tipici: Ampia gamma di applicazioni, tra cui la verifica dell'identità, la fornitura di prove di qualifiche (es. diplomi di studio, certificazioni professionali), attestazioni di appartenenza e altro ancora. Sono adatti per le interazioni online in cui un relying party ha bisogno di verificare le dichiarazioni di vari emittenti.

È importante riconoscere che questi non sono sempre mutualmente esclusivi. OpenID4VP può, ad esempio, essere utilizzato per richiedere e trasportare un [org.iso.mdoc]. La scelta dipende spesso dal caso d'uso specifico, dal tipo di credenziale e dai partecipanti all'ecosistema.

Il Wallet di Identità Digitale dell'Unione Europea (EUDI) è una grande iniziativa che mira a fornire a tutti i cittadini e residenti dell'UE un wallet digitale sicuro per documenti d'identità e attestazioni. L'architettura e il framework di riferimento del Wallet EUDI prevedono esplicitamente di supportare sia mdoc (in particolare per le Patenti di Guida Mobili) sia le Credenziali Verificabili W3C, utilizzando OpenID4VP e OpenID4VCI per i flussi di presentazione ed emissione. L'implementazione di riferimento include il supporto per OpenID4VP che trasferisce mDocs e OpenID4VCI per l'emissione di PID e mDL in formati mDoc e SD-JWT-VC. formati. Questo duplice supporto da parte di un progetto di così vasta scala sottolinea l'importanza di entrambe le famiglie di protocolli. Tuttavia, questa direzione non è esente da critiche, poiché alcuni osservatori notano che la Digital Credentials API, fortemente influenzata dalle aziende "Bigtech statunitensi", potrebbe essere profondamente incorporata nelle specifiche finali del Wallet EUDI. Sono state sollevate preoccupazioni sulla potenziale influenza di entità non-UE su un pezzo critico dell'infrastruttura dell'UE, come discusso in forum della community come questa discussione su GitHub.

Il panorama dei browser per la Digital Credentials API ha ormai preso forma, con Chrome 141 e Safari 26 che hanno rilasciato il supporto stabile a settembre 2025. Ci sono notevoli differenze di approccio e livelli di supporto tra i browser.

Chrome ha rilasciato la Digital Credentials API in Chrome 141 (30 settembre 2025). L'implementazione di Chrome è protocol-agnostic: compatibile con OpenID4VP e ISO 18013-7 Allegato C (mdoc online). Il desktop supporta la presentazione cross-device da wallet mobili tramite un canale supportato da CTAP/BLE (passaggio tramite QR), con la risposta opaca al browser. La forma dell'API è passata a navigator.credentials.get(); parametri rinominati: providers → requests, request → data.

Rilevamento della Funzionalità:

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API supportata
}

Il Credential Manager di Android supporta nativamente OpenID4VP per la presentazione e OpenID4VCI per l'emissione, consentendo alle app Android di agire come titolari di credenziali e verificatori utilizzando questi standard. Google nota un crescente supporto da parte dei wallet; Google Wallet è un primo adottante, con Samsung Wallet e 1Password annunciati.

Nelle versioni precedenti di questo articolo, avevamo previsto che l'approccio di Apple si sarebbe differenziato da quello di Google, concentrandosi sul protocollo org.iso.mdoc. Per contesto storico, il nostro ragionamento era il seguente:

Come avevamo correttamente anticipato, WWDC25 ha confermato questa strategia. Safari 26 (iOS/iPadOS/macOS) è stato rilasciato il 15 settembre 2025 con il supporto alla Digital Credentials API, confermando che la loro implementazione supporta esclusivamente il protocollo org-iso-mdoc (con trattino) per la presentazione.

Ciò è stato dettagliato nella sessione di WWDC25 Verifica dei documenti d'identità sul web. L'API consente ai siti web di richiedere informazioni verificabili da documenti d'identità, come una patente di guida, conservati in Apple Wallet o in app di provider di documenti di terze parti.

Punti chiave dell'implementazione di Apple:

• Solo MDOC: L'API utilizza esclusivamente la stringa di protocollo "org-iso-mdoc", basata sullo standard ISO/IEC 18013-7 Allegato C. Non c'è supporto per OpenID4VP nell'implementazione di Safari della Digital Credentials API.
• Solo Presentazione: L'API è per la presentazione (verifica) di credenziali esistenti. L'emissione in Apple Wallet o altre app rimane un processo separato, non gestito dal browser.
• Incentrato sull'Utente e Sicuro: Il flusso è avviato da un gesto dell'utente e sfrutta un meccanismo di "richiesta parziale", in cui il sistema operativo prima analizza e valida la richiesta in una sandbox prima di passarla all'applicazione wallet, migliorando la sicurezza.
• Estensibile alle App: Oltre ad Apple Wallet, le app di terze parti possono agire come provider di documenti implementando il nuovo framework IdentityDocumentServices e un'estensione dell'app.
• Supporto Cross-Device: La presentazione cross-device da piattaforme non-Apple utilizza CTAP per la prossimità dopo un passaggio tramite codice QR; la risposta JS rimane crittografata/opaca al browser.

Apple ha fornito un chiaro esempio di codice su come un relying party utilizzerebbe l'API:

async function verifyIdentity() {
    try {
        // Il server genera e firma crittograficamente i dati della richiesta.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // La richiesta specifica il protocollo 'org-iso-mdoc'.
        const request = {
            protocol: "org-iso-mdoc",
            // data contiene la richiesta mdoc firmata crittograficamente.
            data,
        };
 
        // L'API deve essere chiamata da un gesto dell'utente.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Invia la risposta crittografata dal wallet al server per la decrittazione e la validazione.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Mostra i dettagli verificati...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Gestisci gli errori, es. annullamento da parte dell'utente.
    }
}

Questa conferma consolida le strategie divergenti nel mercato dei browser. Mentre Chrome si basa sul flessibile livello di trasporto OpenID4VP, Apple sta sfruttando il suo profondo investimento nell'ecosistema ISO mdoc per fornire una soluzione altamente integrata e sicura, sebbene meno flessibile, su misura per i documenti d'identità ufficiali.

Mozilla ha formalmente espresso una posizione negativa sugli standard riguardo alla Digital Credentials API nella sua forma attuale. Le loro preoccupazioni sono ampie e radicate nella loro missione di proteggere la privacy degli utenti, la loro autonomia e garantire un web aperto ed equo.

Le principali preoccupazioni sollevate da Mozilla includono:

• Rischi per la Privacy: Potenziale aumento della condivisione di dati personali e una riduzione dell'anonimato online se le richieste di credenziali digitali diventassero comuni per interazioni banali.
• Esclusione degli Utenti: Rischio che le persone che non possono o scelgono di non utilizzare le credenziali digitali possano essere escluse da servizi e comunità online. Le credenziali emesse dal governo, un caso d'uso primario, potrebbero non allinearsi con la scelta di un individuo su come presentare la propria identità.
• Problemi di Interoperabilità: Preoccupazioni riguardo a una proliferazione di formati di credenziali che porterebbe a un ecosistema frammentato anziché a uno universalmente interoperabile.
• Divulgazione Selettiva: Timori che i benefici per la privacy della divulgazione selettiva possano essere vanificati se non implementata con forti garanzie di non-correlabilità, o se gli utenti non comprendono appieno ciò che viene condiviso.
• Centralizzazione della Fiducia e Autonomia dell'Utente: Timori che l'API possa portare a una maggiore centralizzazione della fiducia e a una riduzione dell'autonomia dell'utente, perpetuando gli squilibri di potere sociali esistenti.

Mozilla riconosce che una tale API potrebbe offrire utilità rispetto ai metodi ad-hoc esistenti per la presentazione delle credenziali, ma sottolinea che le nuove funzionalità della piattaforma web devono dimostrabilmente migliorare il web nel suo complesso e dare priorità agli interessi degli utenti. Sebbene un Consiglio del W3C abbia respinto un'obiezione formale relativa a queste preoccupazioni (per consentire al lavoro di procedere all'interno del W3C anziché in sedi potenzialmente meno trasparenti), il Consiglio ha raccomandato al Working Group di lavorare attivamente per mitigare questi potenziali danni.

Tabella 1: Supporto dei Browser per la Digital Credentials API e i Protocolli (Ott 2025)

Per le organizzazioni (Relying Parties o RP) che intendono richiedere e verificare le credenziali digitali degli utenti, il panorama attuale richiede un'attenta pianificazione strategica.

Dato che Safari (rilasciato il 15 settembre 2025) supporta esclusivamente interazioni dirette org-iso-mdoc (ISO 18013-7 Allegato C) attraverso la Digital Credentials API, e Chrome (rilasciato il 30 settembre 2025) è protocol-agnostic supportando sia OpenID4VP che ISO 18013-7 Allegato C (mdoc), gli RP che mirano alla più ampia portata possibile dovrebbero prepararsi a supportare interazioni basate su entrambi gli approcci.

Ciò significa progettare sistemi in grado di:

1. Avviare richieste di credenziali tramite l'API navigator.credentials.get(), specificando diversi parametri di protocollo ("org-iso-mdoc" per Safari o "openid4vp" per Chrome/flussi OID4VP) in base al rilevamento del browser o alle capacità dello user agent.
2. Elaborare risposte che possono arrivare direttamente in formato mdoc (ISO 18013-7 Allegato C) o come vp_token tramite OpenID4VP, che deve poi essere analizzato per estrarre la credenziale sottostante (che potrebbe essere essa stessa un mdoc o un altro formato VC).

Sebbene ciò aggiunga complessità, tentare di forzare tutti gli utenti su un unico percorso di protocollo escluderà probabilmente una parte sostanziale della base di utenti, sia quelli su iOS sia quelli su Chrome/Android, a seconda del percorso scelto. Un approccio pragmatico, sebbene più intensivo in termini di sviluppo, è quello di costruire la flessibilità per gestire entrambi.

I Relying Parties devono essere estremamente consapevoli che anche quando richiedono la stessa informazione logica (ad esempio, "l'utente ha più di 21 anni?"), il modo in cui questa viene definita in una richiesta e come viene restituita in una risposta può differire significativamente tra una query mdoc diretta e una query OpenID4VP (che potrebbe usare Presentation Exchange o DCQL).

• Divulgazione Selettiva mdoc: org.iso.mdoc ha i propri meccanismi per la divulgazione selettiva, che tipicamente comportano la creazione da parte dell'emittente di hash salati di singoli elementi di dati. Il wallet del titolare rivela quindi solo gli elementi richiesti insieme ai loro sali, consentendo al verificatore di confermarli rispetto agli hash senza vedere altri dati. La richiesta di elementi specifici è legata a namespace e identificatori di elementi di dati predefiniti all'interno dello standard mdoc.
• Divulgazione Selettiva OpenID4VP: OpenID4VP utilizza tipicamente un linguaggio di query come Presentation Exchange (DIF PE) o il più recente Digital Credentials Query Language (DCQL) incorporato nella presentation_definition della richiesta. Ciò consente agli RP di specificare i tipi di credenziali e i singoli claim di cui hanno bisogno. Il wallet costruisce quindi una Presentazione Verificabile contenente solo le informazioni richieste, se supportato dal formato della credenziale e dal wallet.

Gli RP devono mappare i loro specifici requisiti di dati a queste diverse strutture di protocollo. È fondamentale comprendere le sfumature di come la divulgazione selettiva viene implementata e richiesta in ciascun protocollo per garantire che vengano richiesti ed elaborati solo i dati minimi necessari, aderendo così alle migliori pratiche di privacy e ai principi di minimizzazione dei dati. Anche il formato e la struttura dei dati divulgati restituiti dal wallet possono differire, richiedendo una logica di analisi e convalida distinta sul backend dell'RP.

Per le entità che cercano di emettere credenziali digitali e fornire applicazioni wallet per i titolari, l'ambiente del sistema operativo gioca un ruolo cruciale.

Gli emittenti di wallet si trovano di fronte a scenari nettamente diversi su iOS e Android per quanto riguarda la creazione di wallet, l'integrazione con il sistema e l'interazione con la Digital Credentials API.

• Android: Offre generalmente un ecosistema più aperto. L'Android Credential Manager include una Holder API che consente alle applicazioni native di terze parti di registrarsi come titolari di credenziali. Queste app titolari registrate possono quindi partecipare ai flussi di presentazione delle credenziali mediati dal sistema, rispondendo alle richieste della Digital Credentials API (tramite Chrome) o dei verificatori di app native. Android supporta anche esplicitamente OpenID4VCI per l'emissione di credenziali, consentendo agli utenti di scegliere un wallet di terze parti compatibile per ricevere le credenziali appena emesse. Sebbene le app native siano il focus principale per le piene capacità di titolare di credenziali, il sistema è progettato per una partecipazione più ampia.

• iOS: Apple mantiene un controllo più stretto sul suo ecosistema. Sebbene le app wallet di terze parti possano esistere sull'App Store, la loro capacità di integrarsi profondamente come titolari di credenziali a livello di sistema per credenziali ad alta affidabilità (come le mDL destinate ad Apple Wallet) è spesso soggetta ai processi e ai diritti specifici di Apple. L'aggiunta di un documento d'identità ad Apple Wallet, ad esempio, è un flusso controllato che coinvolge le autorità di emissione statali e la verifica di Apple. Per la Digital Credentials API in Safari, le interazioni saranno probabilmente gestite da vicino, con un focus primario su org.iso.mdoc presentato da fonti autorizzate, vale a dire Apple Wallet stesso e le app di provider di documenti di terze parti registrate.

L'approccio dell'"ecosistema chiuso" di Apple è ben consolidato e la loro implementazione delle credenziali digitali non fa eccezione. Tuttavia, WWDC25 ha chiarito il percorso per la partecipazione di terze parti.

Mentre Apple Wallet è il provider principale e integrato per credenziali come le mDL statali, Apple ha introdotto il framework IdentityDocumentServices per le app native di iOS. Ciò consente agli sviluppatori di terze parti di creare applicazioni in grado di fornire e presentare i propri documenti d'identità.

Per partecipare al flusso web, un'app nativa deve:

1. Registrare i Documenti: Usare IdentityDocumentProviderRegistrationStore per registrare gli mdocs che l'app gestisce con il sistema operativo. Questa registrazione include il tipo di documento e le autorità di certificazione attendibili per la firma delle richieste.
2. Implementare un'Estensione dell'App: Aggiungere un'estensione UI App "Identity Document Provider" al progetto. Questa estensione è responsabile della visualizzazione dell'interfaccia di autorizzazione all'utente quando l'app viene selezionata durante un flusso di verifica basato sul web.

Ciò significa che, sebbene la creazione di un wallet completamente integrato su iOS richieda la creazione di un'applicazione nativa e l'utilizzo dei framework specifici di Apple — non tecnologie web come le PWA — esiste un meccanismo chiaro, sebbene strettamente controllato, per le app di terze parti di agire come provider di documenti insieme ad Apple Wallet. Ciò conferma che l'interazione con la Digital Credentials API in Safari è gestita dal sistema operativo, che quindi inoltra le richieste ad Apple Wallet o a qualsiasi altra app provider di documenti registrata e autorizzata.

La Digital Credentials API rappresenta un progresso significativo nello spazio dell'identità digitale, offrendo un approccio più sicuro, incentrato sull'utente e rispettoso della privacy alla verifica dell'identità e alla presentazione delle credenziali. Con Chrome 141 (30 settembre 2025) e Safari 26 (15 settembre 2025) che ora offrono supporto stabile, l'API è passata da sperimentale a pronta per la produzione. Man mano che l'ecosistema continua a evolversi, è fondamentale che sia i relying parties sia gli emittenti di wallet si adattino e abbraccino il potenziale di questa nuova tecnologia. Manterremo questo articolo aggiornato man mano che il panorama cambia.

Tuttavia, le sfide rimangono. Raggiungere una vera interoperabilità globale tra diversi formati di credenziali, protocolli e implementazioni di wallet è un'impresa significativa. Affrontare le valide preoccupazioni sollevate da organizzazioni come Mozilla riguardo alla privacy, all'esclusione e all'autonomia dell'utente è fondamentale per garantire che queste tecnologie servano l'umanità. Gli approcci divergenti — l'implementazione protocol-agnostic di Chrome contro il focus solo-mdoc di Safari — significano che i relying parties e gli emittenti di wallet devono navigare in un panorama a doppio protocollo per il prossimo futuro.