Introduzione

Digital Media in Italia, abbreviato in dmin.it (http://www.dmin.it/), è un gruppo interdisciplinare, aperto, senza scopo di lucro, che si propone di definire aree di interventi che consentano all’Italia di acquisire un ruolo primario nello sfruttamento del fenomeno globale “digital media”. Questi sono intesi come qualsiasi contenuto rappresentato in forma numerica che può quindi essere trasportato su reti numeriche ed elaborato da dispositivi numerici specie se programmabili.

dmin.it parte dalla considerazione che molti vantaggi offerti dai digital media rimangono potenziali perché le tecniche numeriche possono alterare in modo così sostantiale i ruoli tradizionali e le modalità operative delle catene del valore da vanificare tali vantaggi. Ed infatti i tentativi fatti negli ultimi 10 anni da molti operatori per innovare le catene del valore dei media sono per lo più falliti e le catene del valore digitali di oggi assomigliano spesso a vecchie catene analogiche rese digitali grazie all’uso di tecniche di protezione basate su tecnologie di protezione proprietarie. Anche nuove promettenti metodologie aperte di distribuzione quali le licenze Creative Commons stentano a mostrare il loro potenziale innovativo.

Il risultato è quindi un mercato “apparente” assolutamente anemico mentre il mercato “sommerso” è maggiore di ordini di grandezza rispetto all’altro. I tentativi di aumentare la pressione punitiva non hanno finora – e dmin.it non si aspetta che l’abbiano in futuro – alcun effetto misurabile, senza contare il pericolo di interventi lesivi di libertà fondamentali.

La proposta contenuta in questo documento specifica e crea le condizioni per l’uso effettivo dei tre elementi critici per il raggiungimento dell’obiettivo di “massimizzare il flusso di digital media”, e cioè:

Formato per la distribuzione controllata dei digital media (iDRM)
Accesso aperto alle reti a larga banda (iNet)
Pagamento e incasso a punti (iPay)

Questo documento contiene

Cap. 1	Introduzione
Cap. 2	Sviluppo della proposta descrive il processo seguito da dmin.it per sviluppare la proposta
Cap. 3	Caratteristiche e vantaggi della proposta analizza le caratteristiche delle 3 componenti iDRM, iNet e iPay ed i vantaggi derivanti dalla loro introduzione
Cap. 4	Scenari d’uso descrive 10 scenari d’uso innovativi abilitati dalle 3 componenti iDRM, iNet e iPay
Cap. 5	Requisiti contiene l’insieme dei requisiti che devono essere soddisfatti dalle 3 componenti iDRM, iNet e iPay
Cap. 6	Specifiche tecniche del sistema di iDRM fa riferimento alle specifiche tecniche adottate da dmin.it
Cap. 7	Proposta di legge per il supporto legislativo a iDRM è il testo integrale della proposta di legge di dmin.it per supportare l’operatività delle tecnologie iDRM
Cap. 8	Governance del sistema iDRM contiene le regole di governance del sistema iDRM
Cap. 9	Specifiche tecniche del sistema iNet fa riferimento alle specifiche tecniche del sistema iNet
Cap. 10	Proposta di legge per il supporto legislativo a iNet è il testo integrale della proposta di legge di dmin.it per supportare l’operatività delle tecnologie iNet
Cap. 11	Governance del sistema iNet è destinato a contenere le regole di governance del sistema iNet
Cap. 12	Specifiche tecniche del sistema iPay contiene le specifiche del sistema iPay
Cap. 13	Proposta di legge per il supporto legislativo a iPay è destinato a contenere il testo integrale della proposta di legge di dmin.it per supportare l’operatività del sistema iPay
Cap. 14	Governance del sistema iPay è destinato a contenere le regole di governance del sistema iPay
Cap. 15	Esempi di realizzazione pratica della proposta dmin.it contiene alcuni esempi dimostrativi e sperimentali in corso di realizzazione per verificare l’adeguatezza delle tecnologie adottate e la loro capacità effettiva di rispondere ai requisiti
Cap. 16	Bibliografia
Cap. 16	Glossario

Sviluppo della proposta

Costituitosi nel novembre 2005, alla data di prima pubblicazione di questo documento, il gruppo dmin.it ha tenuto 22 riunioni nelle città di Firenze, Genova, Milano, Roma e Torino. Tutte queste riunioni, salvo la prima la cui informazione è stata distribuita per passaparola e per posta elettronica, sono state debitamente annunciate sia sul sito web del gruppo dmin.it sia per posta elettronica alle mailing list dei primi organizzatori. La condivisione degli obiettivi di dmin.it, e cioè definire aree di interventi che consentano all’Italia di acquisire un ruolo primario nello sfruttamento del fenomeno globale” digital media”, è stata la sola condizione posta per la partecipazione alle riunioni. Il coordinamento di dmin.it avviene anche attraverso un riflettore di posta elettronica la cui partecipazione è stata finora lasciata aperta a tutti. Tutte le decisioni sono state prese dai partecipanti agli incontri sulla base di regole pubblicate sul sito web di dmin.it.

Tutti i documenti ufficiali dal gruppo sono stati pubblicati con l’invito a proporre commenti e sono tutt’ora disponibili sul sito web del gruppo dmin.it.

In una serie di riunioni con intense discussioni, dmin.it ha posto la “massimizzazione del flusso di digital media” come formulazione concreta dell’obiettivo e ha quindi definito i seguenti tre obiettivi:

Formato per la distribuzione controllata di digital media (iDRM) che dà la possibilità a tutti e quindi non solo agli attori tradizionali delle catene del valore ma anche agli autori, esecutori, interpreti e produttori di attuare nuove forme di distribuzione che possono andare dalle licenze Creative Commons alla protezione dei contenuti, ed abilita anche modalità radicalmente nuove quali i sistemi di compensazione alternativa (ACS). Il formato permette anche al consumatore di utilizzare tutti i contenuti pubblicati in Italia senza essere obbligato ad avere ad esempio un player di musica o un set top box specifico del fornitore di servizio.
Accesso aperto alle reti a larga banda (iNet) che dà la possibilità a tutti di diventare fornitori di digital media perché tutti possono accedere a tutti i contenuti forniti
Pagamento e incasso a punti (iPay) che permette a tutti, fruitori compresi, di monetizzare i propri contenuti e servizi o remunerare quelli di altri utilizzando la flessibilità del formato e l’accesso aperto alle reti a larga banda.

A settembre 2006, al termine di un processo durato 10 mesi di lavoro in 6 riunioni aperte a tutti come detto sopra e con la partecipazione di decine di esperti, dmin.it ha pubblicato una prima versione della sua proposta intitolata Proposte di azione per dare all'Italia una posizione leader nei digital media [1] dandone notizia con comunicati stampa. La proposta è stata presentata a Roma presso l’ISIMM (novembre 2006), a Milano presso Assolombarda (dicembre 2006) ed a Torino presso il Circolo dei Lettori (maggio 2007) ed è stata ripresa dagli organi di stampa ricevendo positivi riscontri.

Per essere realizzata la proposta dmin.it abbisogna però non soltanto delle specifiche delle tre componenti (formato, accesso, pagamenti) ma anche degli interventi legislativi che accompagnano l’introduzione delle tecnologie e la governance dei sistemi una volta che questi siano entrati in fase operativa. dmin.it ha quindi impiegato 5 riunioni nei 6 mesi successivi ad elaborare una versione operativa della sua proposta intitolata Specifiche funzionali, azioni normative e governance per la realizzazione della proposta dmin.it pubblicata a marzo 2007 [2]. La proposta operativa contiene una serie di scenari d’uso e di requisiti di natura sia tecnica sia, quando opportuno, giuridica che devono essere soddisfatti dai tre insiemi di tecnologie.

Seguendo la pratica comune negli ambienti di standardizzazione, dmin.it ha quindi emesso, a marzo 2007, delle richieste offrendo a chiunque la possibilità di rispondere e cioè

Richiesta di piattaforme di Digital Rights Management (DRM) e pagamento elettronico [3] in cui dmin.it chiedeva a chi avesse disponibilità di tali piattaforme di renderle disponibili a dmin.it per sperimentazione;
Richiesta di proposte di tecnologie e soluzioni per la realizzazione delle proposte dmin.it [4] in cui si richiedeva, a chiunque avesse tecnologie e soluzioni DRM soddisfacenti i requisiti allegati di proporle a dmin.it;
Richiesta di commenti alla governance dei sistemi dmin.it per la realizzazione delle proposte dmin.it [5] in cui si richiedevano commenti alle linee guida della governance;
Richiesta di commenti agli interventi normativi per la realizzazione delle proposte dmin.it [6] in cui si richiedevano commenti alle lineed guida delle proposte di interventi normativi.

A giugno 2007 dmin.it ha valutato le risposte ottenute alle sue tre richieste ed ha iniziato la redazione di documenti che coprovo i vari aspetti della proposta.

Nello stesso mese di giugno dmin.it ha costituito un gruppo operativo chiamato dmin.action. questo gruppo ha il mandato di sviluppare esempi applicativi con cui iniziare la sperimentazione della sua proposta.

Nella seguenti due riunioni di luglio e settembre 2007 dmin.it ha ulteriormente raffinato i suoi documenti ed a dicembre 2007 li ha approvati nella forma integrata di questo documento.

Per il 2008 dmin.it intende operare nelle seguenti aree

Completamento di piccole parti della proposta
Studio delle implicazioni pratiche derivanti dalla proposta dmin.it
Vari sviluppi e sperimentazioni di dmin.action
Sostenimento delle attività, specie realizzative e sperimentali, di dmin.it
Investigazione dell’uso di metadati per fruizione potenziata
Creazione di dmin.autori

Caratteristiche e vantaggi della proposta

In altri tempi sarebbe stato naturale proporre un insieme di tecnologie – formato, accesso e pagamento/incasso – da applicare uniformemente sul territorio nazionale ad esclusione di altre tecnologie competitive. Questa è una formula che ha ben contribuito al successo di altri sistemi di comunicazione sia analogici che numerici, ma quand’anche un tale approccio, anche se trovasse il consenso delle parti in causa, ci sarebbero oggi seri ostacoli a causa dell’esistenza della legislazione nazionale, dell’obbligo di recepimento di mandati comunitari e del vincolo di trattati internazionali.

D’altra parte dmin.it ritiene che rendere possibile a

un autore/esecutore/interprete/produttore di rilasciate i propri contenuti con la fiducia che esiste una larga base istallata di apparati di fruizione in grado di interpretarli,
un consumatore di accedere e fruire di una larga base di contenuti
un intermediario di potersi facilmente agganciare a catene del valore di contenuti

sia un potente fattore abilitante del raggiungimento degli obiettivi di dmin.it.

Pertanto dmin.it, invece di proporre una standardizzazione esclusiva delle tecnologie di formato, accesso e pagamento/incasso, propone di affiancare gli strumenti proposti da dimin.it a quelli che gli operatori liberamente decidono di adottare per le loro necessità. Il valore aggiunto degli strumenti dmin.it sta nel fatto che chi li adotta sa di essere interoperabile con tutti gli altri che adottano gli stessi strumenti.

Quindi la proposta dmin.it individua un punto di equilibrio fra l’esigenza degli operatori di poter scegliere le tecnologie che meglio si adattano al loro business e l’esigenza di interoperabilità dei due estremi della catena del valore – autori, esecutori, interpreti e produttori da una parte e consumatori dall’altra – e degli intermediari che vogliono basare il loro business sull’interoperabilità.

dmin.it ritiene che la sua proposta creerà un mercato omogeneo potenziale di 60 milioni di persone capace di stimolare sia l’industria culturale nazionale sia l’innovazione nel mercato dei digital media ponendo così l’industria nazionale all’avanguardia.

3. Tecnologie di formato

Per le tecnologie di formato la proposta dmin.it prevede che sia adottata a livello nazionale una specifica di Digital Rights Management interoperabile (iDRM). È importante far notare che, nonostante l’uso improprio dell’acronimo DRM da parte di molti come sinonimo di Technical Protection Measure (TPM), la “M” di “Management” significa “gestione” e quindi non necessariamete “protezione”. La ben nota definizione del National Institute of Standards and Technologies (NIST) di DRM come “Un sistema di componenti e servizi informatici che hanno l'obiettivo di distribuire e controllare contenuti ed i relativi diritti con tecniche numeriche” fa deliberatamente riferimento alla parola “controllo” e non “enforcement”. Questo significa che esistono molte tecnologie che cadono sotto l’acronimo “DRM” che vanno dal rilascio di contenuti semplicemente identificati fino, se necessario, ai contenuti soggetti a tecniche di protezione. Con iDRM dmin.it vuole riservare alla comunità nazionale questo ampio e non settario uso di tecnologie di gestione dei contenuti.

dmin.it fa sua la definizione di DRM del NIST (che è infatti riportata nel glossario). La “i” anteposta a DRM sta a significare che dmin.it sostiene SOLO la versione interoperabile, cioè standard, di DRM qui proposta. dmin.it NON sostiene (ma non è e non può essere contro) l’uso di DRM non interoperabili.

dmin.it propone quindi che la legge determini che un fornitore di servizi che rilascia contenuti utilizzando una tecnologia DRM proprietaria debba rilasciare gli stessi contenuti anche utilizzando la tecnologia iDRM a condizioni che non siano discriminatorie a confronto di quelle usate per i contenuti rilasciati con tecnologia DRM proprietaria. Questo è illustrato nella Figura 1 – Uso di iDRM in parallelo al DRM proprietari

Figura 1 – Uso di iDRM in parallelo al DRM proprietari

Chiunque può (ma non è obbligato a) realizzare dispositivi (hardware e software) e servizi, richiedere e, se la sua realizzazione si qualifica, ottenere un certificato di conformità e quindi offrirli a terze parti con l’indicazione “iDRM” perché tale indicazione non crei conflitti.

Le specifiche iDRM sono pubbliche, realizzate in software con codice sorgente aperto (licenza MPL 1.1), non prescrittive di un particolare modello di business, in linea con quanto detto sopra relativamente al significato della parola “Management” nell’acronimo DRM.

La specifica di iDRM non è una specifica di una soluzione DRM comparabile a quelle che sono esistono oggi sul mercato per il fatto di essere una specifica a “toolkit” cioè a “scatola di attrezzi”. Questo approccio permette di realizzare, usando sempre gli stessi strumenti e quindi aumentando il livello di interoperabilità, catene del valore che realizzano un numero vastissimo di modelli di business utilizzando gli “attrezzi” iDRM e configurandoli a seconda delle proprie necessità, mentre le soluzioni comunemente utilizzate sono a scatola chiusa e per un solo sistema.

Ad esempio, con iDRM sono possibili i seguenti sistemi di distribuzione;

Il contenuto è distribuito senz’altra informazione che un identificativo;
Il contenuto è distribuito con una licenza (ad esempio Creative Commons) che si limita ad esprimere i diritti senza alcuna forma di enforcement;
Il contenuto è distribuito solo con un identificativo ed un “Event Report Request” (vedi glossario) per permettere la raccolta dell’informazione di fruizione;
Il contenuto è distribuito con un identificativo ed una licenza che contiene, oltre all’espressione dei diritti, anche una chiave per la decifratura delle risorse
Ecc.

Come nella maggior parte degli standard moderni di “convergenza” la specifica iDRM non considera gli aspetti realizzativi degli apparati. È quindi possibile che esistano apparati che sono in grado solo di trattare contenuti in uso oggi quali, ad esempio, MP3, altri che trattano solo contenuti iDRM, altri che trattano sia contenuti iDRM, sia contenuti con DRM proprietario, e tutte le altre combinazioni possibili.

Per la stessa ragione le specifiche di iDRM non considerano gli aspetti di sicurezza che alcuni operatori possono richiedere per alcune realizzazioni di iDRM.

Un caso tipico potrebbe richiedere che l’apparato usato per creare contenuti iDRM per distribuzione (Content Creation Device) sia “sicuro” in quanto in generale deve essere possibile associare il contenuto che viene posto in distribuzione con il suo autore. Naturalmente questo non deve implicare che l’autore che lo desideri non possa conservare l’anonimità.

Facendo riferimento alle modalità di distribuzione indicate sopra si può dire che in generale il dispositivo di fruizione possa essere uno qualsiasi per il caso 1., mentre è desiderabile che mostri i termini della licenza prima dell’uso nel caso 2., anche se il contenuto potrebbe essere visto di per sé con un qualsiasi altro dispositivo. Il dispositivo di fruizione deve essere invece certificato nel caso 3. non perché il dispositivo tratta contenuti protetti, ma perché deve essere garantito, ad esempio nel caso di un sistema di compensazione alternativo, che gli “Event Report” (vedi glossario) emessi dal dispositivo siano autentici, sì da poter evitare ripartizioni distorte degli utili basate sul successo delle opere. È probabile invece che il dispositivo di fruizione del caso 4. debba essere certificato come, ad esempio, un set top box per la pay TV, perché il dispositivo tratta contenuti protetti che l’operatore può desiderare siano fruiti solo su apparati di un certo livello di sicurezza.

La specifica iDRM non può e non deve entrare nel merito di quale tecnica debba essere utilizzata per la sicurezza, se questa è richiesta. Infatti, com’è noto nel mercato vi sono già oggi modalità diverse per ottenere livelli di sicurezza diversi, ad esempio

Realizzazioni software delle specifiche che possono essere pensate sicure perché del tutto proprietarie. Un esempio di questo approccio è quello di un client di iTunes per PC.
Realizzazioni software delle specifiche che si basano su funzionalità hardware del dispositivo che sono in grado di conservare informazione segreta. Esempi di questo approccio sono i set top box di pay TV, il player iPod ed i cellulari multimediali di oggi.
Realizzazioni software delle specifiche che si basano sul Trusted Platform Module (TPM) definito dal Trusted Computing Group ed attualmente istallato su tutti i portatili.
Realizzazioni miste hardware/firmware
Altri tipi di realizzazioni che potranno emergere come conseguenza delle necessità del mercato o regolamentative quali, ad esempio, tutela della privacy, protezione dei minori ecc.

Molti di questi aspetti sono demandati alla governance dell’ecosistema iDRM che dmin.it propone sia lasciata nelle mani dei rappresentanti di tutte le parti coinvolte.

3. Tecnologie di accesso

La proposta dmin.it per l’accesso prevede che

Un operatore di rete a larga banda possa offrire accesso bundled e/o unbundled alla sua rete con caratteristiche tecniche di sua scelta;
Un utente della rete (fornitore di contenuti, intermediario o utente finale) possa richiedere ed ottenere da un operatore di rete a larga banda il puro accesso “service-agnostic” alla “big Internet” secondo le specifiche di questo documento con le caratteristiche tecniche già offerte dall’operatore a condizioni non discriminatorie nei confronti delle altre offerte dell’operatore;
Gli operatori di rete a larga banda garantiscano l’interoperabilità dei servizi di rete concordando e fornendo specifici livelli di qualità di servizio (QoS) ai punti di peering così da fornire agli utenti della rete opportuni livelli di QoS.

La Figura 2 – Accesso aperto a internet a larga banda descrive la proposta dmin.it per l’accesso alle reti a larga banda.

Figura 2 – Accesso aperto a internet a larga banda

3. Tecnologie di pagamento

La proposta dmin.it per pagamento/incasso prevede che

Chiunque, compatibilmente con le norme bancarie, possa offrire servizi di “account” non direttamente monetari (punti, credits) per transazioni collegate all’uso di digital media secondo le specifiche tecniche di questo documento;
Le transazioni siano effettuate tra “account” che si appoggiano su strumenti di pagamento ad incasso garantito, ad esempio: conto corrente, carta di credito, carta prepagata, domiciliazione bancaria, borsellino elettronico.
La sincronizzazione di un “account” con il suo circuito di appoggio non sia effettuata ad ogni transazione ma su base periodica oppure a richiesta.

La Figure 3 – Sistema di registrazione e conversione punti per digital media illustra la proposta.

Figure 3 – Sistema di registrazione e conversione punti per digital media

Scenari d’uso

4. Introduzione

In questo capitolo si raccolgono scenari d’uso che sono resi possibili dalla realizzazione delle tre componenti (formato, accesso, pagamento) della proposta di dmin.it. Gli scenari qui presentati si prestano a verificare che

La tecnologia sia effettivamente in grado di supportare tutti scenari d’uso giudicati interessanti
La governance sia in grado di supportare aspetti degli scenari d’uso
Le proposte di intervento normativo coprano aspetti degli scenari d’uso

E ad invitare quindi la comunità dmin.it alla realizzazione e sperimentazione di alcuni scenari d’uso.

Il documento non pretende di disegnare scenari che siano necessariamente realistici ma di trovare combinazioni d’uso che mettano a frutto gli elementi abilitanti della proposta dmin.it.

Alcuni scenari d’uso esercitano soltanto una delle aree (formato, accesso, pagamento), ma in generale si è cercato di esercitare più aree allo stesso tempo.

4. Leonardo compera una canzone da Mimmo

In questo scenario Leonardo compera una canzone da Mimmo e riceve una licenza temporanea, valida fino alla sincronizzazione del suo account con il suo circuito reale. Se la sincronizzazione andrà a buon fine riceverà una licenza definitiva, se no non potrà più sentire la canzone (ma tutti coloro che sono stati pagati da Leonardo dovranno “restituire” dei punti ai loro VASP in proporzione all’ammontare del default di Leonardo).

Leonardo	Visita il sito di Mimmo Vede una canzone che gli piace È d’accordo sulle condizioni del modello di licenza che dice i. Costa 100 punti ii. Da pagare non prima di 7 gg e non dopo 15 gg Scarica il file della canzone cifrata da Mimmo Manda a Mimmo l'Ordine di Acquisto contente l’ID dell'account da cui effettuerà il pagamento
Mimmo	Manda una Disposizione d’Incasso al suo VASP Pluto
Pluto	Consulta i Servizi condivisi Inoltra al VASP Pippo di Leonardo la Disposizione d’Incasso
Pippo	Informa Leonardo della ricezione della Disposizione d’Incasso
Leonardo	Dà l’OK a Pippo
Pippo	Accredita i 100 punti sul conto di Mimmo presso Pluto
Pluto	Comunica l’avvenuta ricezione del pagamento a Mimmo
Mimmo	Confeziona la licenza temporanea Comunica a Leonardo che la licenza temporanea è pronta
Leonardo	Scarica la licenza temporanea da Mimmo Ascolta la canzone come da termini della licenza temporanea
10. Pippo (dopo 12 gg)	Sincronizza con il conto corrente di Leonardo; risultato: successo Comunica il successo a Pluto
11. Pluto	Comunica il successo a Mimmo
12. Mimmo	Confeziona la licenza definitiva Comunica a Leonardo che la licenza definitiva è pronta
13. Leonardo	Scarica la licenza definitiva Ascolta la canzone come da termini della licenza definitiva
14. Ovvero Pippo (dopo 12 gg)	Sincronizza con il conto corrente di Leonardo; risultato: insuccesso (e.g. insufficienza di fondi) Comunica l’insuccesso a Pluto Comunica l’insuccesso a Leonardo Invia una comunicazione ai Servizi Condivisi contenente la lista i. Degli utenti ii. Dei punti che ognuno deve restituire iii. Degli Account su cui tale operazione va fatta
15. Servizi Condivisi	Comunica ad ogni VASP gli account a cui occorre detrarre le somme diventate inesigibili
16. Pluto	Comunica l’insuccesso a Mimmo Detrae dal conto di Mimmo l’ammontare di punti comunicato dai Servizi Condivisi
17. Leonardo (dopo 15 gg)	Non può più sentire la canzone di Mimmo

Nota: Lo scenario d’uso è ovviamente molto primitivo. La governance del sistema di pagamento deve rispondere a queste domande:

Diamo un periodo di grazia a Leonardo sperando che adegui la dotazione del suo circuito reale?
Nel frattempo blocchiamo i punti del suo account che sono insufficienti a completare la sincronizzazione?
Che cosa viene effettivamente segnalato ai Servizi Condivisi?
Per quanto tempo viene conservata l’informazione archiviata nei Servizi Condivisi?
.

4. Roberta guarda un programma TV live

In questo scenario Roberta vuole guardare un film su un canale di TV+ ma le mancano dei punti. Si guarda allora un po’ di pubblicità su Publi+, si ricarica il borsellino e si guarda il film.

Roberta	Si sintonizza sull’offerta di TV+ Sceglie un film Vuole pagare ma si accorge di non avere abbastanza punti Sceglie il fornitore di pubblicità Publi+ che appare sull’EPG di TV+
Publi+	Invia via internet un’EAG (Electronic Advertisement Guide) di pubblicità. Ogni entry ha associato il suo numero di punti dmin
Roberta	Sceglie 3 entry di pubblicità per accumulare il numero di punti desiderato
Publi+	Invia via internet le 3 entry di pubblicità
Roberta	Guarda le 3 entry
Publi+	Accredita i punti accumulati sul virtual account di Roberta
Roberta	Sceglie il programma “Vola più in alto” Paga con i punti appena acquisiti (meno di quanto dovuto perché Roberta ha appena guardato la pubblicità di Publi+)

4. Antonella ascolta la musica pagandola con la pubblicità

In questo scenario Antonella compera una canzone da Mimmo contro un minuto di pubblicità ed il suo profilo fino ad un dato livello di “profondità”. Mimmo “passa” il profilo a Publi+ che confeziona la pubblicità mirata.

Antonella	Visita il sito di Mimmo Vede una canzone che le piace È d’accordo sulle condizioni del modello di licenza che dice “Costa” 1 minuto di pubblicità Con la fornitura di un profilo di profondità stabilita Da ascoltare ogni volta prima dell’ascolto del brano Manda a Mimmo l’ordine di acquisto con Il suo “profilo” di profondità richiesta nella licenza Una licenza d’uso che permette di utilizzare il profilo solo per le necessità del servizio in questione
Mimmo	Manda a Publi+ La richiesta di pagamento per la canzone Il profilo con relativa licenza (con sublicence)
Publi+	Accetta la richiesta di pagamento Manda la disposizione di pagamento della canzone al suo VASP Paperino Chiede a Mimmo i dati di Antonella per confezionare la pubblicità “su misura” per lei
Mimmo	Manda al suo VASP Pluto La disposizione di incasso I dati di Antonella La canzone cifrata richiesta da Antonella
Pluto	Manda la disposizione di incasso a Paperino
Paperino	Detrae i punti dal conto di Publi+ Manda i punti a Pluto
Pluto	Incassa i punti Manda i dati di Antonella a Paperino
Paperino	Prepara e manda a Pluto il pacchetto pubblicitario da allegare al brano
Pluto	Riceve la pubblicità per Antonella Confeziona il pacchetto canzone cifrata+pubblicità Invia il pacchetto canzone cifrata+pubblicità a Mimmo
10. Mimmo	Invia il pacchetto ad Antonella
11. Antonella	Riceve il file cifrato composto da musica+pubblicità

Questo modello presuppone un contratto tra Mimmo e l’inserzionista pubblicitario. Alternativamente potrebbe anche non esserci alcun contratto e Mimmo potrebbe utilizzare i servizi condivisi per conoscere la reputazione dell’inserzionista (come per utente).

4. Luca ascolta musica in abbonamento

In questo scenario Luca si abbona ad servizio di musica “Dormi bene” modellato sull’offerta “Napster” (finché sei abbonato scarichi e senti tanta musica quanta vuoi, quando smetti non hai più nulla)

Luca	Visita il sito di Dormi bene Visualizza le condizioni di abbonamento al servizio È d’accordo sulle condizioni di abbonamento che dicono “Costa” 100 punti al mese Consente di scaricare un numero illimitato di brani musicali I brani possono essere ascoltati solamente fino a quando l'abbonamento è attivo Si registra sul sito di Dormi bene Manda a Dormi bene l'ordine di acquisto dell'abbonamento contenente le coordinate del proprio account virtuale
Dormi bene	Riceve l'ordine di acquisto dell'abbonamento dal nuovo utente registrato Compila ed invia al proprio VASP (NASP) la Disposizione di Incasso corrispondente all'ordine di acquisto
NASP	Riceve la disposizione di incasso da Dormi bene Consulta i Sevizi Condivisi
Servizi Condivisi	Riceve la richiesta di consultazione per Luca Consulta le blacklist e le greylist Invia il risultato a NASP
NASP	Riceve il risultato di consultazione dei Servizi Condivisi[1] Invia la disposizione di incasso al VASP di Luca (LASP)
LASP	Riceve la disposizione di incasso da NASP Richiede a Luca l'OK per il pagamento
Luca	Riceve la richiesta di nulla osta per il pagamento Invia l'ok per il pagamento a LASP
LASP	Riceve l'ok per il pagamento Esegue la transazione di pagamento a Dormi bene attraverso NASP (decrementa il di 100 punti il conto di Luca)
NASP	Riceve la transazione di pagamento della disposizione di incasso Accredita di 100 punti il contro di Dormi bene Notifica Dormi bene dell'avvenuto pagamento dell'abbonamento da parte di Luca
10. Dormi bene	Riceve la notifica del pagamento della disposizione di incasso Attiva l'utenza di Luca Notifica Luca dell'attivazione dell'utenza
11. Luca	Riceve da Dormi bene la notifica dell'attivazione della sua utenza Si autentica su sito di Dormi bene Sceglie i brani da scaricare
12. Dormi bene	Confeziona i package cifrati dei brani Confeziona le licenze temporanee dei brani scelti da Luca Notifica Luca della disponibilità dei brani e delle corrispondenti licenze
13. Luca	Scarica i brani e le corrispondenti licenze sul proprio SAV Eventualmente trasferisce i brani dal SAV al PAV
14. LASP	Esegue la conversione mensile sul circuito di pagamento associato all'account di Luca Comunica a NASP il risultato della conversione
15. NASP	Riceve da NASP il risultato della conversione Se il risultato è positivo notifica Dormi bene del successo della conversione Se il risultato è negativo notifica la blacklist/greylist dei Servizi Condivisi notifica Dormi bene dell'insuccesso della conversione addebita Dormi bene di 100 punti
16. Servizi Condivisi	Riceve la notifica dell'insuccesso della conversione Alimenta la lista delle frodi Assegna Luca alla lista opportuna (blacklist o greylist)
17. Dormi bene	Riceve la notifica del fallimento (insoluto) della conversione e dell'addebitamento di 100 punti sul proprio account Decide cosa fare con il cliente insolvente
18. Dormi bene	Al termine del periodo di abbonamento di Luca notifica quest'ultimo della possibilità di rinnovare l'abbonamento e delle condizioni applicate al rinnovo
19. Luca	Riceve la notifica del termine del periodo di abbonamento e della possibilità di rinnovare lo stesso Se non rinnova l'abbonamento e prova a eseguire i brani scaricati con licenza temporanea, non riesce ad ascoltarli Se decide di rinnovare l'abbonamento invia a Dormi bene l'ordine di acquisto del rinnovo dell'abbomento
20. Dormi bene	Riceve l'ordine di acquisto del rinnovo dell'abbonamento Emette ed invia a NASP la disposizione di incasso
21. NASP	Riceve la disposizione di incasso Consulta i Servizi Condivisi[2] Inoltra la disposizione di incasso a LASP
22. LASP	Riceve la disposizione di incasso Richiede a Luca l'ok per il pagamento della disposizione di incasso
23. Luca	Riceve la richiesta di ok per il pagamento Accetta ed invia l'ok per il pagamento
24. LASP	Riceve l'ok per il pagamento Esegue la transazione (addebito di altri 100 punti sull'account di Luca) Trasmette la transazione di pagamento a NASP
25. NASP	Riceve la transazione di pagamento Accredita l'account di Dormi bene di 100 punti Notifica Dormi bene dell'avvenuto pagamento
26. Dormi bene	Riceve la notifica dell'avveunuto pagamento di Luca Rinnova le licenze temporanea per il prolungamento del periodo di abbonamento Notifica Luca della disponibilità delle nuove licenze
27. Luca	Si autentica sul sito di Dormi bene Scarica sul SAV le nuove licenze temporanee (eventualmente le trasferisce anche su PAV) Esegue i brani

4. Beppe compensa Pippo con un sistema di compensazione alternativo

Immaginamo che in Italia sia stato normativamente introdotto un sistema di compensazione alternativo e che la SIAE sia incaricata di raccogliere le informazioni d’uso. Pippo rappresenta un gruppo di compositori e cantanti che hanno appena prodotto una canzone. Pippo crea una struttura di dati con la canzone che contiene oltre ad una ricca varietà di metadati per far sì che vari motori di ricerca e promozione possano svolgere il loro ruolo, anche la tecnologia di Event Reporting. Ogni volta che qualcuno sente una canzone il Dispositivo invia un messaggio alla SIAE.

Beppe ha ricevuto un suggerimento dal suo programma che scandaglia il web che la canzone di Pippo è probabilmente interessante per lui. Beppe allora decide di sentire la canzone ed il suo Dispositivo invia l’Event Report alla SIAE che può così calcolare esattamente quante volte la canzone di Pippo è stata da lui sentita e quindi retribuirlo corrispondentemente.

4. Nuova Cantina vende musica sul web

La banda di cantinari Nuova Cantina (NC) sta avendo qualche successo con le sue canzoni e vuole tentare di venderle sul web con iDRM.

NC ha un suo Account Virtuale con Nuova Moneta (NM), un fornitore di account virtuali
NC si dota di un programma informatico con le segenti funzionalità
Cifra il file MP3 in forma finale	Si fa con normali tecnologie
Registra il file MP3 ad esempio con la SIAE	Come avviene già oggi
Crea una struttura dati XML con metadati, event reporting, pointer al server di licenze ecc.	Crea una struttura di dati
Registra la struttura dati ad esempio con la SIAE	In questo caso la SIAE è anche un’agenzia di registrazione di contenuti della governance di dmin.it
Mette il tutto in vendita sul sito
Rosita, che vuole comperare il brano, ha
Un WiFi PDA con player iDRM
Un account con Piccola Moneta (PC) , un altro fornitore di account virtuali
Rosita
Si scarica il brano con la struttura dati sul suo WiFi PDA
Schiaccia play e le viene chiesto di pagare	Il player di Rosita è naturalmente un player iDRM
Paga sull’Account Virtuale di PM che notifica NM che notifica il server di licenze di NC (tutto questo è, naturalmente, trasparente a Rosita)
Il player iDRM sul WiFi PDA prende la licenza dal server di licenze di NC e fa sentire il brano

4. Marco distribuisce i suoi video su DTT

Marco è un laureato del DAMS che ha intravisto le opportunità offerte dall’ambiente creato dalla proposta dmin.it. Ha acquistato i diritti per l’uso di un’ora alla settimana da un fornitore di rete DTT ed ora regolarmente confeziona un programma televisivo di un’ora alla settimana approvvigionandosi, mediante l’acquisizione di diritti per la diffusione su DTT, di video autoprodotti dai vari siti italiani.

Lucio	Crea uno short su “La pesca delle trote in alta montagna” un argomento che spera possa interessare Marco in un suo futuro programma
Luigi	Gestisce un sito dove sono caricati video autoprodotti su cui Lucio carica il suo short	Luigi potrebbe caricare sul sito non il puro file video ma un DCF che contiene informazione di management aggiuntiva
Marco	È un aggregatore di video autoprodotti che viene a conoscenza dello short di Lucio e ne acquisisce i diritti	Il lavoro di Marco potrebbe essere facilitato dall’aggiunta di metadati, una volta acquisiti i diritti da Luigi (operazione eventualmente facilitata da una licenza messa da Luigi)
Mario	È un fornitore di accesso alla rete internet a larga banda “on demand” che Marco utilizza una volta alla settimana a condizioni dmin.it per trasmettere i suoi programmi a Muzio
Muzio[3]	È un fornitore di accesso alla rete di distribuzione DTT da cui Marco ha acquistato accesso a 4 Mbit/s per un’ora alla settimana in un giorno ed un’ora stabilita. Muzio offre anche servizi di DRM-izzazione dmin.it che Marco utilizza	Muzio può creare una versione streamabile e protetta (se questo è il modello di business di Marco e se questo si accorda con quello di Luigi)
Neviano	È un fornitore di accesso alla rete internet a larga banda con cui Muzio ha fatto un contratto di fornitura a 100 Mbit/s a condizioni dmin.it
Nino	È un utente che non si perde mai l’ora di trasmissione dei programmi di Marco	Nino può vedere il programma di Marco perché dotato di un Dispositivo che gli consente di vedere tutti i programmi sulla DTT in formato dmin.it
Nereo	È un osservatore di trend dei programmi spontanei su DTT che acquisisce il diritto di accedere ed utilizzare i dati d’uso degli utenti	Il lavoro di Nereo può essere facilitato dal fatto che il contenuto preparato e streamato da Muzio contiene opportuni metadati.

4. Distribuzione di contenuti governati su P2P

DIMusic ha creato una comunità di appassionati sulla sua rete P2P. I partecipanti alla comunità DIMusic sono dotati di un software che trasforma il loro PC o MAC su Windows, Linux o OS X in un “peer” mediante il quale è possibile

Creare un file che contiene i metadati delle canzoni, una licenza espressa in REL (ad esempio di tipo Creative Commons) e la canzone stessa in forma aperta (non cifrata)
Condividere il file con gli altri membri della comunità DIMusic
Fare browsing nelle directory condivise degli altri membri della comunità DIMusic

Della comunità DIMusic fanno parte anche “case discografiche” che pongono il loro catalogo sulla rete sotto forma di file senza licenza ma con la risorsa (canzone) tipicamente cifrata. Per il resto il peer della casa discografica è eguale a uno qualsiasi degli altri peer. Naturalmente se un membro della comunità si scarica un file dal peer della casa discografica dovrà tipicamente pagare per la licenza.

4.10 Registrazione personale di video

VHS 2.0 è una software house che ha sviluppato un pacchetto software che permette al suo acquirente di registrare come DCF un video trovato sul web. Il DCF contiene una licenza espressa in REL che contiene la chiave usata per la cifratura del video cifrata con la chiave pubblica del dispositivo e la risorsa cifrata oltre a metadati che l’utente del programma possa desiderare di aggiungere. Il questo modo solo l’utente sarà in grado di rivedere il video archiviato.

VHS 2.0 offre anche un servizio di gestione domini in cui l’acquirente registra i membri della propria famiglia in modo tale che anche gli altri membri della famiglia possano rivedere il video da lui registrato.

4.11 Gestione del ciclo di vita di documenti

Sharedoc è una software house che ha sviluppato un insieme di applicativi mediante i quali un’azienda può gestire il ciclo di vita dei suoi documenti più importanti in modo molto più puntuale e controllato.

Supponiamo che l’azienda “Avanti Tutta” abbia acquista il giusto numero di licenze della suite di applicativi di Sharedoc e che Aldo, responsabile di una divisione, sia stato incaricato dal capo azienda Giovanni di redigere uno studio confidenziale usando il necessario personale della divisione più due esperti di un’altra divisione.

Usando un applicativo di Sharedoc Aldo crea un’indice del documento ed un insieme di licenze, una per ogni persona coinvolta nella redazione del documento, in cui sono indicati, capitolo per capitolo, i diritti che editing/stampa/commento ecc.

Giacomo, una persona della divisione di Aldo, ha ricevuto una email che gli comunica il nuovo task con il nome del file da editare. Giacomo apre il file e viene mandato sul server di licenze dove si scaricherà la licenza che gli permetterà di svolgere il suo lavoro.

Requisiti

5. Introduzione

In questo documento sono raccolti i requisiti a cui devono soddisfare le tecnologie e le soluzioni utilizzate per realizzare la proposta di Digital Media in Italia (dmin.it) . Tali requisiti hanno guidato la realizzazione delle specifiche tecniche, le proposte di interventi normativi e le regole di governance.

5. Requisiti per iDRM

5.2. Requisiti di sistema

In questo capitolo si raccolgono in modo sistematico alcuni dei requisiti del sistema iDRM considerati nel corso dello sviluppo della proposta

Per una corretta interpretazione della proposta si raccomanda di far uso delle definizioni contenute nel glossario. Le parole con lettere maiuscole hanno il significato dato dal glossario.

Il sistema iDRM consente al Creatore di digital media, sulla base di diritti a lui assegnati e delle limitazioni determinate dalla legislazione del paese in cui vive, di determinare, con funzioni separate:
1. Le modalità d’uso di tale Contenuto
2. L’enforcement di tali modalità
Il sistema iDRM consente a tutti gli attori di una Catena del Valore che hanno ricevuto un dato Contenuto di determinare le modalità e/o l’enforcement d’uso di un tale Contenuto, all’interno dei diritti loro concessi dagli Utenti della Catena del Valore che hanno loro affidato il Contenuto
Il sistema iDRM consente di individuare, come destinatari dei diritti espressi, sia Dispositivi, sia Utenti (opportunamente rappresentati allo scopo, ad esempio, da una smart card) e sia gruppi – detti Domini – di Dispositivi o di Utenti.
Il sistema iDRM consente ad un Utente di una Catena del Valore di comunicare e, se mutuamente accettato, entrare in una relazione di business con un altro Utente
Il sistema iDRM offre un toolkit di tecnologie standard facilmente combinabili per raggiungere determinati obiettivi
Il sistema iDRM consente di estendere il toolkit con nuove tecnologie o di sostituire tecnologie obsolete con altre più moderne e performanti
Il sistema iDRM consente ad un progettista di una Catena del Valore di scegliere/combinare a piacere le tecnologie che si trovano nel toolkit in modo tale da raggiungere gli scopi che si è prefisso
Il sistema iDRM consente ad un Utente di pubblicare la lista di funzionalità abilitate dalla sua scelta/combinazione di tecnologie dal toolkit
Il sistema iDRM consente di definire un “middleware” condiviso da tutti i Dispositivi utilizzati in una Catena del Valore ed in grado di offrire funzionalità comuni a tutti i Dispositivi
10. Il sistema iDRM consente di realizzare Dispositivi interoperabili grazie all’utilizzo del middleware di cui al punto precedente
11. Il sistema iDRM consente di aggiornare le componenti software di un Dispositivo
12. Il sistema iDRM consente di usare codice eseguibile per realizzare opportune funzionalità (e.g. un algoritmo di cifratura specifico di un dato tipo di Contenuto) non standard ma senza danneggiare l’interoperabilità
13. Il sistema iDRM si basa su una governance che supervisiona l’identificazione e la certificazione delle entità (Contenuti e Dispositivi) usati dalle Catene del Valore
14. Il sistema iDRM consente la creazione di mercati orizzontali di Dispositivi utilizzabili nelle Catene del Valore
15. Il sistema iDRM consente di trattare tutti i tipi di Contenuti numerici
16. Il sistema iDRM consente di distribuire contenuti in varie modalità, inclusa quella peer-to-peer

5.2. Requisiti giuridici

La soluzione dmin.it deve favorire il ripristino di un miglior clima di fiducia tra imprese e consumatori e la maggiore efficienza del mercato non soltanto nel modello tradizionale impresa-consumatore, ma anche abilitando forme di remunerazione per la creatività diffusa.
La soluzione dmin.it deve offrire processi di negoziazione trasparenti e bidirezionali (cioè capaci di allargare il ventaglio delle scelte dell’utente rispetto al “prendere o lasciare” tipico della contrattazione standardizzata), ad esempio devono essere possibili modelli di business in cui non si richieda necessariamente l’uso di licenze.
La soluzione dmin.it deve essere applicabile alla giurisdizione italiana con i vincoli posti dall’UE.
La soluzione dmin.it deve permettere di incentivare l’incorporazione nel DRM di procedure che rendano gestibile (almeno parzialmente) per via tecnologica la fruizione di eccezioni e limitazioni (come quella attinente alla copia privata) al diritto d’autore colmando il divario tra un mondo analogico, direttamente gestito dagli umani ad un mondo numerico in cui le macchine svolgono parte delle funzioni prima esclusivamente svolte dagli umani.
La soluzione dmin.it deve rispettare le libertà fondamentali garantite dalla Costituzione ad esempio la riservatezza ed il diritto alla protezione dei dati personali, ad esempio tenendo accuratamente separate le funzionalità di DRM (e.g. generazione di licenze e gestione delle chiavi) e quelle di utilizzo dei dati che sono presenti nel sistema a scopo amministrativo (e.g. a scopo di billing)
La soluzione dmin.it deve poter essere utilizzata per proteggere i dati personali e d’uso.
La soluzione dmin.it deve richiedere il minimo uso di dati personali e di dati identificativi, in modo da escluderne il trattamento quando le finalità perseguite nei singoli casi possono essere realizzate mediante, rispettivamente, dati anonimi od opportune modalità che permettano di identificare l’interessato solo in caso di necessità.
La soluzione dmin.it deve permettere che un utilizzatore possa permettere l’utilizzo, eventualmente contro contropartita, di alcuni dei propri dati, nel rispetto delle norme del d.lgs. 30 giugno 2003 n. 196, codice in materia di protezione dei dati personali.
La soluzione dmin.it deve essere dotate di funzionalità che consentono all’utente di compiere atti negoziali attraverso le componenti poste sotto il controllo dell’utente medesimo. Ad esempio quando un utente si abbona ad un servizio, il fornitore di servizio offre contratti “multiclausola” per avere dei contratti personalizzati
La soluzione dmin.it incorporare funzionalità che consentano all’utente di fruire delle eccezioni o limitazioni al diritto d’autore ed ai diritti connessi con riguardo ai contenuti digitali che ricadono nell’ambito di applicazione della legge 22 aprile 1941 n. 633, protezione del diritto d’autore e di altri diritti connessi al suo esercizio;
La soluzione dmin.it deve incorporare funzionalità che consentano all’utente di poter essere costantemente informato sul funzionamento delle medesime misure tecnologiche di protezione e sul loro eventuale aggiornamento;
La soluzione dmin.it deve ridurre al minimo i rischi attinenti alla sicurezza dei sistemi informativi di operatori ed utenti;
La soluzione dmin.it deve consentire di escludere le misure tecnologiche di protezione ove l’attore della catena del valore che distribuisca digital media mediante iDRM non intenda applicarle ovvero la legge non ne preveda l’applicazione.
La soluzione dmin.it deve essere dotata di funzionalità che consentano all’utente di poter in ogni momento disattivare e rimuovere legittimamente le componenti iDRM installate sul proprio dispositivo, eventualmente al costo di non più poter fruire i contenuti gestiti mediante quelle particolari componenti o, al limite, con conseguenze sul piano contrattuale, cioè inadempimento, ma mai l’impossibilità “fisica” di disinstallare quel che si è precedentemente installato sul proprio dispositivo.

5.2. Requisiti tecnici

La soluzione dmin.it deve permettere la realizzazione di catene del valore che implementano una vasta gamma di modelli di business, ad esempio quelli degli scenari d’uso
La soluzione dmin.it deve permettere l’utilizzazione della stessa tecnologia, eventualmente aumentata o diminuita, per
1. Realizzare la stessa funzionalità in catene del valore diverse
2. Essere applicata a diversi sistema di delivery (ADSL, DTT ecc.).
La soluzione dmin.it deve permettere l’utilizzazione delle sole funzionalità richieste da una data catena del valore
La soluzione dmin.it deve permettere l’aggiunta di nuove funzionalità nel caso in cui queste siano richieste da nuove catene del valore
La soluzione dmin.it deve permettere l’espressione unitaria e flessibile dei vari dati che si riferiscono ad una data risorsa (identificativi, metadati, licenze, informazione usata dal sistema iDRM ecc.)
La soluzione dmin.it deve permettere l’identificazione delle varie entità (contenuti, dispositivi, utenti ecc.) che sono utilizzate in una catena del valore
La soluzione dmin.it deve permettere l’autenticazione (cioè la dimostrazione dell’identità) e la gestione (e.g. rinnovo certificati) dei dispositivi usati nelle catene del valore
La soluzione dmin.it deve permettere l’espressione in un linguaggio interpretabile da una macchina
1. Dei diritti relativi ai contenuti di dispositivi, utenti o gruppi di dispositivi e di utenti
2. Dell’ontologia (cioè dell’insieme dei termini e delle loro relazioni) del sistema iDRM
La soluzione dmin.it deve permettere l’ottenimento da parte di un dispositivo del codice necessario per eseguire una data funzionalità (ed esempio un algoritmo di cifratura)
10. La soluzione dmin.it deve permettere la gestione di gruppi di dispositivi e di utenti (domini)
11. La soluzione dmin.it deve permettere la possibilità per due attori di una catena del valore di negoziare i termini delle licenze che essi possono scambiare (ad esempio contenuto contro dati d’uso)
12. La soluzione dmin.it deve permettere la comunicazione tra dispositivi in una catena del valore mediante opportuni protocolli.

5. Requisiti per iNet

5.3. Requisiti di sistema

Deve essere possibile per un utente

Trovare e accedere
1. a quello che vuole
2. quando vuole
con la qualità di servizio che sceglie
1. a condizioni di mercato non discriminatorie
Poter raggiungere e/o essere raggiunto
1. senza discriminazioni da qualsiasi potenziale consumatore
2. a condizioni di libero mercato
Poter raggiungere e/o essere raggiunto
1. senza discriminazioni da qualsiasi potenziale fornitore
2. a condizioni di libero mercato
Non avere raccolti i propri comportamenti sulla rete
1. se non con consenso
2. senza perdere altri diritti
Avere l’anonimato protetto (e.g. a meno di richiesta di magistrato) a richiesta

5. Requisiti per iPay

5.4. Requisiti di sistema

In questo capitolo si raccolgono in modo sistematico alcuni dei requisiti del sistema di pagamenti per cui si fa riferimento alla seguente nomenclatura:

Utente: ogni attore che opera nel sistema di pagamento
Subscriber: un attore che ha un Account su un VASP
VASP: Virtual Account Service Provider
Servizi Condivisi

È opportuno notare che alcune di queste ipotesi sono state introdotte per facilitare la progettazione del sistema ma che alcune di queste potrebbero anche essere rimosse o modificate.

Il sistema di pagamenti proposto è parallelo e non sostitutivo di altri sistemi di pagamento
Nel sistema di pagamenti proposto operano Fornitori di Servizi di Account o Virtual Account Service Provider (VASP), che eventualmente cumulano tale funzione con altre, presso i quali gli Utenti (di tipo “Consumer” o “Business”) delle catene del valore possono stabilire
1. Uno o più Account
2. Presso uno o più VASP
3. Con o senza possibilità di convertire punti in moneta reale
4. Eventualmente con dei limiti prefissati al livello di punti negativi cumulabili
5. Da usare dal titolare per regolare i suoi pagamenti, se la sua controparte accetta
Gli Account sono
1. Basati su un’unità di conto (punti) che è unica per tutto il sistema di pagamenti proposto ed accettata da tutti i VASP
2. Dipendenti da un solo sistema di pagamento in moneta reale (relazione biunivoca)
3. Sincronizzati periodicamente o a richiesta degli Utenti con dei sistemi di pagamento in moneta reale ad incasso garantito
4. Gerarchici, cioè possono contenere dei Sub-Account
5. Non gravati/beneficiati di interessi sui punti depositati
6. Gestiti dagli Utenti mediante applicazioni con interfacce standard (ad esempio per ottenere la situazione dell’Account o per forzare una sincronizzazione prima della scadenza)
I punti hanno le seguenti caratteristiche
1. Sono convertibili in moneta reale a richiesta dell’Utente titolare dell’Account o a intervalli determinati
2. Rappresentano un valore monetario molto piccolo (e.g. 0,001 €) per permettere, ad esempio, impulse buying/selling
3. Hanno un rapporto
  1. Espresso da un numero qualsiasi
  2. Determinato all’istante t0 dalla Governance dei sistema economico dmin.it
  3. Dopo di che il valore rimane fisso oppure varia (v. Annex C)
Esiste un punto di raccolta dati chiamato Servizi Condivisi che
1. È unico nel sistema economico dmin.it
2. Raccoglie informazione sui default dei titolari di Account dai VASP
3. Fornisce su richiesta informazione sulle trasgressioni dei titolari degli Account a
  1. Un VASP
  2. Un Utente solamente per reperire informazioni riguardo a se stesso
4. È aggiornato non appena è scoperto un default (sincronizzazione fallita)
La governance del sistema di pagamento proposto potrà determinare forme di supervisione dell’attività dei VASP per evitare che questi “creino moneta” in modo fraudolento. Due possibili forme sono
1. Ispezioni ai “libri contabili” dei VASP
2. Trasmissione ai Servizi Condivisi di tutte le transazioni con il payload oscurato salvo il numero della transazione e l’ammontare
L’ammontare di un default è suddiviso
1. Tra tutti coloro che sono stati pagati a punti dopo l’ultima sincronizzazione conclusasi con successo
2. In proporzione dell’ammontare del loro credito
Il sistema di pagamenti proposto applica l’IVA ad ogni transazione (perché i tassi per le diverse transazioni possono non essere omogenei)
Il VASP fornisce ai suoi titolari di Account
1. L’informazione necessaria per permettere loro di pagare l’IVA come per legge
2. Servizi aggiuntivi, e.g. fatturazione
10. Un VASP può oscurare parte del payload che passa ad un altro utente
11. Il sistema di pagamenti proposto è alimentato da una tassa di partecipazione (e.g. prelevata ad ogni transazione) per
1. Servizi Condivisi
2. Eventualmente altri servizi necessari (e.g. governance)
12. Ogni Utente del sistema di pagamenti proposto ha un identificativo unico emesso dai Servizi Condivisi basato sul suo codice fiscale ed altri parametri
13. Ogni Account ha un identificativo unico
1. All’interno del VASP
2. All’interno del sistema di pagamenti proposto mediante associazione all’ID del VASP

Specifiche di iDRM

6. Introduzione

Questo documento specifica il sistema di iDRM. Dmin.it ha adottato per le specifiche del toolkit iDRM quelle dell’Interoperable DRM Platform v. 3.2 (IDP-3.2) del Digital Media Project e la sua reference implementation nota con il nome di Chillout.

È opportuno notare che ISO/IEC 23000-5 corrisponde alla specifica IDP-3.2 per la parte dispositivo d’utente.

6. Schema di riferimento

La Figura 4 – Attori tipici di una catena del valore descrive alcuni dei tipici attori di una tale catena del valore e le specifiche iDRM sono utilizzabili per realizzare le catene del valore che replicano quelle del mondo analogico ma anche altre catene del valore molto più innovative.

Figura 4 – Attori tipici di una catena del valore

Un autore crea un’opera che è eseguita (“istanziata”) da un artista ed utilizzata da un produttore per farne un prodotto – tipicamente una combinazione di varie risorse (audio, video ecc.) – che sarà successivamente distribuito da fornitori di contenuti e di servizi per essere infine fruito da un utente finale.

Già nelle catene del valore tradizionali esisteva la necessità di dare un’identità alle varie entità che sono trattate dagli attori della catena del valore. Quando tali entità dessano di essere oggetti fisici per diventare bit che non sono più necessariamente associabili a qualcosa di fisico tale necessità è vieppiù sentita, anche perché alle entità sono associati o associabili una quantità di dati (metadati ed altro).

Nelle catene del valore numeriche gioca quindi un ruolo importante la definizione di una struttura che possa tenere insieme in mod flessibile risorse (od eventualmente solo i link che portano ad esse), identiticativi, metadati ed altro di cui si dirà oltre.

Un esempio importante di “altri” dati associabili alle entità sono le licenze. Queste permettono ad un utente della rete che ha diritti su un’entità di esprimere come un altro utente della rete può usare le risorse oggetto della licenza ed a quali condizioni. Un esempio di tale licenza può essere una particolare licenza Creative Commons espressa in una forma interpretabile da una macchina, ma potrebbe essere una licenza che implica sostanziali limitazioni alla fruizione delle risorse e può includere chiavi crittografiche.

Le licenze possono essere date ad dispositivi (nel caso di un utente finale, il suo player MP3, ad esempio), ad utenti (rappresentati ad esempio dalle loro smart card) o a domini. Questi ultimi sono raggruppamenti di dispositivi e di utenti.

In generale si richiede un opportuno linguaggio chiamato Rights Expression Language (REL) perché un dispositivo (ad esempio un player) sia in grado di interpretare, senza intervento umano, una licenza potenzialmente in grado di esprimere tutte le complessità dei rapporti di business tra attori delle catene del valore. Tale linguaggio usa dei “verbi” (ad esempio “play”, “copy” ecc.) che sono definiti da un’ontologia che ha lo scopo di esprimere anche complessi rapporti di business tra attori delle catene del valore. L’ontologia è espressa in Ontology Web Language (OWL).

Un utente della catena del valore che interagisce con contenuti mediante un dispositivo genererà tipicamente dei dati (ad esempio “quante volte è stata sentita la canzone Papaveri e Papere” oppure “quante volte è stato letto il paragrafo 1.2.3 della proposta dmin.it”). Questi si chiamano “dati d’uso” e possono avere un valore in sé. L’utente che li genera ne è, ovviamente, proprietario e potrà decidere, nel rispetto delle leggi, di dare ad altri utenti della catena del valore licenza di utilizzare tali dati d’uso. Infatti, mentre nei casi più comuni è il contenuto ad aver valore, sono concepibili casi in cui sono invece i dati d’uso ad aver più valore. Una tecnologia molto importante per la valorizzazione dei dati d’uso è quindi quella che permette di “contare” in modo affidabile i vari eventi che corrispondono ad un uso.

La licenza può essere parte integrale della struttura dati (cioè essere “in line”) oppure può essere referenziata (e questo, come detto sopra è vero in generale per qualunque componente della struttura). In alternativa il dispositivo a cui l’utente chiede di svolgere una certa funzione (ad esempio “play”, “copy” ecc.) può consultare il dispositivo del detentore dei diritti per conoscere se quella funzione è ammissibile.

I componenti della struttura, in particolare le risorse, possono essere in una forma che permette l’uso immediato o in forma protetta (ad esempio, cifrata). Quindi la struttura deve essere in grado di convogliare altri tipi di dati quali le chiavi e altra informazione collegata. Oltre a questi altri tipi di dati la struttura deve poter convogliare anche codice eseguibile che il dispositivo può utilizzare per compiere varie elaborazioni sui dati ricevuti (ad esempio estrazione di informazione contenuta nel watermarking associato ad un file audio).

Le modalità di trasporto della struttura di dati tra dispositivi sono essenzialmente due: attraverso file o stream. Il secondo caso è particolarmente importante nel caso in cui la struttura dati porti informazione che deve essere consegnata al dispositivo ricevente entro un certo tempo.

Infine occorre ricordare che, prima di attuare il trasporto della struttura dati o addirittura indipendentemente dal trasporto stesso, i dispositivi hanno necessità di eseguire protocolli in conseguenza di istruzioni date dagli utenti dei dispositivi. Esempi possono essere il protocollo per ottenere la licenza per l’uso di un contenuto o per la creazione di un dominio di dispositivi o di utenti.

In molti casi di catene del valore analogiche il ruolo del dispositivo è marginale e l’uso dei contenuti – libri, cassette, dischi ecc. – è regolato dalle leggi e dalle consuetudini. Lo stesso può avvenire anche per catene del valore numeriche (ad esempio vendita di file MP3 non protetti di Emusic).

Questo tipo di modalità è però abbastanza limitativo dello spettro di possibilità offerto dalle tecniche numeriche. Coloro infatti che detengono diritti per contenuti di alto valore temono che il rilascio dei loro contenuti in forma non protetta porti ad un significativo mancato guadagno. Se tali contenuti sono però protetti (ad esempio, cifrati) è necessario che i dispositivi che convertono i contenuti in forma non cifrata siano certificati, cioè diano sufficienti garanzie di robustezza agli attacchi.

Il modello iDRM offre la garanzia che chiunque abbia un dispositivo realizzato secondo le specifiche pubbliche ed abbia acquisito i necessari diritti possa accedere a e fruire un dato contenuto. Il modello però funziona solo se ci sono contenuti e cioè che gli aventi diritto abbiano rilasciato i loro contenuti fiduciosi che i dispositivi che li usano si comportino come atteso.

La possibilità di avere un “certificato di garanzia di un dispositivo” è quindi una componente fondamentale del modello iDRM, tenendo presente che potrebbero benissimo esserci diversi “bollini” corrispondenti a diversi requisiti di robustezza per contenuti che richiedono appunto diversi requisiti. Potrebbero anche esserci casi in cui nessun “bollino” è necessario, anche se questo potrebbe creare confusione nel mercato.

La governance del sistema iDRM di Figura 5 – Struttura gerarchica per la certificazione e l’identificazione richiede quindi che ci siano diverse “agenzie” che, sotto la sorveglianza del sistema di governance (Authority), possano emettere, ovviamente a valle di un’istruttoria tecnica, il “bollino” ai dispositivi di un certo modello.

Similmente la governance richiede che i contenuti (rappresentati dalle strutture dati associati) siano univocamente identificati. Il processo di registrazione ed emissione di identificativi è attuato sotto la sorveglianza del sistema di governance e prevede l’esistenza di diverse “agenzie” che assegnano gli identitficativi all’interno di un name space loro assegnato.

Lo stesso metodo può essere adottato nell’identificare in modo univoco i dispositivi.

Figura 5 – Struttura gerarchica per la certificazione e l’identificazione

Una Catena del Valore è una rete di Dispositivi, eventualmente operati da Utenti, che eseguono delle azioni su Contenuti che vengono scambiati all'interno della Catena del Valore. Nella Figura 6 – Dispositivi in una catena del valore sono rappresentate le possibili relazioni tra i vari dispositivi in una catena del valore generica.

È opportuno far notare però che i Dispositivi della Figura 6 – Dispositivi in una catena del valore hanno un puro valore funzionale. Infatti lo schema può valere così com’è per un normale sistema di distribuzione in cui i contenuti sono venduti da un retailer, mentre in un sistema di distribuzione di contenuti con licenza Creative Commons il player (SAV), il dispositivo di creazione (CCD) ed il dispositivo di fornitura di contenuti (CPD) sono integrati in un singolo apparato,

Si può dire però in generale che la presenza di un dispositivo in una catena del valore può essee un segnale che quel particolare dispositivo abilita un modello di business.

Figura 6 – Dispositivi in una catena del valore

6. Che cosa è standardizzato in iDRM

Gli elementi standardizzati da iDRM sono dei Tool che realizzano le f unzionalità che sono necessarie per raggiungere da una parte l’interoperabilità, e dall’altra permettono di ottenere quella flessibilità di realizzazioni che sola dà un senso ad uno standard di DRM.

Gli elementi standardizzati da iDRM appartengono a 3 classi differenti:

Rappresentazione dell’informazione: gli elementi di questa classe hanno il compito di generare, analizzare e modificare le strutture dati necessarie per la gestione dei Contenuti.
Protocolli: gli elementi di questa classe hanno la funzione di gestire lo scambio di dati e l'interazione fra i Dispositivi
Package: gli elementi di questa classe gestiscono le operazioni di “impacchettamento” di Risorse, strutture dati ed eventuali altri medatati, in unità che si prestano al trasferimento come file o come stream.

iDRM adotta per queste tre classi quelle definite dalle specifiche Interoperable DRM Platform versione 3.2 (IDP-3.2) disponibili a [7]. Va comunque fatto rilevare che la parte di specifiche di IDP-3.2 relativa al dispositivo d’utente coincide con quella dello standard ISO/IEC 23000-5 [11].

dmin.it è ben conscio che le attuali specifiche iDRM possono richiedere aggiunte nel futuro.La politica generale è però di non fare proprie aggiunte ma di contribuire le necessarie proposte di estensioni per gli scopi di dmin.it alle specifiche e standard internazionali, e non di attuare delle proprie estensioni.

6. Software di riferimento

Il software di riferimento è basato su Chillout, un software Open Source rilasciato con licenza Mozilla [9]. È concepibile che dmin.it decida di creare un branch su Chillout per soddisfare suoi requisiti, perché i benefici immediati ottenibili da una tale azione devono essere ben valutati perché l’appartenenza di dmin.it alla più ampia comunità Chillout dà maggiori innegabili benefici, specie in un’ottica di esportazione del modello dmin.it.

L’architettura del software di riferimento è rappresentata dalla Figura 7 – Architettura del software di riferimento:

Figura 7 – Architettura del software di riferimento

Il software di riferimento prevede quindi che tutti i dispositivi della Figura 6 – Dispositivi in una catena del valore siano dotati della Core library che può essere sia quella Open Source di dmin.it, sia una realizzazione proprietaria, ma certificata (se richiesto dalla particolare Catena del Valore) che contiene gli elementi tecnologici che sono basati sugli elementi standardizzati nella proposta e che assicurano quindi l’interoperabilità tra Dispositivi. I Dispositivi possono anche essere dotati di Auxiliary Library che facilita lo sviluppo di applicazioni, ma non è di per sé indispensabile per l’interoperabilità. Ogni applicazione è invece costituita da codice che è tipicamente specifico del Dispositivo e può benissimo essere proprietaria.

Nella Figura 7 – Architettura del software di riferimento sono rappresentate le quattro liberie attualmente disponibili.

Core: implementa i formati standard IDP-3.2
Auxiliary: funzioni di utilità
Media Framework: co-decodifica audio e video e mux/demux
P2P: protocolli di ricerca e comunicazione peer-to-peer

Si noti che la libreria P2P è stata sviluppata da dmin.it e donata a DMP.

È opportuno far rilevare le librerie operano in un ambiente Java. Tuttavia l’uso di questo ambiente non è richiesto per raggiungere l’interoperabilità. Infatti la comunicazione tra dispositivi è attuata mediante protocolli realizzati in WSDL ed è del tutto agnostica all’ambiente. Alcuni partecipanti a dmin.it stanno già attuando realizzazioni alternative del software di riferimento in altri linguaggi.

6. Agganci a iNet e iPay

La piattaforma iDRM ed il sistema di pagamento proposto e interagiscono nei seguenti punti

Il venditore emette una Disposizione d’Incasso che contiene l’identificativo del contenuto (ed eventualmente della licenza) nel payload delle transazioni
Il venditore emette una licenza (temporanea o definitiva) a fronte di un pagamento e la rende disponibile all’acquirente
Il venditore non riconferma la licenza temporanea a fronte di una sincronizzazione fallita.

È da notare che potrebbero essere utilizzati protocolli di negoziazione della licenza in cui entrano in gioco le condizioni contro il valore monetario (a punti). In questo caso si svilupperanno altri punti di interazione.

La piattaforma iDRM ed il sistema di accesso aperto a internet a larga banda interagiscono in modi TBD.
Proposta di legge per il supporto legislativo a iDRM

7. Introduzione

Questa proposta di legge complementa gli interventi tecnici e le regole di governance che insieme permettono la realizzazione completa della proposta dmin.it per il sistema iDRM.

7. Testo della proposta

PROPOSTA DI LEGGGE

d’iniziativa _________

Modifica alla Legge 22 aprile 1941, n. 633 in materia di accesso ai contenuti digitali e di misure tecniche di protezione.

___________

Presentato il ________

___________

Art. 1.

Il Titolo II ter della Legge 22 aprile 1941, n. 633 è sostituito dal seguente:

TITOLO II-ter

Informazioni sul regime dei diritti, accesso ai contenuti digitali dotati di misure tecniche di gestione e protezione ed obblighi di interoperabilità

102-quater

Ogni qualvolta utilizzate nel presente titolo le espressioni che seguono avranno il significato di seguito indicato:

Misure tecniche di gestione e protezione dei diritti interoperabili: Le tecniche o i componenti destinati a gestire ed eventualmente tutelare, secondo le specifiche tecniche di interoperabilità, l’uso delle opere da parte degli utenti in conformità agli accordi con i titolari dei diritti;

Misure tecniche di gestione e protezione dei diritti proprietarie: le tecniche o i componenti che non sono basate sulle specifiche tecniche di interoperabilità

Specifiche tecniche di interoperabilità: Le specifiche di misure tecniche di gestione e protezione individuate in conformità all’art. 2 di questa legge

Dispositivi interoperabili: i dispositivi di creazione, distribuzione, elaborazione e riproduzione di contenuti digitali realizzati secondo le specifiche tecniche di interoperabilità

Dispositivi proprietari: i dispositivi di creazione, distribuzione, elaborazione e riproduzione di contenuti realizzati secondo specifiche diverse dalle specifiche tecniche di interoperabilità

102-quinquies

I titolari di diritti d'autore e di diritti connessi nonché del diritto di cui all'art. 102-bis, comma 3, possono apporre sulle opere o sui materiali protetti misure tecniche di gestione e protezione che comprendono tutte le tecniche, i dispositivi o i componenti che sono destinati a gestire ed eventualmente tutelare l’uso delle opere da parte degli utenti in conformità agli accordi con i titolari dei diritti.

Nel caso in cui un titolare di diritti decida di comunicare, distribuire e diffondere opere usando misure tecniche di gestione e protezione dei diritti proprietarie, questi deve parallelamente attuare una comunicazione, distribuzione e diffusione sullo stesso canale usando misure tecniche di gestione e protezione dei diritti interoperabili a condizioni economiche non discriminatorie nei confronti della propria offerta proprietaria.

Resta salva l'applicazione delle disposizioni relative ai programmi per elaboratore di cui al capo IV sezione VI del titolo I.

102 - sexies

Le Specifiche tecniche di interoperabilità, le modalità del loro aggiornamento ed i criteri per la verifica della conformità di una specifica misura tecnica di gestione alle Specifiche tecniche di interoperabilità sono stabilite con Deliberazione approvata dall’Autorità Garante delle Comunicazioni (di seguito l’Autorità).

Le specifiche tecniche di interoperabilità devono rispondere a criteri di apertura che ne consentano il controllo pubblico e l’esercizio da parte dell’Autorità dei poteri di cui al comma precedente, in particolare la possibilità di aggiornare ed estendere le Specifiche tecniche di interoperabilità.

Le specifiche tecniche di interoperabilità sono stabilite con Regolamento approvato dall’Autorità entro 120 giorni dall’entrata in vigore della legge _________[estremi della legge attraverso la quale si procederà alla modifica della Legge sul diritto d’autore].

L’Autorità d’ufficio o su istanza di un’associazione di utenti e consumatori determina la misura ed i termini in cui l’adozione di misure tecniche di gestione e protezione interoperabili non può precludere l’esercizio delle libere utilizzazioni di cui al Capo V, Titolo I in funzione del tipo di opera affetta da misure tecniche di gestione e protezione interoperabili, dei diversi modi di pubblicazione e delle possibilità offerte dalle tecnologie disponibili.

102 - septies

I titolari di diritti d'autore e di diritti connessi nonché del diritto di cui all'art. 102-bis e tutti i soggetti che adottano misure tecniche di gestione e protezione devono informare i legittimi utilizzatori delle opere a qualunque titolo circa i termini, le modalità ed i limiti di utilizzo delle opere stesse per effetto delle misure tecniche di gestione e protezione in conformità a quanto previsto nel Capo I del Titolo II del Decreto Legislativo 6 settembre 2005, n. 206.

È vietata la distribuzione e diffusione di contenuti gestiti e protetti da misure tecniche di gestione e protezione in assenza delle informazioni di cui al comma 1.

In caso di violazione delle previsioni di cui ai commi 1, 2 e 3 che precedono nonché di quelle di cui all’art. 102-sexies che precedono, le associazioni degli utenti e consumatori possono chiedere all’Autorità Giudiziaria del luogo presso il quale l’opera è resa accessibile al pubblico di obbligare il soggetto che commercializza l’ulteriore distribuzione al rispetto dei detti commi.

102 - octies

Informazioni elettroniche sul regime dei diritti possono essere inserite dai titolari di diritti d'autore e di diritti connessi nonché del diritto di cui all'art. 102-bis, comma 3, sulle opere o sui materiali protetti o possono essere fatte apparire nella comunicazione al pubblico degli stessi.

Le Misure tecniche di gestione e protezione dei diritti interoperabili possono identificare l'opera o il materiale gestito e/o protetto nonché l'autore o qualsiasi altro titolare dei diritti, fornire informazioni elettroniche sul regime dei diritti e contenere indicazioni circa i termini o le condizioni d'uso dell'opera o dei materiali, qualunque numero o codice che rappresenti le informazioni stesse o altri elementi di identificazione, eventualmente le modalità di protezione dell’informazione ed ogni altra funzionalità collegata con la gestione e la protezione dei diritti.

Le Misure tecniche di gestione e protezione dei diritti interoperabili non possono, in nessun caso, richiedere un trattamento dei dati personali dell’utente in assenza di sua autorizzazione.

Art. 2.

È costituito all’interno dell’Autorità un Comitato di controllo per le misure tecniche di gestione e protezione interoperabili (di seguito il Comitato di controllo)

Il Comitato di controllo è costituito da rappresentanti degli autori, produttori, editori, fornitori di servizi e consumatori.

Entro 30 giorni dall’entrata in vigore della presente legge il Consiglio dell’Autorità determina la composizione del Comitato di controllo identificando le organizzazioni che possono esprimere i componenti.

Entro 60 giorni dall’entrata in vigore della presente legge il Consiglio dell’Autorità approva un regolamento per disciplinare il funzionamento del Comitato di controllo e per l’esercizio da parte di quest’ultimo dei poteri attribuitigli con la presente legge.

I compiti del Comitato di controllo sono:

Determinare le modalità che assicurino un adeguato livello di sostenibilità economica della governance delle Specifiche tecniche di interoperabilità;
Amministrare il processo di verifica della conformità dei Dispositivi e dei Contenuti interoperabili alle Specifiche tecniche di interoperabilità;
Fornire al Consiglio dell’Autorità proposte e pareri di natura tecnica ed ecomica per le Deliberazioni che l’Autorità è chiamata ad emettere;
Dirimere le controversie tra i soggetti che adottano misure tecniche di gestione e protezione interoperabili e gli utilizzatori delle opere a qualunque titolo, incluse le loro associazioni.
In generale curare la gestione ordinaria delle Specifiche tecniche di interoperabilità;
Proporre azioni volte a correggere, mantenere tecnicamente competitive od estendere le Specifiche tecniche di interoperabilità
Gestire il processo di correzione, mantenimento della competitività tecnica ed estensione dell’ambito delle Specifiche tecniche di interoperabilità;
Valutare periodicamente l’adeguatezza dell’uso delle Misure tecniche di gestione e protezione interoperabili alle necessità sociali e culturali del paese ed eventualmente proporre azioni migliorative o correttive.

7. Relazione con altre proposte di interventi legislativi

TBD

Governance del sistema iDRM

8. Introduzione

Questo documento definisce i principi e le modalità operative della governance del sistema DRM tecnicamente specificato e legislativamente normato da questo documento.

8. Obiettivi del Trust Model di iDRM

Il sistema di governance del sistema iDRM necessita di un Trust Model per far sì che ogni attore della catena del valore, ed in particolare un produttore/fornitore di contenuti, sia convinto che tutti gli altri attori, ad esempio fornitori di servizio, produttori di dispositivi, fornitori di tecnologie di sicurezza ecc. sono affidabili come business partner, e quindi invogliarlo a far sì che i loro contenuti digitali siano disponibili al mercato, che altrimenti non esisterebbe senza contenuti. Questo non solo per i grandi fornitori di contenuti, ma anche in modo specifico i piccoli content provider ed i prosumer, che sono il nuovo mercato che si può aprire in Italia grazie all’iDRM.

Da questo discende la necessità che il Trust Model sia articolato in modo da rendere fattibili tecnicamente e sostenibili economicamente cicli di business molto diversi fra loro. Si può pensare infatti di avere livelli diversi di “sicurezza di sistema” a cui corrispondono in generale costi implementativi diversi, adatti ai diversi segmenti di mercato, e che sono tenuti a rispettare rigorosamente un principio di gerarchie di livello, nel senso che eventuali semplificazioni introdotte ai livelli meno critici non possano in alcun modo costituire una minaccia per la sicurezza dei livelli più sensibili. Ciò si potrebbe tradurre nel vincolo realizzativo per cui un dispositivo che ottempera ai requisiti di un livello di sicurezza inferiore non può accedere a contenuti per i quali sia richiesto possedere caratteristiche più stringenti. Tali contenuti potranno naturalmente essere fruibili su dispositivi di livello di sicurezza superiore.

Evidentemente questo requisito, oltre ad avere un impatto sull’aspetto tecnologico del problema risulta essere soprattutto un problema di contrattualistica e di gestione degli oneri economico-implementativi a carico dei singoli attori, gestione che deve essere adatta o adattabile ai diversi contesti. Infatti i costi di ingresso e permanenza nell’ecosistema devono essere costruiti in modo tale da rendere percorribile un cammino di ingresso nel business anche da parte del piccolo produttore/fornitore di servizio, e non costituire una barriera tale da consentire l’ingresso nel mercato solo ai grandi attori.

Il Trust Model di iDRM si organizza attorno a tre componenti base:

Il processo di accettazione ed integrazione nel sistema iDRM di qualunque dispositivo gestisca i contenuti o le licenze
Il processo run-time legato al comportamento dei dispositivi legati al consumo di contenuti, che riguarda principalmente la verifica delle licenze e la gestione delle anomalie riscontrate nei dispositivi, con tutti i livelli di escalation necessari
Lo schema legale/normativo/contrattuale che lega i diversi attori fra di loro, attribuisce le responsabilità e garantisce il sistema nei confronti dei danni che possono derivare da comportamenti “malicious” di clienti finali e di attori stessi.

Di queste tre componenti vanno definiti:

Le logiche di governo e di funzionamento, che devono poi trovare riscontro nelle relative componenti operative/processive
I costi di funzionamento ed i meccanismi che garantiscono la relativa sostenibilità economica.

8. Processo di certificazione

L’accettazione ed integrazione nel sistema iDRM di un dispositivo (hardware o software) si basa sul seguente processo:

Esistono diverse macro-categorie di dispositivi: terminali per la fruzione di contenuti sicuri (es: STB, cellulare…) ed altri dispositivi usati in altri punti di una catena del valore, e.g. per la produzione e distribuzione di contenuti. Il Trust Model deve necessariamente coprire efficacemente tutti i dispositivi.
Le specifiche iDRM sono aperte e pubbliche, quindi chiunque può implementarle. È però necessario che ogni produttore assicuri una implementazione corretta e se ne assuma la responsabilità, il che si traduce anche nell’adesione formale ad un sistema contrattuale vincolante che garantisca tutti gli attori (vedi punto 3).
Esiste una Autorità Centrale (AC), ovvero l’ente di governo dell’intero sistema, che deve quindi essere unica a livello nazionale, che garantisce che un’implementazione delle specifiche iDRM sia corretta e robusta^{^[4]}.
Per la verifica puntuale della correttezza e della robustezza delle implementazioni AC si avvale di un organo tecnico specificatamente competente, chiamato Laboratorio Accreditato (LA).
Al fine di facilitare le corrette implementazioni delle specifiche, LA rilascia anche delle linee guida che sono in grado di aiutare il costruttore nel processo di realizzazione di un dispositivo conforme allo standard.
Se LA debba o possa essere una entità societaria differente dalla AC con una sua specifica ragione sociale oppure sia semplicemente un dipartimento operativo della AC stessa è un elemento da definire nel completamento architettura del sistema di governance. Tale scelta potrà essere definita sulla base di convenienze economiche o considerazioni di attribuzione di responsabilità e/o conflitto di interessi.
In una prima fase è conveniente che esista un solo LA ma in futuro è possibile (anzi auspicabile) che esistano più LA, eventualmente specializzati per diverse tipologie di certificazione, il cui processo di accreditamento, nei suoi aspetti formali e sostanziali, è compito specifico di AC.
Poiché l’accettazione di un dispositivo implica, a valle di verifiche positivamente concluse da parte di LA, il rilascio di una Certificazione di Conformità con caratteristiche di univocità rispetto al modello del dispositivo, LA deve ricevere notifica dell’identitificativo di ogni dispositivo e del relativo modello certificato che il costruttore produce e immette sul mercato.
Tale Certificazione di Conformità si tradurrà concretamente in un Certificato che dovrà essere univocamente abbinato all’anagrafe del dispositivo e risiedere all’interno di ogni singolo dispositivo prodotto in modo da non poter essere in nessun modo manomittibile da parte degli utilizzatori del dispositivo stesso.
La produzione del Certificato integrato con i dati anagrafici nonché il suo inserimento in modo sicuro nel singolo dispositivo è una operazione affidata ad ogni singolo costruttore, che dovrà comunicare a LA l’anagrafe completa dei dispositivi prodotti (e di conseguenza dei Certificati in essi installati). Il processo con il quale il costruttore assegna ed introduce i Certificati nel dispositivo è a sua volta oggetto di verifica nel processo di certificazione svolto da LA.
In un qualunque momento il Certificato rilasciato al singolo dispositivo potrà essere invalidato/revocato da LA, sulla base di considerazioni di sicurezza di sistema.
Oltre a tale sistema di revoca puntuale, si possono immaginare altre logiche di revoca che operino su base aggregata, ad esempio su base costruttore, su base geografica/regionale o altro; è quindi necessario che il meccanismo di creazione dei certificati (comprensivo del sistema di anagrafe) utilizzato da ogni costruttore sia strutturato gerarchicamente in modo da supportare in modo efficiente tutte le logiche che LA, eventualmente su disposizione di AC, riterrà necessarie realizzare nel sistema.

Nel caso in cui il dispositivo sia basato sulla tecnologia TPM, la governance è attuata secondo i seguenti principi

dmin.it definisce le specifiche di interfacciamento di iDRM con il TPM
dmin.it estende la sua reference implementation aggiungendo l'interfacciamento con il TPM
Il LA dell'AC garantisce che un'implementazione di un dispositivo costituito da un hardware con TPM e con un software realizzato con la reference implementation è "corretta e robusta"
L'AC gestisce una Certification Authority (CA) attraverso il LA, oppure utilizza una della CA esistenti e riconosciute dal TCG, da cui è possibile scaricare un eseguibile che è garantito essere il compilato del sorgente (punto 3.) distribuito in OSS
Il TPM riconosce la CA del punto 4. ed esegue il binario come software certificato per il dispositivo
Chiunque può fare modifiche al codice del punto 3., verificandone le funzionalità in un ambiente di test, e risottometterlo al LA che, esaminatolo, ne mette a disposizione il sorgente in OSS e il corrispondente binario certificato scaricabile attraverso la CA
Chi ha fatto le modifiche si assume le responsabilità di cui alla sezione 8.5
Chi sviluppa un software proprietario di iDRM che non intende distribuire in OSS deve sottometterlo al LA che ne certifica la conformità
Il software del punto 8. è accessibile dalla CA ed eseguito da un hardware con TPM.

8. Processo run-time legato al consumo di contenuti

Il processo run-time legato al consumo di contenuti, che riguarda principalmente la verifica delle licenze e la gestione delle anomalie riscontrate, con tutti i livelli di escalation necessari deve tener conto dei seguenti elementi:

La licenza che contiene i diritti di utilizzo e/o trattamento del contenuto per essere interpretata ha bisogno di verificare che il dispositivo su cui essa viene scaricata e successivamente interpretata sia un dispositivo correttamente abilitato a fare ciò.
La correttezza del dispositivo è garantita dalla presenza all’interno del dispositivo stesso di un certificato di sicurezza valido. La validità del certificato del singolo dispositivo può essere verificata in qualsiasi momento.
Se il sistema iDRM opera utilizzando una infrastruttura bidirezionale, la verifica può essere fatta interrogando opportunamente LA, che attraverso suoi specifici meccanismi (quali ad esempio la consultazione di una Certificate Revocation List) può confermare o meno la validità.
Se il sistema opera su una infrastruttura di distribuzione del Digital Media esclusivamente monodirezionale, la validità dovrà essere confermata da un riferimento auto-esplicativo interno al device, come ad esempio una data di scadenza del certificato presente nel dispositivo. In questo caso il rinnovo del certificato del device potrà richiedere al proprietario di connettere il dispositivo ad un elemento periferico (es: dongle USB, smart card specifica ecc…)

8. Schema legale/normativo/contrattuale

Lo schema è basato sui seguenti punti:

La “root authority” della governance iDRM risiede nell’Autorità Centrale (AC). La sua eventuale scomparsa come soggetto economico/giuridico implica lo scioglimento del mercato.
L’operatività tecnica è gestita dal Laboratorio Accreditato (LA) che opera su mandato, al momento esclusivo, di AC.
La certificazione è rilasciata da LA, attraverso cui devono passare obbligatoriamente i costruttori che vogliono operare sul mercato coperto dall’iDRM. I singoli Certificati sono immessi nei dispositivi dai costruttori, che ne notificano gli estremi a LA.
Il rapporto fra LA e costruttori e regolato da un contratto in cui il costruttore ammette la sua liability in caso di infrazione realizzata sul dispositivo da lui costruito. La liability deve essere garantita da una assicurazione/fideiussione.
La AC si configura come il punto unico di interfaccia per la garanzia di sicurezza nei confronti dei Content Providers, sia per i premium content sia per tutti gli altri tipi di contenuti.

Lo schema di riferimento che si configura fra i diversi soggetti è quindi rappresentato dalla Figure 8 – Modello di Riferimento del Trust Model di iDRM:

Figure 8 – Modello di Riferimento del Trust Model di iDRM

8. Gli economics di sistema

L’Autorità Centrale (AC) è una organizzazione “no profit”, costituita con un capitale iniziale che deriva dal versamento dei soci fondatori, il cui funzionamento si basa su un meccanismo di ricopertura dei costi. Per condurre le verifiche tecniche necessarie per il funzionamento del sistema iDRM, AC organizza un proprio LA interno. Il “costo” della singola istanza del certificato di conformità è determinato da LA ed approvato da AC sulla base del principio di ricopertura costi, fatto a livello di bilancio da un anno all’altro. Il processo, che deve essere in grado di supportare una eventuale espansione del numero dei LA che operano per la AC, sarà oggetto di ulteriore studio nel corso dello sviluppo del sistema iDRM.

Il sistema di sicurezza garantito dalla AC deve rispondere a requisiti di affidabilità in grado di soddisfare sia i più esigenti fornitori di Contenuti Premium, con inevitabili costi implementativi di un certo rilievo, e sia fornitori di contenuti anche di dimensioni contenute, fino al profilo prosumer. È necessario pertanto che la governance del sistema iDRM sia progettata per essere in grado di differenziare gli impegni economici a carico dei diversi soggetti in funzione del livello di sicurezza che gli aventi diritto desiderano garantire per i propri prodotti, al fine di garantire un adeguata possibilità di sviluppo anche al mercato dei piccoli produttori.

La Figure 9 – Possibile schema dei flussi fra operatori nel sistema iDRM indica a titolo di esempio un possibile schema dei flussi che intercorrono fra gli attori in relazione alle dipendenze di responsabilità (frecce nere) e relativi corsi economici che possono svilupparsi in caso di effrazione del sistema.

Figure 9 – Possibile schema dei flussi fra operatori nel sistema iDRM

Specifiche di iNet

9. Introduzione

Questo capitolo specifica il sistema di accesso aperto a internet a larga banda.

9. Schema di riferimento

Si fa riferimento a Figura 2 – Accesso aperto a internet a larga banda

9. Accesso d’utente

Requisiti essenziali di servizio di accesso a “big Internet”, “service agnostic sono:

Assegnazione statica o dinamica di almeno un indirizzo IP “pubblico”;
Nessuna limitazione sul numero di port numbers (TCP, UDP) utilizzabili;
Nessun filtraggio selettivo del traffico su base:
1. “Port number”;
2. Indirizzi destinazione o sorgente;
3. Servizio applicativo utilizzato;

Inoltre sono servizi indispensabili:

Risoluzione dei nomi (DNS);
Mail forwarding (SMTP).

Allo stato attuale non viene presa in considerazione la compatibilità con IPv6.

Requisiti opzionali sono funzionalità di:

Accesso “premium” per specifiche direttrici di traffico;
Multicast e/o streaming (con controllo della banda utilizzata e prioritizzazione del traffico)

9. Interfacce e protocolli tra operatori

Per quanto riguarda il peering, la specifica BGP-4 definisce in dettaglio come devono comportarsi gli operatori al punto di interconnessione, sia questo di tipo 1:1 sia di tipo NxN. La pubblicazione delle policy di peering adottate, ad esempio nel Data Base mantenuto da RIPE-NCC per quanto riguarda l’Europa, è garanzia di ulteriore trasparenza, nonché strumento utile per la manutenzione delle reti.

Qualora l’operatore offra servizi con QoS, area ancora non consolidata, lungo la catena end-to-end devono essere soddisfatti i seguenti requisiti:

Più classi di servizio in numero prefissato (in dipendenza dalla tecnologia adottata);
Mantenimento dei livelli di servizio previsti da ogni classe lungo tutta la catena, dal nodo sorgente al nodo destinazione;
Equivalenza delle classi di servizio di ogni operatore alla frontiera di peering;
Uniformità di QoS per il traffico di una classe di servizio, indipendentemente dalle caratteristiche del traffico (indirizzi sorgente/destinazione, port number, applicazione);
Responsabilità del controllo di flusso al nodo sorgente.

Inoltre devono essere specificati i Service Level Agreement (SLA) che gli operatori sottoscrivono al fine di rendere interoperabili i loro servizi di QoS. Tali SLA potranno essere diversi nel caso di

Peering “privato”, cioè attraverso un collegamento diretto;
Peering “pubblico”, cioè realizzato presso un Network Access Point (NAP).

9. Software di riferimento

Questo è probabilmente non richiesto.

9. Agganci a iDRM e iPay

Questi sono ancora da considerare.

10 Proposta di legge per il supporto legislativo ad iNet

10.1 Introduzione

Questa proposta di legge complementa gli interventi tecnici e le regole di governance che insieme permettono la realizzazione completa della proposta dmin.it nell’area di accesso aperto ad internet a larga banda.

10.2 Testo della proposta

PROPOSTA DI LEGGGE

d’iniziativa _________

Modifica alla Legge 1 agosto 2003, n. 259 in materia di accesso aperto alla rete intenet a larga banda.

___________

Presentato il ________

___________

(in corsivo le aggiunte proposte al testo della legge attuale)

Art. 1

Definizioni

1. Ai fini del presente Codice si intende per:

qq. “peering”: la interconnessione di reti a commutazione di pacchetto amministrativamente separate al fine di assicurare lo scambio di traffico tra utenti di ciascuna rete.

rr. “Punti di Accesso Neutrale”: servizi pubblici o privati o di natura consortile che consentono, a condizioni eque, trasparenti e non discriminatorie, l’accesso fisico a operatori di reti pubbliche a commutazione di pacchetto al fine di implementare accordi di peering.

Art. 15

Numerazione, assegnazione dei nomi a dominio e indirizzamento

Il Ministero controlla l’assegnazione di tutte le risorse nazionali di numerazione e la gestione del piano nazionale di numerazione, garantendo che a tutti i servizi di comunicazione elettronica accessibili al pubblico siano assegnati numeri e blocchi di numeri adeguati. Il Ministero, altresì, vigila sull’assegnazione dei nomi a dominio e indirizzamento.

L’Autorità stabilisce il piano nazionale di numerazione e le procedure di assegnazione della numerazione nel rispetto dei principi di obiettività, trasparenza e non discriminazione, in modo da assicurare parità di trattamento a tutti i fornitori dei servizi di comunicazione elettronica accessibili al pubblico. In particolare, l’Autorità vigila affinché l’operatore cui sia stato assegnato un blocco di numeri non discrimini altri fornitori di servizi di comunicazione elettronica in relazione alle sequenze di numeri da utilizzare per dare accesso ai loro servizi.

L’Autorità pubblica il piano nazionale di numerazione e le sue successive modificazioni ed integrazioni, con le sole restrizioni imposte da motivi di sicurezza nazionale.

L’Autorità promuove l’armonizzazione delle risorse di numerazione all’interno dell’Unione europea ove ciò sia necessario per sostenere lo sviluppo dei servizi paneuropei.

Il Ministero vigila affinché non vi siano utilizzi della numerazione non coerenti con le tipologie di servizi per i quali le numerazioni stesse sono disciplinate dal piano nazionale di numerazione.

Il Ministero e l’Autorità, al fine di assicurare interoperabilità completa e globale dei servizi, operano in coordinamento con le organizzazioni internazionali che assumono decisioni in tema di numerazione, assegnazione di nomi a dominio e indirizzamento delle reti e dei servizi di comunicazione elettronica assicurandone la piena interoperabilità a livello internazionale sulla base dei principi assunti dalle organizzazioni internazionali di standardizzazione.

Per l’espletamento delle funzioni di cui al presente articolo, l’Istituto superiore delle comunicazioni e delle tecnologie dell’informazione presta la sua collaborazione all’Autorità.

Art. 41

Diritti ed obblighi degli operatori

Gli operatori di reti pubbliche di comunicazione hanno il diritto e, se richiesto da altri operatori titolari di un'autorizzazione dello stesso tipo, l'obbligo di negoziare tra loro l'interconnessione ai fini della fornitura di servizi di comunicazione elettronica accessibili al pubblico, allo scopo di garantire la fornitura e l'interoperabilità dei servizi in tutta l’Unione europea. Gli operatori offrono l’accesso e l’interconnessione ad altri operatori nei termini e alle condizioni conformi agli obblighi imposti dall’Autorità ai sensi degli articoli 42, 43, 44 e 45, e nel rispetto dei principi di cui all’articolo 13, comma 5, lettera b).

Le reti pubbliche di comunicazione elettronica realizzate per distribuire servizi di televisione digitale devono essere in grado di distribuire servizi e programmi televisivi in formato panoramico. Gli operatori di rete che ricevono e redistribuiscono servizi e programmi televisivi in formato panoramico mantengono il formato panoramico dell'immagine.

Fatto salvo l'articolo 33, gli operatori che ottengono informazioni da un altro operatore prima, durante o dopo il negoziato sugli accordi in materia di accesso o di interconnessione utilizzano tali informazioni esclusivamente per i fini per cui sono state fornite e osservano in qualsiasi circostanza gli obblighi di riservatezza delle informazioni trasmesse o memorizzate. Le informazioni ricevute non sono comunicate ad altre parti, in particolare ad altre unità organizzative, ad altre società consociate o partner commerciali, per i quali esse potrebbero rappresentare un vantaggio concorrenziale

Gli operatori di reti pubbliche a commutazione di pacchetto che offrono servizi di accesso ad Internet, hanno l’obbligo di garantire un peering pubblico presso un Punto di Accesso Neutrale, a qualità trasparente e non discriminatoria. Gli operatori hanno l’obbligo di rendere pubblici i propri criteri per il peering e, se richiesti da altri operatori titolari di una autorizzazione dello stesso tipo, hanno l’obbligo di concedere il peering a qualunque soggetto che rispetti i criteri adottati. I criteri dovranno essere trasparenti e non discriminatori. Qualora il peering avvenga presso un punto neutrale, nessun operatore potrà immotivatamente negare il peering ad altro operatore ivi presente, se titolare dello stesso titolo autorizzativo.

Art. 46

Obbligo di trasparenza

Ai sensi dell’articolo 45, l’Autorità può imporre obblighi di trasparenza in relazione all'interconnessione, al trasporto e all'accesso, prescrivendo agli operatori di rendere pubbliche determinate informazioni quali informazioni di carattere contabile, specifiche tecniche, caratteristiche della rete, termini e condizioni per la fornitura e per l'uso, prezzi.

In particolare, l’Autorità può esigere che, quando un operatore è assoggettato ad obblighi di non discriminazione ai sensi dell’articolo 47 pubblichi un'offerta di riferimento sufficientemente disaggregata per garantire che gli operatori non debbano pagare per risorse non necessarie ai fini del servizio richiesto e in cui figuri una descrizione delle offerte suddivisa per componenti in funzione delle esigenze del mercato, corredata dei relativi termini, condizioni e prezzi. L'Autorità con provvedimento motivato può imporre modifiche alle offerte di riferimento in attuazione degli obblighi previsti dal presente Capo.

L’Autorità può precisare quali informazioni pubblicare, il grado di dettaglio richiesto e le modalità di pubblicazione delle medesime.

In deroga al comma 3, se un operatore è soggetto agli obblighi di cui all'articolo 49 relativi all'accesso disaggregato alla rete locale a coppia elicoidale metallica, l’Autorità provvede alla pubblicazione di un'offerta di riferimento contenente almeno gli elementi riportati nell'allegato n. 3.

L’Autorità può definire ulteriori misurazioni statistiche che permettano di caratterizzare, per i servizi offerti agli utenti finali e tra operatori, le prestazioni multimediali, ivi comprese le prestazioni di unicast e multicast tra utenti e verso i Punti di Accesso Neutrale, dei servizi dei diversi operatori che offrono servizi di accesso ad Internet imponendone l’obbligo di pubblicazione.

Art. 72

Qualità del servizio

L’Autorità, dopo aver effettuato la consultazione di cui all’articolo 83, può prescrivere alle imprese fornitrici di servizi di comunicazione elettronica accessibili al pubblico di pubblicare, a uso degli utenti finali, informazioni comparabili, adeguate ed aggiornate sulla qualità dei servizi offerti. Le informazioni sono comunicate, a richiesta, anche all'Autorità prima della pubblicazione.

L’Autorità precisa, tra l'altro, i parametri di qualità del servizio da misurare, nonché il contenuto, la forma e le modalità della pubblicazione, per garantire che gli utenti finali abbiano accesso ad informazioni complete, comparabili e di facile consultazione, anche utilizzando i parametri, le definizioni e i metodi di misura indicati nell'allegato n. 6.

Gli operatori di reti pubbliche a commutazione di pacchetto che offrono servizi di accesso ad Internet, hanno l’obbligo di fornire agli utenti, un servizio base di collegamento ad Internet che non discrimini le comunicazioni sulla base di terminali sorgente e destinatario, nè del tipo di servizio di comunicazione elettronica effettuato, nè dei suoi contenuti. Il servizio base deve essere garantito a condizioni eque, trasparenti e non discriminatorie rispetto ad altre offerte praticate agli utenti.

10.3 Relazioni con altre proposte di interventi legislativi

Queste sono anora da identificare

11 Governance del sistema iNet

11.1 Introduzione

Questo documento definisce i principi e le modalità operative della governance dell’accesso aperto ad internet a larga banda sistema tecnicamente specificato da [4] e legislativamente normato da [7].

11.2 Obiettivi della governance dell’accesso aperto ad internet a larga banda

Le attività della governance dell’accesso aperto ad internet a larga banda sono finalizzate ad assicurare agli utenti del sistema iNet definito da dmin.it la massima circolazione dei contenuti concordando tra gli operatori le modalità tecniche per l’eliminazione di vincoli o barriere tecnologiche che ne possano ostacolare la diffusione, secondo i principi descritti in [3.2] e le caratteristiche tecniche definite in [9.3] e [9.4].

11.3 Operatività della governance dell’accesso aperto ad internet a larga banda

La funzione di Governance è svolta da un organismo di rappresentanza degli operatori e delle istituzioni pertinenti che ne facciano richiesta secondo criteri stabiliti dagli operatori e dalle istituzioni stesse.

La governance è assicurata mediante accordi collettivi tra gli operatori di accesso che stabiliscono le regole operative relative alla definizione, implementazione, verifica, sanzione e correzione delle specifiche tecniche relative alla interoperabilità delle proprie reti e della loro implementazione, finalizzate ad assicurarne la piena interoperabilità sulla base dei principi definiti dalle organizzazioni internazionali di standardizzazione e secondo le migliori pratiche internazionali.

La governance concorda le modalità di verifica, sanzione, risoluzione delle controversie e correzione della coerenza delle pratiche degli operatori in riferimento agli impegni di peering, QoS, e trasparenza dei relativi criteri. La governance verifica inoltre la documentazione pubblica delle offerte degli operatori al fine di assicurare le previsioni di cui al punto [3.2] e stabilisce modalità attuative tecniche e procedurali di eventuali verifiche tecniche. Nello svolgimento di queste attività, la governance pubblica tutte le misurazioni statistiche e informazioni relative alla esecuzione degli accordi di peering e relativo QoS, cosi’ come delle offerte al pubblico.

12 Specifiche di iPay

12.1 Introduzione

Questo capitolo contiene la specifica tecnica del sistema di registrazione e conversione punti per digital media di Digital Media in Italia (dmin.it).

12.2 Schema di riferimento

Si fa riferimento a Figure 3 – Sistema di registrazione e conversione punti per digital media.

12.3 Gli elementi da standardizzare

In questa sezione si elencano gli elementi che richiedono standardizzazione.

12.3.1 Gli attori

Il sistema dmin.it ha 4 tipologie di attori:

Il Subscriber
Il VASP
I Servizi Condivisi
I circuiti tradizionali di pagamento

12.3.2 Le comunicazioni

Gli attori comunicano tra di loro. Per ognuna di queste comunicazioni devono essere definiti:

Il protocollo
Il formato dei dati scambiati

12.4 Rappresentazione XML delle strutture dati

In questa sezione sono riportati i messaggi scambiati tra i tre seguenti attori nel sistema: i Subscriber (SU), che possono distinguersi a loro volta in Buyers (BU) o Sellers (SE), i VASP (VA) e gli Shared Services (SS), inclusa una descrizione ad alto livello delle informazioni contenute in ciascun messaggio. Ogni messaggio deve essere firmato dal mittente, e la firma deve essere inclusa nell'elemento dsig:Signature in ciascun messaggio. Nello stesso file .zip con questo documento sono date date le complete rappresentazioni XML dei payload.

Nota: i nomi delle entità usati nella specifica sono in inglese per facilitarne un’eventuale “esportabilità”. È possibile si richieda la rettifica di alcuni nomi per allinearli alla corretta dicitura inglese.

12.4.1 Creazione account (createAccount)

Nel momento in cui un nuovo utente decide di aprire un Virtual Account, i seguenti messaggi vengono scambiati tra i vari attori:

12.4.1.1 Subscriber – VASP

CreateSubscriberAccount_SU-VA (opzionale) può essere inviato da un Subscriber ad un VASP per richiedere la creazione di un nuovo Virtual Account.

</sequence>

</extension>

</complexContent>

</complexType>

Figure 10 – CreateSubscriberAccount_SU-VA

Questo messaggio contiene informazioni personali del richiedente, informazioni sul circuito reale sul quale intende appoggiare quello virtuale, ed eventuali opzioni riferite al tipo di account di cui richiede la creazione.

12.4.1.2 VASP – SS

CreateSubscriberAccount_VA-SS è inviato da un VASP ai Servizi Condivisi per richiedere un dentificativo per l'utente che richiede la creazione di un Virtual Account.

</sequence>

</extension>

</complexContent>

</complexType>

Figure 11 – CreateSubscriberAccount_VA-SS

Questo messaggio contiene informazioni personali del richiedente.

12.4.1.3 SS – VASP

CreateSubscriberAccount_SS-VA è inviato dai Servizi Condivisi ad un VASP in risposta ad un messaggio CreateSubscriberAccount_VA-SS.

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

</complexContent>

</sequence>

</extension>

</complexContent>

</complexType>

</restriction>

</simpleType>

Figure 12 – CreateSubscriberAccount_SS-VA

Questo messaggio contiene l'identificativo del richiedente, che è generato sul momento qualora l'utente non fosse ancora registrato presso i Servizi Condivisi.

12.4.1.4 VASP – Subscriber

CreateSubscriberAccount_VA-SU è inviato da un VASP in risposta ad un messaggio CreateSubscriberAccount_SU-VA dopo aver ricevuto il messaggio CreateSubscriberAccount_SS-VA in risposta dai Servizi Condivisi.

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 13 – CreateSubscriberAccount_VA-SU

Questo messaggio contiene l'identificativo del richiedente e le informazioni relative al nuovo Virtual Account, se questo è stato creato con successo, oppure un codice d'errore.

12.4.2 Disposizione d'incasso

Nel momento in cui un venditore riceve un ordine d'acquisto, i seguenti messaggi vengono scambiati tra i vari attori:

12.4.2.1 Subscriber (SE)– VASP

CashOrder_SE-VA è inviato da un Subscriber venditore al suo VASP.

</sequence>

</extension>

</complexContent>

</complexType>

</restriction>

</simpleType>

Figure 14 – CashOrder_SE-VA

Questo messaggio contiene un identificativo dell'ordine, informazioni su come la licenza per il contenuto può essere ottenuta, le informazioni sull'acquirente e sul VASP stesso, informazioni sul conto corrente virtuale su cui il pagamento dovrà essere depositato, l'ammontare della cifra e l'IVA sulla transazione.

12.4.2.2 VASP – VASP

CashOrder_VA-VA è inviato dal VASP del venditore al VASP dell'acquirente.

</sequence>

</extension>

</complexContent>

</complexType>

Figure 15 – CashOrder_VA-VA

12.4.2.3 VASP – Subscriber (BU)

CashOrder_VA-BU è inviato dal VASP dell'acquirente all'acquirente.

</sequence>

</extension>

</complexContent>

</complexType>

Figure 16 – CashOrder_VA-BU

Questo messaggio contiene un identificativo dell'ordine, informazioni su come la licenza per il contenuto può essere ottenuta, le informazioni sul venditore, informazioni sul conto corrente virtuale su cui il pagamento dovrà essere depositato, l'ammontare della cifra e l'imposta sulla transazione.

12.4.3 Disposizione di pagamento

Nel momento in cui un acquirente riceve una disposizione d'incasso, i seguenti messaggi vengono scambiati tra i vari attori:

12.4.3.1 Subscriber (BU) – VASP

PaymentOrder_BU-VA è inviato dall'acquirente al suo VASP.

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 17 – PaymentOrder_BU-VA

Questo messaggio può contenere sia una disposizione di pagamento, sia il rifiuto della disposizione d’incasso. Nel primo caso, il messaggio contiene lo stesso identificativo presente nella disposizione d'incasso, informazioni su come la licenza per il contenuto può essere ottenuta, le informazioni sull'acquirente, informazioni sul conto corrente virtuale da cui effettuare il pagamento, l'ammontare della cifra, il beneficiario del pagamento e le informazioni sul Virtual Account su cui l'ammontare dovrà essere trasferito, e l'imposta sulla transazione. In caso di fallimento viene fornito un messaggio che informa sul possibile problema che ha impedito di completare la transazione

12.4.3.2 VASP – VASP

PaymentOrder_VA-VA è inviato dal VASP dell'acquirente al VASP del venditore.

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 18 – PaymentOrder_VA-VA

Questo messaggio può contenere sia una disposizione di pagamento, sia un rifiuto di procedere al pagamento. Nel primo caso, il messaggio contiene lo stesso identificativo presente nella disposizione d'incasso, informazioni su come la licenza per il contenuto può essere ottenuta, le informazioni sull'acquirente, informazioni sul conto corrente virtuale da cui effettuare il pagamento, l'ammontare della cifra, il beneficiario del pagamento e le informazioni sul Virtual Account su cui l'ammontare dovrà essere trasferito, e l'imposta sulla transazione. A seguito di questo messaggio inviato correttamente, il VASP emittente scalerà l'ammontare specificato dal Virtual Account del compratore, mentre il VASP ricevente aggiungerà lo stesso ammontare sul Virtual Account del venditore.

12.4.3.3 VASP – Subscriber (SE)

PaymentOrder_VA-SE è inviato dal VASP del venditore al venditore.

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 19: PaymentOrder_VA-SE

Questo messaggio può contenere sia una conferma di pagamento, sia un rifiuto di pagamento. Nel primo caso, il messaggio contiene lo stesso identificativo presente nella disposizione d'incasso, informazioni sulla licenza, le informazioni sull'acquirente, informazioni sul conto corrente virtuale da cui il pagamento è stato effettuato, l'ammontare della cifra, e l'imposta sulla transazione.

12.4.4 Caricamento dati utente insolvente

Nel momento in cui un VASP non è in grado di effettuare una sincronizzazione tra il Virtual Account ed il circuito reale di un suo Subscriber, il seguente messaggio viene inviato dal VASP ai Servizi Condivisi.

12.4.4.1 VASP – SS

StoreSubscriberData_VA-SS è inviato dal VASP di un Subscriber in default ai Servizi Condivisi.

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 20 – StoreSubscriberData_VA-SS

Questo messaggio contiene un identificativo di questo rapporto, l'identificativo dell'utente in default, la data e l'ora in cui la sincronizzazione è fallita, a quanto ammonta il default dell'utente, il proprio identificativo, e la lista degli identificativi delle transizioni affetti dalla sincronizzazione non riuscita.

12.4.5 Consultazione dati utente

I seguenti messaggi vengono impiegati per richiedere la lista dei default di un utente in un certo periodo temporale ai Servizi Condivisi, e per contenere la risposta. Solo un VASP può fare questo.

12.4.5.1 VASP – SS

RetrieveSubscriberData_VA-SS è inviato dal VASP di un Subscriber in default ai Servizi Condivisi per richiedere la lista dei default di un utente in un determinato periodo temporale.

</sequence>

</extension>

</complexContent>

</complexType>

Figure 21: RetrieveSubscriberData_VA-SS

Questo messaggio contiene l' identificativo dell'utente di cui il VASP vuole conoscere eventuali default, e l'indicazione del periodo interessato.

12.4.5.2 Subscriber – VA

RetrieveSubscriberData_SS-SU è inviato da un Subscriber per richiedere al suo VASP la lista dei default da lui stesso commessi in un certo periodo temporale.

Figure 22 – RetrieveSubscriberData_SS-SU

Questo messaggio, come il precedente, contiene l' identificativo dell'utente che vuole conoscere eventuali default e l'indicazione del periodo interessato. Il Subscriber deve passare attraverso il suo VASP per poter comunicare con i Servizi Condivisi.

12.4.5.3 SS – VASP

RetrieveSubscriberData_SS-VA è inviato dai Servizi Condivisi in risposta ad un messaggio RetrieveSubscriberData_VA-SS.

</sequence>

</extension>

</complexContent>

</complexType>

</choice>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 23: RetrieveSubscriberData_SS-VA

Questo messaggio contiene l' identificativo dell'utente di cui il VASP vuole conoscere eventuali default, e per ogni default la data e l'ora in cui la sincronizzazione è fallita, a quanto ammonta il default dell'utente, l'identificativo del VASP che ha riportato il default, e la lista degli identificativi delle transizioni affetti dalla sincronizzazione non riuscita. Il record contenuto nel messaggio sarà diverso a seconda della storia passata del Subscriber. Un utente senza alcuna insolvenza sarà identivicato con un record vuoto, un'utente che ha avuto insolvenze in passato, sarà identificato dalla lista di tutti i default avvenuti in passato, infine un utente che si trova attualmente in uno stato insolvente sarà identificato da un record che non contiene alcuna data di fine del default stesso.

12.4.5.4 VASP – Subscriber

RetrieveSubscriberData_VA-SU è inviato dal VASP di un utente in default all'utente in default dopo una sincronizzazione fallita.

Figure 24 – RetrieveSubscriberData_VA-SU

Questo messaggio contiene l'identificativo dell'utente interessato, la data e l'ora in cui la sincronizzazione è fallita, a quanto ammonta il default dell'utente, l'identificativo del VASP che ha riportato il default, e la lista degli identificativi delle transizioni affetti dalla sincronizzazione non riuscita.

12.4.6 Ridistribuzione default

I seguenti messaggi vengono impiegati qualora sia necessario ridistribuire tra i creditori di un utente in default un importo in moneta virtuale prelevato dal circuito reale del subscriber, sebbene questo non sia sufficiente a saldare il debito interamente.

12.4.6.1 VASP – Subscriber

DefaultRedistribution _VA-BU è inviato dal VASP di un acquirente all'acquirente per comunicare una sincronizzazione fallita.

</sequence>

</extension>

</complexContent>

</complexType>

Figure 25: DefaultRedistribution _VA-BU

Questo messaggio contiene l'identificativo di questo rapporto, informazioni sul conto reale da cui non è stato possibile estrarre l'ammontare sufficiente, l'ammontare che risulta scoperto e la data in cui la sincronizzazione è avvenuta senza successo.

12.4.6.2 VASP – SS

DefaultRedistribution _VA-SS è inviato dal VASP di un utente scoperto in default e i Servizi Condivisi.

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 26: DefaultRedistribution_VA-SS

Questo messaggio contiene l'identificativo di questa comunicazione, l'informazione sull'utente in default, l'identificativo dei VASP interessati alla ridistribuzione, l'ammontare che deve essere scalato da ogni VASP e il numero d'ordine di pagamento che è rimasta scoperto.

12.4.6.3 SS – VASP (SE)

DefaultRedistribution_SS-VA è inviato dai Servizi Condivisi al VASP di quegli utenti da cui un certo ammontare dovrà essere scalato a causa di una sincronizzazione fallita.

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 27 – DefaultRedistribution _VA-SS

Questo messaggio contiene l'identificativo di questa comunicazione, l'informazione sull'utente in default, l'identificativo degli User interessati alla ridistribuzione (della perdita), l'ammontare che deve essere scalato da ogni VASP e il numero d'ordine di pagamento che è rimasto scoperto.

12.4.6.4 VASP (SE) – Subscriber (SE)

DefaultRedistribution_VA-SE è inviato dal VASP degli utenti che hanno ricevuto pagamenti dall'utente in default a questi ultimi.

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 28 – DefaultRedistribution _VA-SE

Questo messaggio contiene l'identificativo di questa comunicazione, l'informazione sull'utente in default, l'identificativo dell'account interessati alla ridistribuzione (della perdita), l'ammontare che deve essere scalato da ogni Subscriber e il numero d'ordine di pagamento che è rimasta scoperto.

12.4.7 Creazione account VASP

Nel momento in cui un nuovo VASP decide di entrare nel mondo iPay, sarà necessario registrarsi presso i Servizi Condivisi, i seguenti messaggi vengono scambiati tra i vari attori:

12.4.7.1 VASP - SS

CreateVASPAccount_VA-SS viene inviato da un VASP ai Servizi Condivisi per la registrazione del proprio account.

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 29 – CreateVASPAccount_VA-SS

Questo messaggio contiene informazioni personali del VASP richiedente.

12.4.7.2 SS - VASP

CreateVASPAccount_SS-VA è inviato dai Servizi Condivisi ad un VASP in risposta ad un messaggio CreateVASPAccount_VA-SS.

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 30 – CreateVASPAccount_SS-VA

Questo messaggio contiene l'identificativo per il richiedente, generato dai Servizi Condivisi in caso di successo. Altrimenti un messaggio che informa sul possibile problema che ha impedito di completare la registrazione.

12.4.8 Registrazione URL dei Servizi

I seguenti messaggi vengono impiegati dopo la registrazione di un VASP. Il VASP deve fornire ai Servizi Condivisi la lista delle URL dei servizi che espone. In questo modo ciascun VASP potrà consultare i Servizi Condivisi quando dovrà utilizzare un servizio presso un altro VASP.

12.4.8.1 VASP - SS

VASPServiceURLRegister_VA-SS è inviato da un VASP ai Servizi Condivisi per registrare le URL relativi ai vari servizi che il VASP espone

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

</restriction>

</simpleType>

Figure 31 – VASPServiceURLRegister_VA-SS

Questo messaggio contiene un identificativo del VASP e le varie coppie nome servizio – URL che il VASP vuole registrare presso i Servizi Condivisi.

12.4.8.2 SS – VASP

VASPServiceURLRegister_SS-VA è inviato dai Servizi Condivisi ad un VASP in risposta ad una richiesta di registrazione delle URL dei servizi.

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 32 – VASPServiceURLRegister_SS-VA

Questo messaggio contiene l'esito della registrazione dei servizi del VASP. In caso di fallimento viene fornito un messaggio che informa sul possibile problema che ha impedito di completare la registrazione.

12.4.9 Richiesta URL per il servizio di un VASP

I seguenti messaggi vengono impiegati qualora un VASP abbia bisogno dell'URL di un altro VASP con cui desidera comunicare. Il VASP dovrà sempre fare riferimento ai servizi condivisi per ricercare queste URL.

12.4.9.1 VASP - SS

VASPServiceURL_VA-SS è inviato da un VASP ai Servizi Condivisi per ricevere la URL di uno specifico servizio su uno specifico VASP.

</sequence>

</extension>

</complexContent>

</complexType>

Figure 33 – VASPServiceURL_VA-SS

Il messaggio contiene l'identificativo di un VASP e il nome del servizio di cui si desidera conoscere l'URL.

12.4.9.2 SS - VASP

VASPServiceURL_SS-VA è inviato in risposta ad un VASPServiceURL_VA-SS.

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 34 – VASPServiceURL_SS-VA

Questo messaggio può contenere sia l'URL relativa a un servizio di un VASP, sia il rifiuto di tale informazione. Nel primo caso, il messaggio contiene l'identificativo del VASP e una coppia nome – URL relativa al servizio richiesto. In caso di fallimento viene fornito un messaggio che informa sul possibile problema che ha impedito di completare la transazione

12.5 I protocolli

I proponenti considerano prematura la definizione dei protocolli WSDL – peraltro facilmente derivabili dalla rappresentazioni XML dei messaggi – in quanto questi dipendono dagli specifici interventi che saranno necessari sul codice cyclos proposto come punto di partenza della reference implementation in Open Source.

12.6 Reference software

Il reference software è disponibile a http://www.dmin.it/specifiche/ ipay-core-library.zip.

12.7 Agganci a iDRM

Come si vede dagli scenari d’uso presentati il sistema di pagamento e la piattaforma iDRM interagiscono nei seguenti punti

Il venditore emette una Disposizione d’Incasso che contiene l’identificativo del contenuto (ed eventualmente della licenza) nel payload delle transazioni

Il venditore emette una licenza (temporanea o definitiva) a fronte di un pagamento e la rende disponibile all’acquirente

Il venditore non riconferma la licenza temporanea a fronte di una sincronizzazione fallita.

Alcuni partecipanti a dmin.it hanno fatto una realizzazione sperimentale dello scenario d’uno no. 1 di cui la Figura 31 riporta il diagramma dei messaggi. Si è potuto osservare una perfetta integrazione dei due ambienti software iDRM ed iPay.

Figure 35 – Diagramma dei flussi dello scenario d’uso no. 1.

13 Proposta di legge per il supporto legislativo ad iPay

Allo stato attuale non si è ancora aperta la verifica relativa all'eventualità che iPay, il sistema di gestione dei micropagamenti proposto da dmin.it per i digital media, richieda un qualche supporto legislativo ad hoc per la sua attuazione sul territorio nazionale. E' comunque previsto il coinvolgimento di esperti di estrazione bancaria che possano contestualizzare iPay in un quadro normativo di riferimento a fronte del quale intraprendere le eventuali iniziative normative e/o legislative come già nel caso di iDRM.

Nella sua versione finale il capitolo conterrà le sezioni seguenti

13.1 Introduzione

Questa proposta di legge complementa gli interventi tecnici e le regole di governance che insieme permettono la realizzazione completa della proposta dmin.it del sistema di pagamenti ed incassi a punti per digital media.

13.2 Testo della proposta

PROPOSTA DI LEGGE

d’iniziativa _________

Modifica alla Legge xyz, n. ijkl in materia di.

___________

Presentato il ________

___________

13.3 Relazione con altre proposte di interventi legislativi

TBD

14 Governance del sistema iPay

Come per iDRM, anche per iPay è necessario introdurre un Trust Model che garantisca ogni attore delle catene del valore sull'affidabilità degli altri attori e in particolare degli attori denominati VASP (Virtual Account Service Provider) che erogano i servizi di virtual account verso tutti gli attori delle catene del valore dei digital media. Allo stato attuale e in conseguenza degli approfondimenti in corso di natura legale normativa di iPay suddetto Trust Model non è ancora stato definito non essendo ancora stato chiarito, per esempio, se i servizi VASP possano essere erogati solo ed esclusivamente da istituti bancari o anche da qualsiasi organizzazione privata come sarebbe nelle intenzioni di dmin.it. Nel caso in cui le norme bancarie non escludano la possibilità che i servizi dei VASP possano essere erogati non solo da istituti bancari, allora si prevede di adottare per iPay un Trust Model del tutto simile a quello proposto per iDRM e con il quale potrebbe persino coincidere.Introduzione

Nella sua versione finale il capitolo conterrà le sezioni seguenti

14.1 Obiettivi della governance

Questo documento definisce i principi e le modalità operative della governance del sistema di registrazione e conversione punti per digital media.

14.2 Operatività della governance

15 Esempi di realizzazione della proposta dmin.it

15.1 Introduzione

dmin.it è ben conscio della complessità del sistema da proposto che ha ragioni sia tecniche per la necessità di integrare le tre tecnologie di iDRM, iNet, iPay, sia normative in quanto si richiedono alcuni, anche se non molto profondi, interventi legislativi ed operativi dal momento che i sistemi necessitano di una governance che dmin.it propone sia gestita dalle parti in causa.

Per questo motivo già da marzo 2007 dmin.it ha emesso la “Richiesta di piattaforme di Digital Rights Management (DRM) e pagamento elettronico” [3] da proporre entro il 30 aprile 2007, che già aveva l’intenzione di permettere alla comunità dmin.it di cominciare a “sperimentare” su larga scala le implicazioni di DRM e pagamento elettronico per i digital media.

Con l’accettazione di IDP-3.0 e della piattaforma Chillout dmin.it come iDRM, dmin.it ha dato un’accelerazione ai suoi piani di sperimentazione. Al momento i seguenti ambiti applicativi sono in corso di sviluppo

p2p iDRM	Realizzare il Use Case and Value Chain No. 6: “Controlled Peer-to-Peer Distribution”(*) dell'Approved Document No 4 – Technical: Specification: Use Cases and Value Chains, v. 2.1 – ch. 7 [8]
VHS 2.0	Realizzare un sistema di PVR in rete con contenuti governati iDRM dall'ingestion al consumo utilizzando il codice Chillout.
idDRM	Realizzare un sistema che permetta la gestione del ciclo di vita di documenti Open Office editati in modo collaborativo da un insieme di utenti utilizzando il codice Chillout.
iIPTV	Realizzare un dispositivo di consumo mobile Chillout utilizzando un Nokia 800 (Linux Versione Maemo) utilizzando il codice Chillout
ipDRM
Porting di Chillout su STB	Realizzare una SAV con PC Linux in C++ gcc4 compliant
Sistema di suggerimenti	Realizzare un sistema di suggerimenti per digital media

15.2 P2P iDRM

P2P-iDRM è un sistema completamente decentralizzato e distribuito sui nodi di una rete peer-to-peer (P2P) strutturata. La soluzione realizzata ha lo scopo di indicizzare attraverso una Distributed Hash Table (DHT) metadati MPEG-21 riguardanti i rights per consentire ai fruitori una modalità di ricerca basata sulle licenze collegate a determinati contenuti governati.

Come mostrato in Figure 36 – Schema di massima dei dispositivi e relative connessioni del sistema P2PiDRM., gli attori principali del framework Chillout di interesse per il sistema sono:

SAV – Stationary Audio Visual Device
CPD – Content Provider Device
CCD – Content Creation Device.

Questi dispositivi si interfacciano gli uni gli altri come nodi in una rete P2P, e attraverso di essa comunicano tra di loro e reperiscono risorse e contenuti.

Per fare ciò, ogni dispositivo ingloba una componente P2P, come in Figure 37 – Schema a blocchi delle componenti software utilizzate in P2P-iDRM.

Questa componente è suddivisa in (a) un layer DHT, (b) un livello di trasporto e (c) un livello applicativo.

Figure 36 – Schema di massima dei dispositivi e relative connessioni del sistema P2PiDRM.

Quello che si propone P2P-iDRM è l'indicizzazione di metadati MPEG-21 su DHT, in modo da garantire ricerca per rights e query complesse (per esempio, ricercare tutti i documenti DCF che hanno come issuer "misterX" e come grant "play").

Il sistema è però completamente agnostico allo specifico “livello” di iDRM utilizzato, nel senso che chi pubblica i suoi contenuti può pubblicarli, ad esempio, con una licenza Creative Commons oppure con tecniche di protezione.

Per fare ciò, vengono indicizzati documenti DCF associandoli a chiavi estratte dalla licenza.

Non tutti i metadati MPEG-21 vengono indicizzati. Ogni licenza, oltre ad altre informazioni, è composta da issuer, grant e principal.

Per ogni licenza associata ad un contenuto governato, oltre al titolo e all'autore, vengono indicizzate queste informazioni sotto forma di tripla. Questi dati così indicizzati sono sufficienti per reperire univocamente un contenuto governato (i.e., il DCF completo di tutti i metadati) su cui è possibile effettuare raffinamenti della ricerca in locale.

Il layer DHT si occupa del routing dei messaggi e della gestione delle chiavi. Ad ogni risorsa, su una DHT, è assegnata una chiave univoca, e tutte le funzionalità offerte da questi sistemi possono essere riassunte dalla funzione base lookup(chiave), che restituisce il valore associato a quella chiave.

All'interno del sistema P2P-iDRM vengono inserite chiavi a fronte di metadati relativi a rights estratti da tag MPEG-21 all'interno di file DCF, e tutti i dati inseriti su DHT (tutte le chiavi) hanno come valore associato il file DCF, in modo da avere più riferimenti al file (e dare così modo di effettuare query complesse su DHT). Il sistema prevede quindi l'indicizzazione di documenti DCF reperibili attraverso ricerche basate sui rights. Lo strato applicativo si occupa di estrarre le informazioni da indicizzare dal DCF e comunica con il layer DHT per l'indicizzazione delle chiavi associate. Il livello di trasporto si occupa del download dei file così reperiti.

Figure 37 – Schema a blocchi delle componenti software utilizzate in P2P-iDRM

Ad oggi la soluzione utilizza come strato DHT il software FreePastry, ma le dipendenze sono ad un livello sufficiente a garantire l'interoperabilita' con altri soluzioni DHT come Chord, Kademlia, etc.

Anche la componente di trasporto potrà nel futuro essere migliorata per gestire il download da più peers contemporaneamente (multisource download) usando per esempio lo strato di trasporto di BitTorrent, o ad esempio utilizzare GridFTP (Globus) per rendere più efficiente il trasporto di files più grandi di 2Gb.

Lo sforzo iniziale sostenuto per implementare una rete Peer-to-Peer strutturata anzichè flooding e/o centralizzata, viene ricompensato dal fatto che questo tipo di rete “scala” in modo naturale e viene garantito un massimo numero di salti pari a log₂N per raggiungere un qualsiasi peer che possiede un determinato content (dove N è il numero complessivo di peers dell'overlay).

Questo significa avere tempi di risposta molto contenuti per tutti gli utenti connessi e una grande dinamicita' nella configurazione della topologia.

L’intenzione del gruppo di sviluppo è quella di coinvolgere le comunità scientifiche/accademiche nell'utilizzo di Chillout con questa estensione P2P al fine di provare e sperimentare le applicazioni di ricerca in un contesto di contenuti governati e di soluzioni all'avanguardia con un forte valore di innovazione tecnologica.

15.3 VHS 2.0

VHS 2.0 è un ambiente basato su DMP IDP v. 3.0 per la gestione di contenuti multimediali con criteri di riservatezza e privacy.

Uno scenario d’ uso è quello di un mediacenter domestico, dove il semplice cittadino può tutelare una serie di suoi contenuti audio o video trasformandoli in un formato protetto con i criteri di protezione richiesti dall’ utente:

protezione basata su password
protezione basta su certificato X509
play locale
play remoto domestico
play remoto via internet

Tramite VHS2.0 il privato cittadino può proteggere i propri contenuti e controllarne l’ utilizzo da parte di altri soggetti, permettendo quindi di:

Mantenere in sicurezza registrazioni della propria sfera “privata”

Realizzare una copia effettivamente privata di contenuti accessibili on-line o on-the-air per ricreare in ambito digitale il diritto alla copia privata che è sempre stato tutelato in ambito analogico

VHS2.0 si articola su due macrocomponenti:

VHS2.0 Player
VHS2.0 Creator

Figure 38 – Schema a blocchi delle componenti software utilizzate in VHS 2.0

Il primo componente ad avere una implementazione operativa è stato il VHS2.0 Player, un SAV alternativo al SAV nativo di chillout:

ottimizzato per le necessità dell’ utente privato singolo
che opera con le protezioni su control point 1 di IDP v. 3.0
con chiara visibilità preventiva dei metadati e delle condizioni di licenza e di visione
non vincolato all’ utilizzo di uno specifico player
in grado di effettuare lo streaming del flusso decodificato su https verso il player
che permette la visualizzazione remota su sistemi hardware differenti
che mantiene la sicurezza del player sulla base di certificatti SSL a bordo si questi

Sul mediacenter è installato il VHS2.0 Player, un webservice accessibile attraverso il protocollo https.

I diversi player sia software (Microsoft Explorer, Mozilla Firefox, VLC, QuickTime, Real) sia hardware (Sony PSP, Apple Iphone/ Ipod Touch, Nokia N800, Sony PS3, Microsoft X-box) possono essere abilitati all’ accesso di VHS2.0 sulla base diversi criteri: indirizzo IP, indirizzo MAC, certificato X509, semplice password.

Il player accedendo con il suo browser web a VHS2.0 Player sul mediacenter, può sfogliare i contenuti protetti .DCF e quindi avviarne la visione locale una volta offerte le opportune credenziali.

16 Bibliografia

[1]	Dmin.it	Proposte di azione per dare all'Italia una posizione leader nei digital media, 2006/09/13 http://www.dmin.it/proposta/index.htm
[2]	Dmin.it	Specifiche funzionali, azioni normative e governance per la realizzazione della proposta dmin.it, 2007/03/15 http://www.dmin.it/proposta/proposta-operativa.htm
[3]	Dmin.it	Richiesta di piattaforme di Digital Rights Management (DRM) e pagamento elettronico http://www.dmin.it/proposta/richiesta-piattaforma-DRM-pagamenti.doc
[4]	Dmin.it	Richiesta di tecnologie e soluzioni per la realizzazione delle proposte dmin.it http://www.dmin.it/proposta/richiesta-tecnologie-soluzioni.doc
[5]	Dmin.it	Richiesta di commenti sugli interventi normativi necessari per la realizzazione delle proposte dmin.it http://www.dmin.it/proposta/richiesta-commenti-normativi.doc
[6]	Dmin.it	Richiesta di commenti sui sistemi di governance necessari per la realizzazione delle proposte dmin.it http://www.dmin.it/proposta/richiesta-commenti-governance.doc
[7]	DMP	DMP Technical Specification: Interoperable DRM Platform, Version 3.0 http://www.dmpf.org/open/dmp1003.zip
[8]	DMP	DMP Technical Specification: Use Cases and Value Chains, Version 3.0 http://www.dmpf.org/open/dmp1004.zip
[9]	DMP	Chillout – The IDP Reference Software http://chillout.dmpf.org/
[10]	Dmin.it	Wiki di dmin.action http://wiki.dmin.it/
[11]	ISO/IEC	ISO/IEC 23000-5, Media Streaming Aplication Format

17 Glossario

Termine	Definizione
4G	Quarta generazione di telefonia mobile (la 1° è il TACS, la 2° il GSM, la 3° l’UMTS)
ACS	Alternative Compensation Systems
Address space	Insieme dei possibili indirizzi con cui possono essere identificati i dispositivi interconnessi ad una rete. L’ address space può essere privato, nel caso in cui l’indirizzamento valga all’interno di una singola organizzazione, oppure pubblico, quando gli indirizzi devono essere universalmente univoci Per la rete Internet un’autorità unica (IANA) amministra v la governance degli indirizzi.
Aperto	Aggettivo tipicamente associato ad una soluzione tecnica per indicare che questa è pubblica, completamente specificata, praticabile da una parte diversa da quella che l'ha specificata, eventualmente con il pagamento di royalty dovute a proprietà intellettuale contenuta nella specifica. Esempi: Standard ISO/IEC/ITU/ETSI ecc.
B2B	Business to Business
B2C	Business to Consumer
Banda larga (Broadband)	La banda sufficiente per la trasmissione di informazione audiovisiva di livello adeguato per applicazioni di intrattenimento
Best effort	Attributo di una rete che fa uno sforzo “sincero” (come nel concetto legale di contratto “best effort”) di inoltrare tutti i pacchetti dati in transito in condizioni normali di traffico mentre quando la rete diventa sovraccarica alcuni pacchetti dati possono andare persi, essere ritardati o consegnati fuori ordine.
BEUC	Bureau Européen des Consommateurs.
Bidirezionale	Attributo di una rete in cui i dati possono scorrere nelle due direzioni
Catena del valore	Un insieme di intermediari, uniti per realizzare un modello di business, e collegati tra di loro e con gli autori e gli utenti finali. Gli intermediari svolgono successivamente funzioni a valore aggiunto a cui corrispondono transazioni
CC	Creative Commons
CDN	Content Delivery Network
Contenuto digitale	Vedi Digital media
Decoder	Vedi Set Top Box
Detentore dei diritti	Persona fisica o giuridica che possiede diritti d’autore o diritti connessi su un contenuto
DHT	Distributed Hash Table
Digital media	Forma di creazione, distribuzione e consumo di contenuti resa possibile dal fatto che i contenuti stessi sono espressi in forma di bit elaborabili da dispositivi programmabili e trasportabili da varie tipologie di protocolli sulle reti numeriche
Digital Rights Management (DRM)	Un sistema di componenti e servizi informatici che hanno l’obiettivo di distribuire e controllare contenuti ed i relativi diritti con tecniche numeriche
DTT	Digital Terrestrial Television
DVB-H	Digital Video Broadcast Handheld
Event	Il risultato di una qualsiasi azione svolta da un utente (ad esempio play, copy, enlarge ecc.)
Event Report	L’informazione generata da un dispositivo in seguito ad un Evento
Event Report Request	La richiesta che un autore o distributore inserisce nel contenuto richiedendo ad un dispositivo di inviare un Event Report
HSDPA	High-Speed Downlink Packet Access
IANA	Internet Assigned Numbers Authority
iDRM	Interoperable DRM
Interoperabile	Aggettivo tipicamente associato a Un contenuto per indicare la possibilità di fruire di quel contenuto su un dispositivo Un dispositivo per indicare la possibilità di fruire di un contenuto su quel dispositivo Una rete per indicare la capacità di trasferire dati ad un’altra rete con determinate caratteristiche
IP	Internet Protocol
IPTV	Internet Protocol Television L’erogazione di servizi televisivi, ad esempio la televisione broadcast e pay-per-view, il Video-on-demand (VOD), la TV interattiva e applicazioni associate, realizzati sopra una rete bidirezionale IP a larga banda connessa ad un set-top box a ciò dedicato.
NGN	Next Generation Network
Open Source Software	Software con codice sorgente aperto
P2P	Peer-to-Peer
Pay-per-view (PPV)	Servizio a pagamento che permette ad un utente di fruire di contenuti singoli a pagamento
Peering	Operazione con cui diversi operatori di accesso o, in genere, di connettività Internet mettono in comunicazione le proprie reti. Rappresenta la modalità attraverso cui i diversi operatori si riconoscono vicendevolmente uguale status (letteralmente: “rapportarsi tra parigrado”)
Piattaforma	Nella distribuzione di contenuti: insieme di dispositivi hardware e software che permettono l’invio, la ricezione o l’uso di contenuti
Protezione dei contenuti	vedi Technical Protection Measure (TPM)
Quality of Service (QoS)	Caratteristica di una rete di trasmettere dati con caratteristiche concordate
SET	Secure Electronic Transactions
Simulcast	La trasmissione dello stesso contenuto con caratteristiche (ad esempio risoluzione) diverse o su due diversi sistemi trasmissivi
Sistema di compensazione alternativo	Modo di compensazione dei detentori dei diritti diverso dalla compensazione economica diretta
STB	Set Top Box
TPM	Technical Protection Measure Una tecnologia (cifratura, watermarking ecc.) che ha lo scopo di prevenire o scoraggiare l’uso di contenuti se si è sprovvisti di autorizzazione
TPM	Trusted Platform module
UMTS	Universal Mobile Telecommunication System
Venture Capital	Una società finanziaria che fa investimenti specialmente diretti a società con crescita veloce e che però richiedono un livello alto di capitale
Walled garden	Un insieme di contenuti e servizi offerti in modo esclusivo ad un insieme chiuso di utenti
Work for hire	Lavoro intellettuale che dovrebbe dar origine a diritti a chi lo svolge ma che invece è ridotto a puro lavoro stipendiato

[1] Lo scenario d’uso si riferisce al caso in cui la consultazione dei servizi condivisi dia esito positivo. Viceversa sarebbe necessario notificare Dormi bene dell'esito negativo della consultazione e lasciare a ques'ultimo la decisione su come procedere.

[2] In questa parte del processo non viene preso in considerazione un esito negativo dell'interrogazione dei Servizi Condivisi

[3] Nota: ad oggi la legge italiana non consente l’accesso a Muzio, ma la realizzabilità dello scenario d’uso non dipende dall’accesso diretto di Mario alla distribuzione DTT.

[4] In prima approssimazione AC svolge le funzioni del Comitato di Controllo della proposta di intervento legislativo