Chi chiede i dati non pubblici associati a un dominio può avere esigenze molto diverse: investigare un abuso, tutelare un marchio o rispondere a un’emergenza. ICANN ha aperto una consultazione su una nuova bozza per il System for Standardized Access/Disclosure (SSAD), il sistema centralizzato pensato per trasmettere queste richieste ai registrar e, in alcuni casi, ai registry. La proposta prova a definire un flusso comune senza trasformare l’identificazione del richiedente in un diritto automatico a ricevere i dati.
Leggi anche: Project Jake prova a sbloccare i dati Whois senza tornare al Far West
Una nuova bozza dopo lo stop del Board
Il progetto non riparte da zero. Nel marzo 2026 il Board ICANN ha deciso di non adottare le 18 raccomandazioni originarie sul SSAD e ha chiesto al GNSO di proseguire con un pacchetto supplementare. A monte c’è anche l’esperienza del Registration Data Request Service (RDRS), il pilota biennale i cui dati e problemi operativi sono stati analizzati da un comitato dedicato.
La bozza messa in consultazione il 10 novembre accorpa e riorganizza parti delle raccomandazioni precedenti. Il cambiamento più evidente riguarda l’accesso: non propone un accreditamento obbligatorio per ogni persona o organizzazione che voglia presentare una richiesta. Distingue invece tra richiedenti standard e richiedenti autenticati. L’autenticazione è prevista soprattutto per le richieste urgenti delle forze dell’ordine; per altri gruppi il documento contempla un percorso graduale di autenticazione federata.
Essere autenticati, però, non equivale a essere autorizzati a ottenere i dati. Serve a dare al registrar elementi sull’identità e sul ruolo del richiedente. La valutazione sostanziale rimane in capo al soggetto accreditato che riceve la richiesta: può fornire i dati, negare la disclosure motivando la decisione oppure chiedere documentazione ulteriore.
Il registrar resta il punto decisionale
Il flusso proposto instrada normalmente la domanda al registrar del dominio. Un registry che aderisse volontariamente potrebbe riceverla direttamente, oppure il richiedente potrebbe scegliere di coinvolgere entrambi quando il servizio offre questa opzione. La partecipazione dei registry non cambierebbe da sola gli obblighi sostanziali di registrar e gestore della TLD.
Qui emerge la distanza tra il SSAD e un semplice motore di ricerca dei registranti: la piattaforma dovrebbe standardizzare moduli, ricevute, instradamento e tracciamento, ma non decidere in modo automatico se rivelare i dati. La bozza lascia al registrar o al registry la responsabilità di bilanciare la richiesta con le regole applicabili e con la tutela delle persone intestatarie. È una scelta coerente con le criticità individuate nel pilota RDRS, dove la valutazione può richiedere giudizio umano e contesto.
Leggi anche: ICANN lavora sull’autenticazione delle forze dell’ordine per le richieste urgenti sui dati dei domini
Tempi diversi per urgenze e richieste ordinarie
La proposta prevede due classi. Una richiesta urgente, inviata da un richiedente autenticato e legata a minacce imminenti alla vita, a gravi lesioni, alle infrastrutture critiche o allo sfruttamento di minori, dovrebbe ricevere conferma entro due ore e una risposta entro 24 ore. In circostanze eccezionali è prevista una proroga motivata: il richiedente deve essere avvisato entro le prime 24 ore e la risposta non può slittare oltre 72 ore dalla ricezione.
Per le richieste standard, la bozza indica un riscontro di ricezione entro due giorni lavorativi e una risposta entro 30 giorni di calendario dall’accettazione della richiesta completa. Chi segnala phishing, malware o frodi dovrebbe poter indicare la finalità di tutela dei consumatori, così che il soggetto incaricato possa darle priorità rispetto alle altre pratiche ordinarie.
La classificazione non sarebbe intoccabile: il registrar potrebbe ricategorizzare una richiesta quando ritiene che non rispetti i criteri previsti, ma dovrebbe spiegare il motivo. Per una domanda urgente riclassificata come standard è contemplata la possibilità di aggiungere chiarimenti a sostegno dell’urgenza; se il richiedente considera impropria la riclassificazione, potrebbe presentare un reclamo a ICANN. Sono garanzie procedurali proposte, non una promessa di disclosure.
Privacy, abusi e perimetro della piattaforma
La bozza affronta anche i dati legati ai servizi privacy e proxy. Il richiedente dovrebbe sapere, prima dell’invio, se il registrar considera richieste relative ai dati sottostanti a tali servizi; l’informazione non anticipa l’esito di una singola pratica. Il sistema includerebbe inoltre misure contro l’uso abusivo, come richieste automatizzate incomplete o ripetute, credenziali false e invii organizzati per impedire il rispetto delle scadenze. L’uso intenso, da solo, non dovrebbe però bastare a qualificare un richiedente come abusivo: è prevista una valutazione del contesto e della proporzionalità.
Il perimetro iniziale resta quello delle registrazioni gTLD. I ccTLD che utilizzano RDAP potrebbero aderire in seguito su base volontaria, ma non sono indicati come requisito per il lancio iniziale. Anche le interfacce per utenti e operatori, il monitoraggio delle pratiche, la conservazione dei log e i report statistici sono parte del disegno operativo da completare.
La lettura Webinvest
Il punto centrale della consultazione è il compromesso tra rapidità e controllo: la bozza cerca di rendere prevedibile il percorso delle richieste, con autenticazione mirata e tempi massimi, mantenendo la decisione sui dati presso registrar e registry. Per gli operatori ciò significa un possibile standard di lavoro e rendicontazione; per chi invia richieste, una procedura più leggibile ma non un accesso garantito. Per i registranti, resta decisivo come i soggetti contrattuali valuteranno necessità, base giuridica e proporzionalità caso per caso.
La consultazione pubblica è aperta fino al 23 dicembre 2026 alle 23:59 UTC. Il team SSAD dovrà esaminare i commenti e può modificare la bozza prima di trasmettere le raccomandazioni finali al Consiglio GNSO. Finché questo percorso non sarà concluso e le regole non saranno adottate e implementate, scadenze e procedure contenute nel testo restano proposte.
Fonte: ICANN, consultazione sulle raccomandazioni supplementari SSAD; bozza delle raccomandazioni supplementari (PDF).
← Tutte le news