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

Ultimo aggiornamento: 26 Marzo 2026

Una rapida panoramica del supporto alla 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 Ottobre 2025?

• Cambio nella governance del protocollo: Il W3C FedID WG ha eliminato il registro aperto dei protocolli durante il TPAC (Nov 2025) e ora definisce rigidamente i protocolli supportati direttamente nelle specifiche: OpenID4VP, OpenID4VCI e ISO 18013-7 Annex C. L'API non è più un semplice "canale passivo".
• Emissione in arrivo: Chrome 143 ha lanciato un Origin Trial per l'emissione di credenziali tramite navigator.credentials.create(), espandendo l'API oltre la sola presentazione.
• Firefox sta implementando: Nonostante una posizione negativa sugli standard invariata, Mozilla ha introdotto il codice base per la DC API in Firefox 149, con lavori sulla UX ancora in corso.
• Mandato condizionale UE: Il Framework di Riferimento dell'Architettura EUDI (Topic F) ora richiede condizionalmente il supporto DC API per tutti i wallet degli stati membri.
• Adozione nel mondo reale: La DMV della California ha aggiunto il supporto DC API alla sua piattaforma OpenCred (Feb 2026).

Le credenziali digitali sono un argomento molto caldo nel settore dell'identità al momento. Man mano che le nostre vite diventano sempre più connesse con il regno 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, ci proponiamo di discutere 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 i relying party che per gli issuer (emittenti) di wallet che navigano in questo panorama in rapida evoluzione.

Provare l'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 il raggiro e la frode.

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

Il ripiego 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 combinate con il caricamento di documenti sono diventate un'alternativa più digitale, seguite dalla più recente ascesa della scansione automatizzata dei documenti e dei controlli di esistenza in vita (liveness checks). Nonostante i progressi, questi metodi presentano notevoli svantaggi: possono richiedere molto tempo, essere inclini all'errore umano o ai pregiudizi, e sono stati frequentemente esposti come vulnerabili a falsificazioni sofisticate.

La sfida si sta intensificando drammaticamente con l'avvento dei deepfake, delle tecniche avanzate di impersonificazione guidate dall'AI 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'AI, 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 di Know Your Customer (KYC) standard. Questo panorama di minacce in escalation sottolinea l'urgente necessità di meccanismi di identità e verifica online più sicuri e crittograficamente verificabili.

Want to experience digital credentials in action?

Try Digital Credentials

Per capire come operano le credenziali digitali è necessario guardare agli attori chiave coinvolti e ai diversi strati tecnologici che abilitano le loro funzionalità.

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

1. Issuer (Emittente): Un'entità (es. governo, università, datore di lavoro) che è autorevole per certe informazioni su un soggetto e può emettere una credenziale digitale che attesta tali informazioni.
2. Holder (Titolare): Il soggetto delle informazioni (ovvero l'utente) che riceve la credenziale dall'issuer e la conserva in un digital wallet. L'holder controlla quando e quali informazioni della credenziale vengono condivise.
3. Verifier (o Relying Party): Un'entità (es. un sito web, un servizio online) che deve verificare certe informazioni sull'holder per concedere l'accesso a un servizio o risorsa. Il verifier richiede le informazioni necessarie all'holder.

Questo modello a tre parti è importante perché mira a mettere l'utente (holder) al controllo dei propri dati. A differenza dei sistemi di identità tradizionali dove i dati potrebbero essere archiviati centralmente o condivisi tra parti senza l'intermediazione diretta dell'utente, questo modello enfatizza il consenso dell'utente e la selective disclosure (divulgazione selettiva). L'holder decide quali pezzi di informazione condividere da una credenziale per una specifica transazione, piuttosto che 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, usa la propria chiave privata, spesso protetta all'interno del proprio digital wallet (che è protetto dall'hardware del dispositivo), per provare il controllo sulla credenziale e per autorizzare la sua presentazione a un verifier. Questo tipicamente comporta che il verifier presenti una sfida (un dato casuale) che il wallet dell'holder firma usando la chiave privata associata alla credenziale. Il verifier può quindi usare 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 attraverso sfide crittografiche sono comuni a diverse tecnologie sottostanti.

Questo articolo si concentra sulla verifica delle credenziali digitali e sul principio della selective disclosure, che permette agli utenti di provare attributi specifici (es. "Ho più di 18 anni", "Possiedo una patente valida") senza rivelare l'intero documento sorgente. Sebbene i sistemi sottostanti per le credenziali digitali possano supportare funzionalità come le Firme Elettroniche Qualificate (QES) e capacità di firma remota (come visto in soluzioni complete come l'EU Digital Identity Wallet per firme legalmente vincolanti), il focus qui, in particolare per la Digital Credentials API, è sull'asserzione dell'identità e la 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 livelli. Ogni livello indirizza 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 sulla Digital Credentials API, che opera al livello di presentazione.

Terminologia Chiave:

• Credenziale digitale: Qualsiasi credenziale leggibile da una macchina (PDF con codice a barre, ISO mDL, W3C VC, SD-JWT, ecc.). "Digitale" non implica nulla sulla verificabilità crittografica.
• Verifiable Credential (VC): Un tipo di credenziale digitale, definita dal W3C VC Data Model. Aggiunge evidenza di manomissione e prova crittografica, e vive sempre in un mondo a tre parti: issuer → holder → verifier.
• Verifiable Credential API: Un'interfaccia di servizio REST/HTTP per emettere, archiviare, presentare e verificare VC tra sistemi back-end (issuers, wallet, verifiers).
• Digital Credentials API (DC API): Un'API browser / sistema operativo (JavaScript + infrastruttura nativa) che permette a un sito web di chiedere al wallet lato dispositivo dell'utente di presentare qualsiasi credenziale digitale supportata (VC, ISO mDoc, SD-JWT…) in modo rispettoso della privacy.

Pensa alle VC come a un modello dati, alla VC API come a una specifica back-end, e alla DC API come all'implementazione front-end che presenta le credenziali al Web. Tutto ciò che sta sopra il livello 1 (Livello Data-model) è agnostico rispetto al formato; tutto ciò che sta sotto dipende dal formato della credenziale.

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

Il diagramma seguente illustra come questi livelli lavorano insieme in uno scenario reale.

Nota come il dato è una VC, il trasporto sul Web è la DC API, il protocollo di scambio sottostante è OpenID4VP, e il controllo lato server usa la VC API.

Perché esiste questa divisione:

• Modello dati interoperabile (prove crittografiche, selective disclosure): 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 (ID governativo vs. certificato di corso): Risolto usando il formato giusto (ISO mDoc per ID ad alta garanzia; W3C VC per claim generali) sotto la DC API.

Punti chiave:

1. "Credenziale digitale" è il termine ombrello.
2. Verifiable Credential è un tipo di credenziale digitale con verificabilità crittografica integrata.
3. VC API è l'infrastruttura server-to-server per le operazioni del ciclo di vita sulle VC.
4. Digital Credentials API è il ponte browser-to-wallet che permette finalmente a quelle credenziali di fluire agevolmente nelle Web-app, qualsiasi sia il formato concreto in cui si trovano.
5. I tre pezzi sono complementari, non in competizione—siedono a diversi livelli dello stesso stack e insieme abilitano un'identità sicura e centrata sull'utente sul Web aperto.

Avendo esplorato i partecipanti e l'architettura a livelli complessiva delle credenziali digitali, questo articolo andrà ora più in profondità nel livello di presentazione, concentrandosi specificamente sulla Digital Credentials API e il suo stato attuale.

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

Ad Ottobre 2025, l'API è stata rilasciata in versioni stabili sia su Chrome 141 (30 Settembre 2025) che su Safari 26 (15 Settembre 2025). L'implementazione di Chrome supporta sia OpenID4VP che ISO 18013-7 Annex C, mentre Safari supporta esclusivamente il protocollo org-iso-mdoc.

Importante (Aggiornamento Marzo 2026): La relazione dell'API con i protocolli è cambiata radicalmente. Al TPAC di Novembre 2025, il W3C FedID WG ha raggiunto il consenso per eliminare il registro aperto dei protocolli e invece inserire direttamente una lista finita di protocolli supportati nelle specifiche: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc (per la presentazione), e openid4vci-v1 (per l'emissione). Ci si aspetta che gli user agent rifiutino protocolli non in lista. Questo rende il Working Group un guardiano di fatto per future aggiunte di protocolli — un compromesso deliberato per abilitare una revisione olistica di sicurezza e privacy di tutto ciò che fluisce attraverso l'API (vedi la Working Draft attuale).

Le specifiche ora coprono anche l'emissione di credenziali tramite navigator.credentials.create(). Chrome 143 ha lanciato un Origin Trial per questo, permettendo ai siti web di innescare flussi di approvvigionamento del wallet usando OpenID4VCI. Tuttavia, una vulnerabilità di binding nella selezione del wallet — dove un'app wallet malevola può intercettare i codici di pre-autorizzazione all'emissione — rimane una preoccupazione aperta. Gli enti governativi emittenti hanno indicato che non adotteranno l'emissione mediata dal browser finché questo non sarà risolto.

Chrome supporta la presentazione nativamente su Android attraverso il suo sistema Credential Manager e supporta anche la Digital Credentials API Cross-Device su desktop via CTAP/BLE (scambio con QR), con la risposta offuscata al browser.

L'API estende la Credential Management API esistente abilitando le richieste per credenziali digitali attraverso 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 usare questa interfaccia consolidata piuttosto che la precedentemente proposta navigator.identity. 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 usando OpenID4VP:

async function requestCredential() {
    // Verifica il supporto per la Digital Credentials API
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // Questi parametri sono tipicamente recuperati dal backend.
            // Definiti staticamente qui a scopo illustrativo per l'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 Presentation Exchange, omessa per brevità
                    },
                },
            };
 
            // crea un Abort Controller
            const controller = new AbortController();
 
            // Chiama la Digital Credentials API usando 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 decifrazione e la verifica
            // Omesso per brevità
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // scenario di fallback, solo illustrativo
        alert("La Digital Credentials API non è supportata in questo browser.");
    }
}

Questo esempio è preso da qui.

La Digital Credentials API agisce essenzialmente come un wrapper o intermediario sicuro. Permette al browser di mediare la richiesta per le informazioni sull'identità, sfruttando le capacità del sistema operativo sottostante di 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 autorizzare il suo rilascio, migliorando la sicurezza e la privacy assicurando il consenso dell'utente e prevenendo che i siti web accedano silenziosamente a dati sensibili. I dati effettivi della credenziale nella risposta sono intesi per essere opachi (crittografati) per il browser stesso, con decifrazione e interpretazione gestite dal relying party e dal wallet/holder.

La Digital Credentials API era stata originariamente progettata per essere completamente agnostica rispetto ai protocolli, agendo come un "canale passivo" con un registro aperto per la registrazione di qualsiasi protocollo. Tuttavia, a partire da Gennaio 2026, le specifiche ora nominano esplicitamente i protocolli supportati — ci si aspetta che gli user agent rifiutino quelli non in lista. Le due famiglie principali di protocolli attualmente inserite direttamente (hardcoded) nelle specifiche sono: 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 dati e al modello di interazione per documenti mobili, principalmente Patenti di Guida mobili (mDLs), standardizzato dall'International Organization for Standardization (ISO) e dall'International Electrotechnical (IEC). Lo standard fondamentale è ISO/IEC 18013-5, che definisce l'applicazione mDL, la struttura dati e i protocolli per la presentazione di persona (prossimità) usando tecnologie come NFC, Bluetooth, o codici QR. ISO/IEC 18013-7 estende questo per abilitare la presentazione online/remota di mDLs. La stringa di protocollo "org.iso.mdoc" è specificamente definita in ISO/IEC TS 18013-7 (Annex C) per l'uso con API come la Digital Credentials API.

• Data Model: gli mdocs hanno una struttura dati rigorosamente definita basata su CBOR (Concise Binary Object Representation) per compattezza ed efficienza. Specifica namespace ed elementi dati per attributi comuni delle patenti di guida e supporta forti caratteristiche di sicurezza crittografica, inclusa l'autenticazione dell'emittente, il binding del dispositivo, l'autenticazione del titolare (via ritratto), la crittografia della sessione e la selective disclosure.

• Casi d'Uso Tipici: Principalmente documenti d'identità emessi dal governo come patenti e carte d'identità nazionali. È progettato per scenari ad alta garanzia, sia di persona (es. controlli stradali, verifica età per beni riservati) che online (es. accesso a servizi del governo, verifica dell'identità remota per apertura 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 verifiable credentials. Questi sono standard aperti mirati a un'ampia interoperabilità per vari tipi di credenziali, non solo governative. A inizio 2025, OpenID4VP è in fasi avanzate di bozza (es. draft 28 ad Aprile). Anche OpenID4VCI sta maturando.
• Data Model: OpenID4VP/VCI sono progettati per essere agnostici rispetto al formato della credenziale. Possono trasportare W3C Verifiable Credentials (VCs) in formati JSON/JSON-LD o JWT, mdocs, SD-JWTs e altri formati. Il modello di interazione comporta una Richiesta di Autorizzazione dal Verifier (RP) e una risposta dal Wallet del Titolare contenente un vp_token (Verifiable Presentation Token). La selective disclosure è tipicamente gestita usando 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, inclusa verifica dell'identità, fornitura di prova di qualifiche (es. diplomi educativi, certificazioni professionali), attestazioni di appartenenza e altro. Sono ben adatti per interazioni online dove un relying party deve verificare claim da vari issuers.

È importante riconoscere che questi non sono sempre mutualmente esclusivi. OpenID4VP può, ad esempio, essere usato 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.

L'European Union Digital Identity (EUDI) Wallet è un'importante iniziativa che mira a fornire a tutti i cittadini e residenti UE un digital wallet sicuro per documenti d'identità e attestazioni. L'architettura e il framework di riferimento dell'EUDI Wallet pianificano esplicitamente di supportare sia mdoc (particolarmente per le Patenti Mobili) che W3C Verifiable Credentials, utilizzando OpenID4VP e OpenID4VCI per i flussi di presentazione ed emissione. L'implementazione di riferimento include supporto per OpenID4VP che trasferisce mDocs e OpenID4VCI per emettere PID e mDLs in formati mDoc e SD-JWT-VC. Questo doppio supporto da un progetto su così larga scala sottolinea l'importanza di entrambe le famiglie di protocolli.

Aggiornamento Marzo 2026: L'impegno dell'UE verso la Digital Credentials API è diventato più concreto. L'EUDI Architecture Reference Framework (ARF) Topic F ora richiede condizionalmente che le EUDI Wallet Units e i Relying Parties supportino la DC API per la presentazione remota e i flussi di emissione attestati. Le condizioni includono che la DC API raggiunga lo stato di Raccomandazione W3C e soddisfi le aspettative su funzionalità, neutralità browser/OS, privacy e protezione da denial-of-service. Il European Wallet Consortium (EWC) ha incorporato casi di test DC API nel suo programma di test di conformità, e il consorzio NOBID ha completato piloti di pagamento usando OpenID4VP — lo stesso protocollo che ora trasporta la DC API.

Tuttavia, questa direzione non è priva di critiche, poiché alcuni osservatori notano che la Digital Credentials API, pesantemente influenzata dalle "US Bigtech", potrebbe diventare profondamente incorporata nelle specifiche finali dell'EUDI Wallet. Sono state sollevate preoccupazioni sulla potenziale influenza di entità non-UE su un pezzo critico dell'infrastruttura UE, come discusso in forum della community come questa discussione GitHub. Separatamente, la decisione di inserire rigidamente il riferimento ISO 18013-7 nelle specifiche ha attirato un'obiezione da Ping Identity, sostenendo che referenziare normativamente una specifica a pagamento confligge con i principi dell'open web — una preoccupazione che potrebbe emergere come obiezione formale quando le specifiche transiteranno a Candidate Recommendation.

Il panorama dei browser per la Digital Credentials API ha ora preso forma, con Chrome 141 e Safari 26 che hanno rilasciato il supporto stabile a Settembre 2025. Ci sono notevoli differenze nell'approccio e nei 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 Annex C (mdoc online). Il desktop supporta la presentazione cross-device da wallet mobili via un canale supportato da CTAP/BLE (scambio QR), con la risposta opaca al browser. La forma dell'API si è spostata su navigator.credentials.get(); parametri rinominati: providers → requests, request → data.

Rilevamento Funzionalità (Feature Detection):

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

Il Credential Manager di Android supporta nativamente OpenID4VP per la presentazione e OpenID4VCI per l'emissione, permettendo alle app Android di agire come credential holder e verifier usando questi standard. Google nota un crescente supporto lato wallet; Google Wallet è un early adopter, con Samsung Wallet e 1Password annunciati.

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

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

Questo è stato dettagliato nella sessione WWDC25 Verify identity documents on the web. L'API permette ai siti web di richiedere informazioni verificabili da documenti d'identità, come una patente di guida, archiviati in Apple Wallet o in app provider di documenti di terze parti.

Punti chiave dell'implementazione di Apple:

• Solo MDOC: L'API usa esclusivamente la stringa di protocollo "org-iso-mdoc", basata sullo standard ISO/IEC 18013-7 Annex C. Non c'è nessun supporto per OpenID4VP nell'implementazione 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-browser.
• Centrato sull'Utente e Sicuro: Il flusso è avviato da un gesto dell'utente e sfrutta un meccanismo di "richiesta parziale", dove il sistema operativo prima analizza e valida la richiesta in una sandbox prima di passarla all'applicazione wallet, migliorando la sicurezza.
• Estendibile alle App: Oltre ad Apple Wallet, app di terze parti possono agire come document provider implementando il nuovo framework IdentityDocumentServices e un'estensione app.
• Supporto Cross-Device: La presentazione cross-device da piattaforme non-Apple usa CTAP per la prossimità dopo uno scambio con codice QR; la risposta JS rimane crittografata/opaca per il browser.

Apple ha fornito un chiaro esempio di codice per come un relying party userebbe 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 dall'interno di un gesto utente.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Invia la risposta crittografata dal wallet al server per decifrazione e 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 errori, es. cancellazione utente.
    }
}

Questa conferma solidifica le strategie divergenti nel mercato dei browser. Mentre Chrome costruisce sul livello di trasporto flessibile di 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 aveva originariamente espresso una posizione negativa sugli standard riguardo alla Digital Credentials API. Le loro preoccupazioni, documentate in dettaglio, sono comprensive e radicate nella loro missione di proteggere la privacy dell'utente, l'agency, e assicurare un web aperto ed equo.

Le preoccupazioni chiave sollevate da Mozilla includono:

• Rischi Privacy: Potenziale per una maggiore condivisione di dati personali e una riduzione dell'anonimato online se le richieste di credenziali digitali diventassero comuni per interazioni banali.
• Esclusione Utente: Rischio che individui che non possono o scelgono di non usare credenziali digitali possano essere esclusi da servizi e comunità online. Le credenziali emesse dal governo, un caso d'uso primario, potrebbero non allinearsi con la scelta individuale di presentazione dell'identità.
• Problemi di Interoperabilità: Preoccupazioni su una proliferazione di formati di credenziali che porti a un ecosistema frammentato piuttosto che a uno universalmente interoperabile.
• Selective Disclosure: Timori che i benefici privacy della selective disclosure possano essere minati se non implementati con forti garanzie di non collegabilità (unlinkability), o se gli utenti non comprendono appieno cosa viene condiviso.
• Centralizzazione della Fiducia e Agency Utente: Paure che l'API possa portare a una maggiore centralizzazione della fiducia e una riduzione dell'agency dell'utente, perpetuando squilibri di potere sociale esistenti.

Mentre un Consiglio W3C ha respinto un'obiezione formale relativa a queste preoccupazioni (per permettere al lavoro di procedere all'interno del W3C piuttosto che in sedi potenzialmente meno trasparenti), il Consiglio ha raccomandato che il Working Group lavori attivamente per mitigare questi potenziali danni.

Aggiornamento Marzo 2026 — Implementazione in corso: Nonostante la posizione formale negativa rimanga tecnicamente invariata, Mozilla ha iniziato a implementare attivamente la Digital Credentials API. Nel Q1 2026, il supporto base DC API è arrivato in Firefox 149 (dietro un flag di preferenza), tracciato sotto il meta bug 2004828. Il codice sorgente è in mozilla-central, inclusi DigitalCredential.cpp, binding WebIDL e infrastruttura IPC. Il lavoro sui prompt di permesso desktop e Android (bug 2010091, bug 2010093) è in corso.

Tre ingegneri Mozilla — John Schanck, Martin Thomson e Benjamin VanderSloot — sono membri attivi del W3C FedID Working Group, e Schanck ha fornito feedback sostanziali informati dall'implementazione su PR chiave delle specifiche, inclusi l'algoritmo di presentazione delle credenziali e l'algoritmo di preparazione della richiesta.

Questo è uno sviluppo significativo: mentre Mozilla mantiene le sue preoccupazioni sul potenziale abuso dell'API, sta evidentemente scegliendo di modellare l'API dall'interno — attraverso sia il lavoro sulle specifiche che l'implementazione — piuttosto che cedere il design ad altri vendor di browser. Segnala che la Digital Credentials API è probabilmente su un percorso verso il supporto su tre browser, sebbene con Mozilla che spinge per barriere privacy più forti (inclusa una proposta di transparency log per le richieste di credenziali).

Tabella 1: Supporto Browser per Digital Credentials API & Protocolli (Marzo 2026)

Per le organizzazioni (Relying Parties o RP) che intendono richiedere e verificare credenziali digitali dagli 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 Annex C) attraverso la Digital Credentials API, e Chrome (rilasciato il 30 Settembre 2025) è protocol-agnostic supportando sia OpenID4VP che ISO 18013-7 Annex C (mdoc), gli RP che mirano alla più ampia portata possibile dovrebbero prepararsi a supportare interazioni basate su entrambi gli approcci.

Questo significa architettare sistemi in grado di gestire entrambi i percorsi di protocollo, come mostrato di seguito.

Sebbene questo aggiunga complessità, tentare di forzare tutti gli utenti su un unico percorso di protocollo escluderà probabilmente una porzione sostanziale della base utenti, sia quelli su iOS che quelli su Chrome/Android, a seconda del percorso scelto. Un approccio pragmatico, anche se più intenso lato sviluppo, è costruire flessibilità per gestirli entrambi.

I Relying Party devono essere acutamente consapevoli che anche quando richiedono lo stesso pezzo logico di informazione (es. "l'utente ha più di 21 anni?"), il modo in cui questo è definito in una richiesta e come viene restituito in una risposta può differire significativamente tra una query diretta mdoc e una query OpenID4VP (che potrebbe usare Presentation Exchange o DCQL).

• mdoc Selective Disclosure: org.iso.mdoc ha i suoi meccanismi per la selective disclosure, tipicamente coinvolgendo l'emittente che crea hash con "salt" di singoli elementi dati. Il wallet dell'holder rivela poi solo gli elementi richiesti insieme ai loro salt, permettendo al verifier di confermarli contro gli hash senza vedere altri dati. La richiesta per elementi specifici è legata a namespace predefiniti e identificatori di elementi dati all'interno dello standard mdoc.
• OpenID4VP Selective Disclosure: OpenID4VP usa 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. Questo permette agli RP di specificare i tipi di credenziali e i singoli claim 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 requisiti dati specifici a queste diverse strutture di protocollo. È cruciale capire le sfumature di come la selective disclosure è implementata e richiesta in ogni protocollo per assicurare che solo i dati minimi necessari siano richiesti ed elaborati, aderendo così alle best practice sulla privacy e ai principi di minimizzazione dei dati. Il formato e la struttura dei dati divulgati restituiti dal wallet potrebbero anch'essi differire, richiedendo logiche di parsing e validazione distinte sul backend dell'RP.

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

Gli emittenti di wallet affrontano panorami distintamente diversi su iOS e Android riguardo alla creazione del wallet, integrazione di sistema e interazione con la Digital Credentials API.

• Android: Offre generalmente un ecosistema più aperto. Il Credential Manager di Android include un'API Holder che permette ad applicazioni native di terze parti di registrarsi come credential holder. Queste app holder registrate possono poi partecipare ai flussi di presentazione delle credenziali mediati dal sistema, rispondendo alle richieste dalla Digital Credentials API (via Chrome) o da verifier app nativi. Android supporta anche esplicitamente OpenID4VCI per l'emissione di credenziali, permettendo agli utenti di scegliere un wallet di terze parti compatibile per ricevere credenziali appena emesse. Mentre le app native sono il focus primario per le piene capacità di credential holder, 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 credential holder a livello di sistema per credenziali ad alta garanzia (come mDLs intese per Apple Wallet) è spesso soggetta ai processi specifici e alle entitlement di Apple. Aggiungere un ID ad Apple Wallet, per esempio, è un flusso controllato che coinvolge le autorità emittenti 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 app provider di documenti di terze parti registrate.

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

Mentre Apple Wallet è il provider primario integrato per credenziali come le mDL statali, Apple ha introdotto il framework IdentityDocumentServices per app iOS native. Questo permette agli sviluppatori di terze parti di costruire applicazioni che possono approvvigionare e presentare i propri documenti d'identità.

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

1. Registrare Documenti: Usare IdentityDocumentProviderRegistrationStore per registrare gli mdocs che l'app gestisce con il sistema operativo. Questa registrazione include il tipo di documento e le certificate authority fidate per la firma della richiesta.
2. Implementare un'Estensione App: Aggiungere un'Estensione App UI "Identity Document Provider" al progetto. Questa estensione è responsabile di mostrare l'UI di autorizzazione all'utente quando l'app viene selezionata durante un flusso di verifica basato sul web.

Questo significa che mentre creare un wallet completamente integrato su iOS richiede di costruire un'applicazione nativa e usare i framework specifici di Apple—non tecnologie web come le PWA—esiste un meccanismo chiaro, sebbene strettamente controllato, per le app di terze parti per agire come provider di documenti a fianco di Apple Wallet. Questo conferma che l'interazione con la Digital Credentials API in Safari è gestita dall'OS, che poi smista le richieste ad Apple Wallet o qualsiasi altra app provider di documenti registrata e autorizzata.

La Digital Credentials API rappresenta un avanzamento significativo nello spazio dell'identità digitale, offrendo un approccio più sicuro, centrato sull'utente e rispettoso della privacy alla verifica dell'identità e presentazione delle credenziali. Con Chrome 141 (30 Settembre 2025) e Safari 26 (15 Settembre 2025) che hanno rilasciato il supporto stabile alla presentazione, e Firefox 149 che ora porta con sé il codice di implementazione base, l'API è su un percorso verso la copertura su tre browser. Terremo questo articolo aggiornato man mano che il panorama cambierà.

Il periodo da Ottobre 2025 è stato definito dalla maturazione dell'API da canale sperimentale a standard governato. L'eliminazione del registro aperto dei protocolli al TPAC (Novembre 2025) è il segnale più chiaro: il W3C FedID WG ora nomina e governa esplicitamente i protocolli supportati dall'API. Questo abilita una revisione comprensiva di sicurezza e privacy ma rende anche il Working Group un guardiano — un compromesso deliberato con cui non tutti i partecipanti sono a proprio agio (in particolare, l'obiezione sul paywall ISO da Ping Identity rimane irrisolta).

Nel frattempo, l'API si sta espandendo dalla presentazione al ciclo di vita completo: l'Origin Trial sull'emissione di Chrome 143 via navigator.credentials.create() permette ai siti web di innescare l'approvvigionamento del wallet. Ma una vulnerabilità di binding nella selezione del wallet — dove app wallet malevole possono intercettare i codici di emissione — sta bloccando l'adozione governativa di questa funzionalità.

Sul fronte regolatorio, il Topic F dell'ARF dell'UE richiede condizionalmente il supporto DC API per tutti i wallet degli stati membri EUDI, in attesa che le specifiche raggiungano la Raccomandazione W3C. L'adozione nel mondo reale sta accelerando: la DMV della California ha aggiunto il supporto DC API, e suite di test di conformità sono in sviluppo dal European Wallet Consortium.

Rimangono delle sfide. La realtà a doppio protocollo (il supporto multi-protocollo di Chrome contro il focus solo-mdoc di Safari) persiste per i relying party. La questione se i browser debbano supportare tutti i protocolli listati o solo uno è irrisolta — direttamente legata ai vincoli di piattaforma di Apple. E le considerazioni sulla privacy rimangono il singolo gap più grande che previene il progresso verso la Candidate Recommendation, con requisiti normativi per i criteri di inclusione dei protocolli ancora non scritti. Si stima che le specifiche siano a 1–2 anni dalla Raccomandazione W3C.