API Digital Credentials (2025): Supporto di Chrome e Safari (WWDC25)

Ultimo aggiornamento: 15 luglio 2025 (post-WWDC25)

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

Il mondo delle credenziali digitali si sta muovendo velocemente. Ecco una panoramica degli sviluppi chiave e delle proiezioni:

Le credenziali digitali sono un argomento molto caldo nel settore dell'identità in questo momento. Man mano che le nostre vite diventano sempre più connesse con il mondo digitale, la necessità di modi sicuri, incentrati sull'utente e che tutelino la 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 richiesta di soluzioni più robuste è palpabile.

In questo articolo, discuteremo lo stato attuale dell'API Digital Credentials, 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 i relying party che per gli issuer 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. Se da un lato Internet ha facilitato una connettività e uno scambio di informazioni senza precedenti, dall'altro ha aperto nuove strade per la falsa rappresentazione e la frode.

In alcuni paesi sono emerse soluzioni, principalmente guidate da consorzi bancari 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.

In molte regioni, la soluzione di ripiego per la verifica dell'identità 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, seguita dalla più recente ascesa della scansione automatizzata dei documenti e dei controlli di vitalità (liveness check). Nonostante i loro progressi, questi metodi presentano notevoli svantaggi. Possono richiedere molto tempo, essere soggetti a errori umani o pregiudizi e sono stati spesso esposti come vulnerabili a falsificazioni sofisticate.

La sfida sta aumentando drasticamente con l'avvento dei deepfake, delle tecniche avanzate di impersonificazione basate sull'IA e degli 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 seria, in particolare per le istituzioni finanziarie e qualsiasi servizio che richieda solidi processi di Know Your Customer (KYC). Questo scenario di minaccia crescente sottolinea l'urgente necessità di meccanismi di identità e verifica online più sicuri e verificabili crittograficamente.

Want to try digital credentials yourself in a demo?

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à.

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

1. Issuer: Un'entità (ad 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. Holder: Il soggetto delle informazioni (cioè l'utente) che riceve la credenziale dall'issuer e la conserva in un wallet digitale. L'holder controlla quando e quali informazioni della credenziale vengono condivise.
3. Verifier (o Relying Party): Un'entità (ad es. un sito web, un servizio online) che deve verificare determinate informazioni sull'holder per concedere l'accesso a un servizio o a una risorsa. Il verifier richiede le informazioni necessarie all'holder.

Questo modello a tre parti è importante perché mira a dare all'utente (l'holder) il 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. L'holder decide quali informazioni condividere da una credenziale per una transazione specifica, invece di rivelare l'intera credenziale.

Un aspetto fondamentale di questi sistemi è il coinvolgimento di coppie di chiavi crittografiche. L'issuer firma digitalmente la credenziale, garantendone l'autenticità e l'integrità. L'holder, 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 verifier. Questo tipicamente comporta che il verifier presenti una challenge (un dato casuale) che il wallet dell'holder firma usando la chiave privata associata alla credenziale. Il verifier 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, detenzione e verifica tramite challenge 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 es. "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 per l'Identità Digitale dell'UE per firme legalmente vincolanti), il focus qui, in particolare per l'API Digital Credentials, è sull'asserzione di identità e sulla verifica degli attributi per le interazioni online, non principalmente su queste più ampie funzionalità di firma.

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 stesso a come viene presentato a un utente in un browser web. Questo articolo si concentra principalmente sull'API Digital Credentials, che opera al livello di presentazione.

Terminologia di base:

• 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.
• Verifiable Credential: Un tipo di credenziale digitale, definita dal W3C VC Data Model. Aggiunge la prova di manomissione e la prova crittografica, e vive sempre in un mondo a tre parti: issuer → holder → verifier.
• API Verifiable Credential: Un'interfaccia di servizio REST/HTTP per emettere, archiviare, presentare e verificare le VC tra sistemi di back-end (issuer, wallet, verifier).
• API Digital Credentials (DC API): Un'API a livello di browser/sistema operativo (JavaScript + infrastruttura nativa) 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, all'API VC come a una specifica di back-end e all'API DC come all'implementazione di front-end che presenta le credenziali al Web. Tutto ciò che si trova sopra il livello 1 (livello del modello di dati) è agnostico rispetto al formato; tutto ciò che si trova sotto dipende dal formato della credenziale.

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

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

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

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 di back-end: Risolto dall'API VC.
• Handshake Wallet ↔ Sito web che preserva la privacy: Risolto dall'API DC.
• Diversi livelli di fiducia / tipi di documento (ID governativo vs. certificato di corso): Risolto utilizzando il formato giusto (ISO mDoc per ID ad alta affidabilità; W3C VC per attestazioni generali) sotto l'API DC.

Punti chiave:

1. "Credenziale digitale" è il termine generico.
2. Una Verifiable Credential è un tipo di credenziale digitale con verificabilità crittografica integrata.
3. L'API VC è l'infrastruttura server-to-server per le operazioni del ciclo di vita delle VC.
4. L'API Digital Credentials è il ponte tra browser e wallet che finalmente consente a queste credenziali di fluire senza problemi nelle app Web, indipendentemente dal formato concreto in cui si trovano.
5. I tre elementi 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 sull'API Digital Credentials e sul suo stato attuale.

In quanto componente cruciale al livello di presentazione, l'API Digital Credentials è uno standard web attualmente in fase di sviluppo per fornire un modo sicuro e standardizzato ai siti web per richiedere e ricevere informazioni sull'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 ufficiale della specifica può essere trovata qui: https://w3c-fedid.github.io/digital-credentials/.

Nel 2025, l'API è ancora descritta come in fase di cambiamenti significativi. Questo evidenzia la sua fase di sviluppo attivo. Nonostante ciò, il suo potenziale è notevole. Chrome è stato il primo a rilasciare qualcosa di pubblico, con il suo Origin Trial, che consente agli sviluppatori di sperimentare le sue capacità. Chrome supporta anche questa funzionalità nativamente su Android attraverso il suo sistema Credential Manager e ha recentemente pubblicato anche il supporto per l'uso dell'API Digital Credentials Cross-Device su desktop.

L'API estende l'esistente API Credential Management abilitando le richieste di credenziali digitali tramite navigator.credentials.get(). Secondo l'Explainer dell'API Digital Credentials del W3C FedID WG (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md), l'API è tornata a utilizzare questa interfaccia consolidata invece della navigator.identity precedentemente proposta. 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() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

Questo esempio è tratto da qui.

L'API Digital Credentials agisce essenzialmente come un wrapper o un 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 destinati a essere opachi (crittografati) per il browser stesso, con la decrittazione e l'interpretazione gestite dal relying party e dal wallet/holder.

L'API Digital Credentials è 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 attuali implementazioni e discussioni: org.iso.mdoc (derivato da ISO 18013-5 e la sua estensione ISO 18013-7 "Annex 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" è specificamente definita in ISO/IEC TS 18013-7 (Annex C) per l'uso con API come l'API Digital Credentials.

• Modello di Dati: Gli mdoc hanno una struttura dati strettamente 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 funzionalità di sicurezza crittografica, tra cui l'autenticazione dell'issuer, il binding al dispositivo, l'autenticazione dell'holder (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 (ad es. controlli stradali, verifica dell'età per beni soggetti a restrizioni) che online (ad es. accesso a servizi governativi, verifica dell'identità a distanza per l'apertura di un conto bancario).

• 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 governative. All'inizio del 2025, OpenID4VP è in fase di bozza avanzata (ad es. bozza 28 ad aprile). Anche OpenID4VCI sta maturando.
• Modello di Dati: OpenID4VP/VCI sono progettati per essere agnostici rispetto al formato della credenziale. Possono trasportare Verifiable Credentials (VC) W3C in formato JSON/JSON-LD o JWT, mdoc, SD-JWT e altri formati. Il modello di interazione prevede una Richiesta di Autorizzazione dal Verifier (RP) e una risposta dal Wallet dell'Holder 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 (ad es. diplomi di studio, certificazioni professionali), attestazioni di appartenenza e altro ancora. Sono adatti per le interazioni online in cui un relying party deve verificare le attestazioni di vari issuer.

È importante riconoscere che 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 per l'Identità Digitale Europea (EUDI) è un'importante 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 Verifiable Credentials W3C, utilizzando OpenID4VP e OpenID4VCI per i flussi di presentazione ed emissione. L'implementazione di riferimento include il supporto per OpenID4VP che trasferisce mDoc e OpenID4VCI per l'emissione di PID e mDL nei formati mDoc e SD-JWT-VC. Questo doppio supporto da parte di un progetto di così larga scala sottolinea l'importanza di entrambe le famiglie di protocolli. Tuttavia, questa direzione non è priva di critiche, poiché alcuni osservatori notano che l'API Digital Credentials, fortemente influenzata da aziende "Big Tech" 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 nei forum della comunità, ad esempio in questa discussione su GitHub.

Il panorama dei browser per l'API Digital Credentials sta ancora prendendo forma, con notevoli differenze nell'approccio e nei livelli di supporto.

Google Chrome, in particolare su Android, è stato uno dei primi ad adottare e implementare l'API Digital Credentials. Hanno eseguito Origin Trial e l'hanno integrata con il Credential Manager nativo di Android. L'implementazione di Chrome sfrutta principalmente OpenID4VP come protocollo per richiedere le credenziali tramite la chiamata API navigator.credentials.get(). Sebbene OpenID4VP sia di per sé agnostico rispetto al formato e possa trasportare org.iso.mdoc o Verifiable Credentials W3C come payload, l'enfasi pratica di Google sembra essere sul flusso OpenID4VP come meccanismo di trasporto. Il Credential Manager di Android supporta anche nativamente OpenID4VP per la presentazione e OpenID4VCI per l'emissione. Ciò consente alle app Android di agire come detentori e verificatori di credenziali utilizzando questi standard.

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

Come avevamo correttamente anticipato, il WWDC25 ha confermato questa strategia. Alla conferenza, Apple ha annunciato ufficialmente il supporto per l'API in Safari 26 (in uscita con iOS 26 e altri aggiornamenti del sistema operativo nell'autunno 2025), confermando che la loro implementazione supporta esclusivamente il protocollo org.iso.mdoc per la presentazione.

Questo è stato dettagliato nella sessione del WWDC25 Verify identity documents on the web. L'API consente ai siti web di richiedere informazioni verificabili da documenti d'identità, come una patente di guida, archiviati in Apple Wallet o in app di fornitori 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 Annex C. Non c'è supporto per OpenID4VP nell'implementazione dell'API Digital Credentials di Safari.
• 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 convalida 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 fornitori di documenti implementando il nuovo framework IdentityDocumentServices e un'estensione dell'app.

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

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

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 espresso formalmente una "posizione negativa" sulla proposta dell'API Digital Credentials così com'è attualmente. Le loro preoccupazioni sono ampie e radicate nella loro missione di proteggere la privacy dell'utente, l'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 dai servizi e dalle comunità online. Le credenziali emesse dal governo, un caso d'uso primario, potrebbero non allinearsi con la scelta di presentazione dell'identità di un individuo.
• Problemi di Interoperabilità: Preoccupazioni per una proliferazione di formati di credenziali che portano a un ecosistema frammentato piuttosto che a uno universalmente interoperabile.
• Divulgazione Selettiva: Timori che i benefici per la privacy della divulgazione selettiva possano essere compromessi se non implementati con forti garanzie di non collegabilità, o se gli utenti non comprendono appieno cosa 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 la 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 piuttosto che in sedi potenzialmente meno trasparenti), il Consiglio ha raccomandato al Working Group di lavorare attivamente per mitigare questi potenziali danni.

Tabella 1: Supporto Browser per API e Protocolli Digital Credentials

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

Dato che Safari, con la sua significativa quota di mercato, darà probabilmente la priorità alle interazioni dirette con org.iso.mdoc attraverso l'API Digital Credentials, e Chrome/Android stanno enfatizzando OpenID4VP (che può trasportare mdoc o altri formati di Verifiable Credential), 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 potenzialmente parametri di protocollo diversi ("org.iso.mdoc" o "openid4vp") basandosi sul rilevamento del browser o sulle capacità dello user agent.
2. Elaborare risposte che possono arrivare direttamente in formato mdoc 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 che quelli su Android/Chrome, 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 Party devono essere acutamente consapevoli che anche quando richiedono la stessa informazione logica (ad es. "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 coinvolgono l'issuer che crea hash salati di singoli elementi di dati. Il wallet dell'holder rivela quindi solo gli elementi richiesti insieme ai loro salt, consentendo al verifier 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 le singole attestazioni di cui hanno bisogno. Il wallet costruisce quindi una Verifiable Presentation 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 best practice sulla 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 desiderano emettere credenziali digitali e fornire applicazioni wallet per gli holder, l'ambiente del sistema operativo gioca un ruolo cruciale.

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

• Android: Generalmente offre un ecosistema più aperto. L'Android Credential Manager include un'API Holder che consente alle applicazioni native di terze parti di registrarsi come detentori di credenziali. Queste app holder registrate possono quindi partecipare ai flussi di presentazione delle credenziali mediati dal sistema, rispondendo alle richieste dell'API Digital Credentials (tramite Chrome) o dei verifier 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 primario per le piene capacità di detentore 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 detentori 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 ID ad Apple Wallet, ad esempio, è un flusso controllato che coinvolge le autorità di emissione statali e la verifica di Apple. Per l'API Digital Credentials in Safari, le interazioni saranno probabilmente gestite da vicino, con un focus primario su org.iso.mdoc presentato da fonti autorizzate, ovvero Apple Wallet stesso e le app di fornitori di documenti di terze parti registrate.

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

Mentre Apple Wallet è il fornitore principale e integrato per credenziali come le mDL statali, Apple ha introdotto il framework IdentityDocumentServices per le app native 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: Utilizzare IdentityDocumentProviderRegistrationStore per registrare gli mdoc che l'app gestisce con il sistema operativo. Questa registrazione include il tipo di documento e le autorità di certificazione attendibili per la firma della richiesta.
2. Implementare un'Estensione dell'App: Aggiungere un'estensione dell'app UI "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 di tecnologie web come le PWA — esiste un meccanismo chiaro, sebbene strettamente controllato, per le app di terze parti per agire come fornitori di documenti insieme ad Apple Wallet. Ciò conferma che l'interazione con l'API Digital Credentials in Safari è gestita dal sistema operativo, che quindi invia le richieste ad Apple Wallet o a qualsiasi altra app fornitrice di documenti registrata e autorizzata.

L'API Digital Credentials rappresenta un progresso significativo nel settore dell'identità digitale, offrendo un approccio più sicuro, incentrato sull'utente e rispettoso della privacy alla verifica dell'identità e alla presentazione delle credenziali. Man mano che l'ecosistema si evolve, è fondamentale che sia i relying party che gli issuer 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 è di fondamentale importanza per garantire che queste tecnologie servano l'umanità. L'attuale frammentazione nel supporto dei browser e nell'enfasi sui protocolli significa che i relying party e gli issuer di wallet devono, per il momento, navigare in un panorama complesso.