Digital Media in Italia

Un'iniziativa per interrogarci sul ruolo dell'Italia
e per programmare il nostro futuro

La proposta di Digital Media in Italia

per dare all’Italia un ruolo primario nello sfruttamento dei digital media

Versione 2.0

Il presente documento è stato redatto da Digital Media in Italia (dmin.it), un gruppo interdisciplinare, aperto e senza scopo di lucro che ha l’obiettivo di definire e proporre aree di intervento che consentano all’Italia di acquisire un ruolo primario nello sfruttamento del fenomeno globale “digital media”.

I partecipanti a dmin.it mettono a disposizione le proprie competenze, visioni ed esperienze a titolo personale, pertanto quanto riportato nel documento non impegna in alcun modo le aziende e le organizzazioni all’interno delle quali i singoli partecipanti operano.

L’uso delle tecnologie descritte in questa specifica tecnica potrebbe infrangere brevetti, copyright o in generale proprietà intellettuale di terze parti. In nessuna circostanza dmin.it può essere reso responsabile di identificare tali diritti.

dmin.it non può essere reso responsabile di qualunque fatto originato da o collegato con l’uso delle specifiche tecniche contenuto in questo documento.

Digital Media in Italia: http://www.dmin.it

Rilasciato con licenza Creative Commons Attribuzione - Non commerciale 2.5

20 dicembre 2007 - 27 maggio 2009


Executive summary

Digital Media in Italia (dmin.it) è un gruppo interdisciplinare, aperto, senza scopo di lucro, costituitosi a novembre 2005, che si propone di definire aree di interventi che consentano all’Italia di acquisire un ruolo primario nello sfruttamento del fenomeno globale “digital media”. Per questi dmin.it intende qualsiasi contenuto rappresentato in forma numerica che può quindi essere trasportato su reti numeriche ed elaborato da dispositivi numerici specie se programmabili.

Operando in piena apertura il gruppo ha definito obiettivi, metodo di lavoro e processo con il quale operare per raggiungere gli obiettivi prefissi. Tutti i documenti sono stati pubblicati sul sito web del gruppo con richiesta di commenti ed è stata data a tutti facoltà di proporre contributi in risposta alle richieste di tecnologie, soluzioni e commenti.

dmin.it parte dalla considerazione che molti vantaggi dei 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.

Per una serie di ragioni i tentativi fatti negli ultimi 10 anni da molti operatori per innovare le catene del valore dei media sono falliti e ci ritroviamo oggi con catene del valore digitali che assomigliano spesso a vecchie catene analogiche in cui sono state montate tecniche di protezione basate su tecnologie proprietarie. Anche nuove promettenti metodologie aperte di distribuzione quali le licenze Creative Commons stentano a mostrare il loro potenziale innovativo.

Il risultato è un mercato “sommerso” di ordini di grandezza maggiore di quello “apparente” ed 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 dmin.it contenuta in questo documento estende la proposta preliminare fatta a settembre 2006 [1] fornendo precisi strumenti tecnologici, normativi e di governance per realizzare l’obiettivo di dmin.it già allora riformulato con “massimizzare il flusso di digital media”. Precisamente la proposta prevede che l’obiettivo possa essere raggiunto specificando e creando le condizioni con cui sia possibile l’uso di tre elementi critici, e cioè:

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

dmin.it non propone però una standardizzazione impositiva delle tecnologie qui specificate ad esclusione di altre. Questo tipo di azione infatti, pur con i benefici che ha storicamente offerto, non risponde alle tendenze del momento. dmin.it propone invece che, accanto agli strumenti che gli operatori liberamente decidono di adottare per le loro necessità, siano affiancati gli strumenti interoperabili proposti da dim.it.

Per il formato dmin.it osserva che l'uso delle tecniche di Digital Rights Management (DRM) sia di gestione che di protezione, per la distribuzione dei digital media è ormai pervasivo nel mercato, esistono trattati internazionali, obblighi comunitari e leggi nazionali che regolamentano diritti e doveri di chi usa DRM e che è quindi irrealistico pensare di abolire tale contesto legislativo.

D’altra parte l’uso di tecnologie DRM proprietarie porta con sé significativi impedimenti a

  1.  Fornitori di contenuti (autori, compositori, interpreti e produttori) che, per poter distribuire le loro opere hanno bisogno dell’esistenza di milioni di apparati di fruizione che è estremamente onerosa da ottenere;
  2.  Consumatori che sopportano sostanziali oneri per dotarsi di più apparati di fruizione ed incontrano notevoli difficoltà a spostare contenuti tra apparati diversi;
  3.  Fornitori di servizio che possono incontrare notevoli limitazioni ad agganciarsi ad altre catene del valore
  4.  Aziende italiane che hanno spesso difficoltà ad operare in un mercato nazionale frammentato e dominato da colossi multinazionali.

Pertanto dmin.it propone che la legge determini che gli operatori che rilasciano contenuti con un DRM proprietario debbano rilasciare gli stessi contenuti anche utilizzando il DRM interoperabile (iDRM) specificato in questo documento, a condizioni che non siano discriminatorie a confronto di quelle usate per i contenuti rilasciati con DRM proprietario.

Per l’accesso dmin.it propone che la legge determini che un operatore di rete a larga banda possa offrire accesso alla sua rete con caratteristiche tecniche di sua scelta, ma che 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.

Per il pagamento/incasso dmin.it propone 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 di questo documento. Le transazioni sono effettuate tra “account” che si appoggiano su strumenti di pagamento ad incasso garantito, quali conto corrente, carta di credito, carta prepagata, domiciliazione bancaria, borsellino elettronico, ma la sincronizzazione di un “account” con il suo circuito di appoggio non è effettuata ad ogni transazione ma su base periodica oppure a richiesta.

Questo documento contiene

  1.  Alcuni esempi di scenari d’uso assolutamente innovativi resi possibili dalla proposta dmin.it;
  2.  L’insieme dei requisiti tecnici e giuridici (ove necessario) utilizzati per la definizione delle tecnologie iDRM, iNet e iPay;
  3.  Le specifiche tecniche, le proposte di intervento normativo e le regole di governance necessarie per la gestione dei sistemi iDRM, iNet ed iPay;
  4.  Alcuni esempi dimostrativi e sperimentali che alcuni partecipanti a dmin.it stanno realizzando per verificare l’adeguatezza delle tecnologie adottate e la loro capacità effettiva di rispondere ai requisiti.

Indice


Executive summary                                                               

Indice                                                                         

1. Introduzione                                                           

2. Sviluppo della proposta                                          

3. Caratteristiche e vantaggi della proposta                                         

3.1    Tecnologie di formato                                                   

3.2    Tecnologie di accesso                                                   

3.3    Tecnologie di pagamento                                               

4. Scenari d’uso                                                               

4.1    Introduzione                                                          

4.2    Leonardo compera una canzone da Mimmo           

4.3    Roberta guarda un programma TV live

4.4    Antonella ascolta la musica pagandola con la pubblicità

4.5    Luca ascolta musica in abbonamento                          

4.6    Beppe compensa Pippo con un sistema di compensazione alternativo

4.7    Nuova Cantina vende musica sul web

4.8    Marco distribuisce i suoi video su DTT  

4.9    Distribuzione di contenuti governati su P2P

4.10     Registrazione personale di video              

4.11  Gestione del ciclo di vita di documenti      

5 Requisiti                                                        

5.1    Introduzione                                             

5.2    Requisiti per iDRM                                   

5.2.1  Requisiti di sistema                                  

5.2.2  Requisiti giuridici                                     

5.2.3  Requisiti tecnici                                       

5.3    Requisiti per iNet                                      

5.3.1  Requisiti di sistema                                  

5.4    Requisiti per iPay                                      

5.4.1  Requisiti di sistema                                  

6 Specifiche di iDRM                                        

6.1    Introduzione                                              

6.2    Schema di riferimento                                

6.3    Che cosa è standardizzato in iDRM           

6.4    Software di riferimento                              

6.5    Agganci a iNet e iPay                                

7 Proposta di legge per il supporto legislativo a iDRM

7.1    Introduzione                                                     

7.2    Testo della proposta                                         

7.3    Relazione con altre proposte di interventi legislativi

8 Governance del sistema iDRM                                  

8.1    Introduzione                                                        

8.2    Obiettivi del Trust Model di iDRM                       

8.3    Processo di certificazione                                     

8.4    Processo run-time legato al consumo di contenuti  

8.5    Schema legale/normativo/contrattuale                    

8.6    Gli economics di sistema                                       

9 Specifiche di iNet                                                       

9.1    Introduzione                                                          

9.2    Schema di riferimento                                            

9.3    Accesso d’utente                                                   

9.4    Interfacce e protocolli tra operatori                         

9.5    Software di riferimento                                           

9.6    Agganci a iDRM e iPay                                          

10   Proposta di legge per il supporto legislativo ad iNet     

10.1  Introduzione                                                          

10.2  Testo della proposta                                              

10.3  Relazioni con altre proposte di interventi legislativi   

11   Governance del sistema iNet                                       

11.1  Introduzione                                                          

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

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

12   Specifiche di iPay

12.1  Introduzione                                                          

12.2  Schema di riferimento                                            

12.3  Gli elementi da standardizzare                                

12.3.1 Gli attori                                                            

12.3.2 Le comunicazioni                                               

12.4  Rappresentazione XML delle strutture dati           

12.4.1 Creazione account (createAccount)                   

12.4.1.1   Subscriber – VASP                                      

12.4.1.2   VASP – SS                                                  

12.4.1.3   SS – VASP                                                  

12.4.1.4   VASP – Subscriber                                      

12.4.2 Disposizione d'incasso                                       

12.4.2.1   Subscriber (SE)– VASP                               

12.4.2.2   VASP – VASP                                            

12.4.2.3   VASP – Subscriber (BU)                             

12.4.3 Disposizione di pagamento                                

12.4.3.1   Subscriber (BU) – VASP                             

12.4.3.2   VASP – VASP                                            

12.4.3.3   VASP – Subscriber (SE)                                         

12.4.4 Caricamento dati utente insolvente                                

12.4.4.1   VASP – SS                                                   

12.4.5 Consultazione dati utente                                     

12.4.5.1   VASP – SS                                                   

12.4.5.2   Subscriber – VA                                            

12.4.5.3   SS – VASP                                                  

12.4.5.4   VASP – Subscriber                                      

12.4.6 Ridistribuzione default                                        

12.4.6.1   VASP – Subscriber                                      

12.4.6.2   VASP – SS                                                  

12.4.6.3   SS – VASP (SE)                                          

12.4.6.4   VASP (SE) – Subscriber (SE)                      

12.4.7 Creazione account VASP                                  

12.4.7.1   VASP - SS                                                   

12.4.7.2   SS - VASP                                                  

12.4.8 Registrazione URL dei Servizi                            

12.4.8.1   VASP - SS                                                   

12.4.8.2   SS – VASP                                                   

12.4.9 Richiesta URL per il servizio di un VASP            

12.4.9.1   VASP - SS                                                

12.4.9.2   SS - VASP                                                

12.5  I protocolli                                                        

12.6  Reference software                                           

12.7  Agganci a iDRM                                               

13   Proposta di legge per il supporto legislativo ad iPay

13.1  Introduzione                                                      

13.2  Testo della proposta                                          

13.3  Relazione con altre proposte di interventi legislativi

14   Governance del sistema iPay                                    

14.1  Obiettivi della governance                                    

14.2  Operatività della governance                                

15   Esempi di realizzazione della proposta dmin.it            

15.  Introduzione                                                         

15.1  P2P iDRM                                                           

15.2  VHS 2.0                                                              

16   Bibliografia                                                               

17   Glossario                                                                  


1.  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è:

  1.  Formato per la distribuzione controllata dei digital media (iDRM)
  2.  Accesso aperto alle reti a larga banda (iNet)
  3.  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


2.  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:

  1.  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.
  2.  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
  3.  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è

  1.  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;
  2.  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;
  3.  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;
  4.  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

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

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

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.1 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;

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

  1.  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.
  2.  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.
  3.  Realizzazioni software delle specifiche che si basano sul Trusted Platform Module (TPM) definito dal Trusted Computing Group ed attualmente istallato su tutti i portatili.
  4.  Realizzazioni miste hardware/firmware
  5.  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.2 Tecnologie di accesso

La proposta dmin.it per l’accesso prevede che

  1.  Un operatore di rete a larga banda possa offrire accesso bundled e/o unbundled alla sua rete con caratteristiche tecniche di sua scelta;
  2.  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;
  3.  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.3 Tecnologie di pagamento

La proposta dmin.it per pagamento/incasso prevede che

  1.  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;
  2.  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.
  3.  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


4.  Scenari d’uso

4.1 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

  1.  La tecnologia sia effettivamente in grado di supportare tutti scenari d’uso giudicati interessanti

  2.  La governance sia in grado di supportare aspetti degli scenari d’uso

  3.  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.2 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:

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

4.3 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.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.5 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.6 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.7 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.8 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.9 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

  1.  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)
  2.  Condividere il file con gli altri membri della comunità DIMusic
  3.  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.


5.  Requisiti

5.1 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.2 Requisiti per iDRM

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

  1.  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à
  2.  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
  3.  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.
  4.  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
  5.  Il sistema iDRM offre un toolkit di tecnologie standard facilmente combinabili per raggiungere determinati obiettivi
  6.  Il sistema iDRM consente di estendere il toolkit con nuove tecnologie o di sostituire tecnologie obsolete con altre più moderne e performanti
  7.  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
  8.  Il sistema iDRM consente ad un Utente di pubblicare la lista di funzionalità abilitate dalla sua scelta/combinazione di tecnologie dal toolkit
  9.  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.2 Requisiti giuridici

  1.  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.
  2.  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.
  3.  La soluzione dmin.it deve essere applicabile alla giurisdizione italiana con i vincoli posti dall’UE.
  4.  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.
  5.  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)
  6.  La soluzione dmin.it deve poter essere utilizzata per proteggere i dati personali e d’uso.
  7.  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à.
  8.  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.
  9.  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
  10. 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;
  11. 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;
  12. La soluzione dmin.it deve ridurre al minimo i rischi attinenti alla sicurezza dei sistemi informativi di operatori ed utenti;
  13. 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.
  14. 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.3 Requisiti tecnici

  1. 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
  2. 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.).
  3. La soluzione dmin.it deve permettere l’utilizzazione delle sole funzionalità richieste da una data catena del valore
  4. La soluzione dmin.it deve permettere l’aggiunta di nuove funzionalità nel caso in cui queste siano richieste da nuove catene del valore
  5. 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.)
  6. La soluzione dmin.it deve permettere l’identificazione delle varie entità (contenuti, dispositivi, utenti ecc.) che sono utilizzate in una catena del valore
  7. 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
  8. 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
  9. 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.3 Requisiti per iNet

5.3.1 Requisiti di sistema

Deve essere possibile per un utente

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

5.4 Requisiti per iPay

5.4.1 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:

  1.  Utente: ogni attore che opera nel sistema di pagamento
  2.  Subscriber: un attore che ha un Account su un VASP
  3.  VASP: Virtual Account Service Provider
  4.  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.

  1.  Il sistema di pagamenti proposto è parallelo e non sostitutivo di altri sistemi di pagamento
  2.  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
  3.  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)
  4.  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)
  5.  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)
  6.  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
  7.  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
  8.  Il sistema di pagamenti proposto applica l’IVA ad ogni transazione (perché i tassi per le diverse transazioni possono non essere omogenei)
  9.  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


6. Specifiche di iDRM

6.1 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.2 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.3 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:

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

  1.  Core: implementa i formati standard IDP-3.2
  2.  Auxiliary: funzioni di utilità
  3.  Media Framework: co-decodifica audio e video e mux/demux
  4.  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.5 Agganci a iNet e iPay

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

  1.  Il venditore emette una Disposizione d’Incasso che contiene l’identificativo del contenuto (ed eventualmente della licenza) nel payload delle transazioni
  2.  Il venditore emette una licenza (temporanea o definitiva) a fronte di un pagamento e la rende disponibile all’acquirente
  3.  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.


7. Proposta di legge per il supporto legislativo a iDRM

7.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 per il sistema iDRM.

7.2 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:

7.3 Relazione con altre proposte di interventi legislativi

TBD


8.  Governance del sistema iDRM

8.1 Introduzione

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

8.2 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 tecni­camente 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 imple­mentativi diversi, adatti ai diversi segmenti di mercato, e che sono tenuti a rispettare rigorosamente un princi­pio 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 li­vello di sicurezza inferiore non può accedere a contenuti per i quali sia richiesto possedere caratte­ristiche 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-imple­mentativi 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 ren­dere percorribile un cammino di ingresso nel business anche da parte del piccolo produttore/forni­tore 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:

  1.  Il processo di accettazione ed integrazione nel sistema iDRM di qualunque dispositivo gestisca i contenuti o le licenze
  2.  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
  3.  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:

8.3 Processo di certificazione

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

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

  1. dmin.it definisce le specifiche di interfacciamento di iDRM con il TPM
  2.  dmin.it estende la sua reference implementation aggiungendo l'interfacciamento con il TPM
  3.  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"
  4.  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
  5.  Il TPM riconosce la CA del punto 4. ed esegue il binario come software certificato per il dispositivo
  6.  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
  7.  Chi ha fatto le modifiche si assume le responsabilità di cui alla sezione 8.5
  8.  Chi sviluppa un software proprietario di iDRM che non intende distribuire in OSS deve sottometterlo al LA che ne certifica la conformità
  9.  Il software del punto 8. è accessibile dalla CA ed eseguito da un hardware con TPM.

8.4 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:

8.5 Schema legale/normativo/contrattuale

Lo schema è basato sui seguenti punti:

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


9.  Specifiche di iNet

9.1 Introduzione

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

9.2 Schema di riferimento

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

9.3 Accesso d’utente

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

  1.  Assegnazione statica o dinamica di almeno un indirizzo IP “pubblico”;

  2.  Nessuna limitazione sul numero di port numbers (TCP, UDP) utilizzabili;

  3.  Nessun filtraggio selettivo del traffico su base:

    1.  “Port number”;

    2.  Indirizzi destinazione o sorgente;

    3.  Servizio applicativo utilizzato;

Inoltre sono servizi indispensabili:

  1.  Risoluzione dei nomi (DNS);

  2.  Mail forwarding (SMTP).

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

Requisiti opzionali sono funzionalità di:

  1.  Accesso “premium” per specifiche direttrici di traffico;

  2.  Multicast e/o streaming (con controllo della banda utilizzata e prioritizzazione del traffico)

9.4 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:

  1.  Più classi di servizio in numero prefissato (in dipendenza dalla tecnologia adottata);
  2.  Mantenimento dei livelli di servizio previsti da ogni classe lungo tutta la catena, dal nodo sorgente al nodo destinazione;
  3.  Equivalenza delle classi di servizio di ogni operatore alla frontiera di peering;
  4.  Uniformità di QoS per il traffico di una classe di servizio, indipendentemente dalle caratteristiche del traffico (indirizzi sorgente/destinazione, port number, applicazione);
  5.  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

  1.  Peering “privato”, cioè attraverso un collegamento diretto;

  2.  Peering “pubblico”, cioè realizzato presso un Network Access Point (NAP).

9.5 Software di riferimento

Questo è probabilmente non richiesto.

9.6 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:

  1.  Il Subscriber
  2.  Il VASP
  3.  I Servizi Condivisi
  4.  I circuiti tradizionali di pagamento

12.3.2  Le comunicazioni

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

  1.  Il protocollo
  2.  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.

<element name="CreateSubscriberAccount_SU-VA" type="pay:CreateSubscriberAccount_SU-VAType"/>

<complexType name="CreateSubscriberAccount_SU-VAType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="UserInfo" type="pay:UserInfoType"/>

                        <element name="SupportingAccount" type="pay:PhysicalAccountType"/>

                        <element name="AccountOptions" type="pay:OtherType" minOccurs="0"/>

                        <element ref="dsig:Signature"/>

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

<element name="CreateSubscriberAccount_VA-SS" type="pay:CreateSubscriberAccount_VA-SSType"/>

<complexType name="CreateSubscriberAccount_VA-SSType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="UserInfo" type="pay:UserInfoType"/>

                        <element ref="dsig:Signature"/>

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

<element name="CreateSubscriberAccount_SS-VA" type="pay:CreateSubscriberAccount_SS-VAType"/>

<complexType name="CreateSubscriberAccount_SS-VAType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <choice>

                              <element ref="pay:Subscriber"/>     

                              <element name="Fault" type="pay:FaultType"/>

                        </choice>

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<element name="User" type="pay:UserType"/>

<complexType name="UserType" abstract="true">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="UserId" type="anyURI"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<element name="Subscriber" type="pay:SubscriberType"/>

<complexType name="SubscriberType">

      <complexContent>

            <extension base="pay:UserType"/>

</complexContent>

<complexType name="FaultType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="FaultCode" type="pay:FaultCodeType"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<simpleType name="FaultCodeType">

<restriction base="string">

            <enumeration value="UNKNOWN_ERROR"/>

            <enumeration value="SERVICE_UNAVAILABLE"/>

            <enumeration value="INVALID_DB_STATE"/>

            <enumeration value="INSUFFICIENT_INFORMATION"/>

            <enumeration value="UNKNOWN_VASP"/>

            <enumeration value="UNKNOWN_SERVICE_NAME"/>

            <enumeration value="INVALID_SERVICE_URL"/>

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

<element name="CreateSubscriberAccount_VA-SU" type="pay:CreateSubscriberAccount_VA-SUType"/>

<complexType name="CreateSubscriberAccount_VA-SUType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <choice>

                              <element name="AccountCreated" type="pay:AccountCreatedType"/>

                              <element name="Fault" type="pay:FaultType"/>

                        </choice>

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="AccountCreatedType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element ref="pay:User"/>

                        <element name="VirtualAccountInfo" type="pay:AccountType"/>

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

<element name="CashOrder_SE-VA" type="pay:CashOrder_SE-VAType"/>

<complexType name="CashOrder_SE-VAType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="OrderNumber" type="string"/>

                        <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                        <element name="Buyer" type="pay:SubscriberType"/>

                        <element name="BuyerVASP" type="pay:VASPType"/>

                        <element name="Seller" type="pay:SubscriberType"/>

                        <element name="SellerAccount" type="pay:AccountType"/>

                        <element ref="pay:Amount"/>

                        <element name="VAT" type="pay:VATType"/>

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

      <element name="Amount" type="float"/>

      <simpleType name="VATType">

            <restriction base="float">

                  <minInclusive value="0"/>

                  <maxInclusive value="100"/>

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

<element name="CashOrder_VA-VA" type="pay:CashOrder_VA-VAType"/>

<complexType name="CashOrder_VA-VAType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="OrderNumber" type="string"/>

                        <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                        <element name="Buyer" type="pay:SubscriberType"/>

                        <element name="BuyerVASP" type="pay:VASPType"/>

                        <element name="Seller" type="pay:SubscriberType"/>

                        <element name="SellerAccount" type="pay:AccountType"/>

                        <element ref="pay:Amount"/>

                        <element name="VAT" type="pay:VATType"/>

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

Figure 15 – CashOrder_VA-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'imposta sulla transazione.

12.4.2.3  VASP – Subscriber (BU)

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

<element name="CashOrder_VA-BU" type="pay:CashOrder_VA-BUType"/>

<complexType name="CashOrder_VA-BUType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="OrderNumber" type="string"/>

                        <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                        <element name="Seller" type="pay:SubscriberType"/>

                        <element name="SellerVASP" type="pay:VASPType"/>

                        <element name="SellerAccount" type="pay:AccountType"/>

                        <element name="Amount" type="long"/>

                        <element name="VAT" type="pay:VATType"/>

                        <element ref="dsig:Signature"/>

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

<element name="PaymentOrder_BU-VA" type="pay:PaymentOrder_BU-VAType"/>

<complexType name="PaymentOrder_BU-VAType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <choice>

                              <element name="Confirmation" type="pay:PaymentConfirmationType"/>

                              <element name="Negation" type="pay:FaultType"/>

                              <element ref="dsig:Signature"/>

                        </choice>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="PaymentConfirmationType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="OrderNumber" type="string"/>

                        <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                        <element name="Buyer" type="pay:SubscriberType"/>

                        <element name="BuyerAccount" type="pay:AccountType"/>

                        <element ref="pay:Amount"/>

                        <element name="Seller" type="pay:SubscriberType"/>

                        <element name="SellerAccount" type="pay:AccountType"/>

                        <element name="SellerVASP" type="pay:VASPType"/>

                        <element name="VAT" type="pay:VATType"/>

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

<element name="PaymentOrder_VA-VA" type="pay:PaymentOrder_VA-VAType"/>

<complexType name="PaymentOrder_BU-VAType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <choice>

                              <element name="Confirmation" type="pay:PaymentConfirmationType"/>

                              <element name="Negation" type="pay:FaultType"/>

                              <element ref="dsig:Signature"/>

                        </choice>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="PaymentConfirmationType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="OrderNumber" type="string"/>

                        <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                        <element name="Buyer" type="pay:SubscriberType"/>

                        <element name="BuyerAccount" type="pay:AccountType"/>

                        <element ref="pay:Amount"/>

                        <element name="Seller" type="pay:SubscriberType"/>

                        <element name="SellerAccount" type="pay:AccountType"/>

                        <element name="SellerVASP" type="pay:VASPType"/>

                        <element name="VAT" type="pay:VATType"/>

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

<element name="PaymentOrder_VA-SE" type="pay:PaymentOrder_VA-SEType"/>

<complexType name="PaymentOrder_VA-SEType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <choice>

                              <element name="Confirmation" type="pay:PaymentExecutedType"/>

                              <element name="Fault" type="pay:FaultType"/>

                              <element ref="dsig:Signature"/>

                        </choice>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="PaymentExecutedType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="OrderNumber" type="string"/>

                        <element name="LicenseInfo" type="pay:LicenseInfoType"/>

                        <element name="Buyer" type="pay:SubscriberType"/>

                        <element name="BuyerAccount" type="pay:AccountType"/>

                        <element ref="pay:Amount"/>

                        <element name="VAT" type="pay:VATType"/>

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

<element name="StoreSubscriberData_VA-SS" type="pay:StoreSubscriberData_VA-SSType"/>

<complexType name="StoreSubscriberData_VA-SSType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="DefaultReportID" type="string"/>

                        <element name="DefaultedUser" type="pay:SubscriberType"/>

                        <element name="DefaultRecord" type="pay:RecordType"/>

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="RecordType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="DefaultTime" type="time"/>

                        <element name="DefaultAmount" type="long"/>

                        <element name="ReportingVASP" type="pay:VASPType"/>

                        <element name="AffectedOrderNumber" type="string" maxOccurs="unbounded"/>

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

<element name="RetrieveSubscriberData_VA-SS" type="pay:RetrieveSubscriberDataRequestType"/>

<complexType name="RetrieveSubscriberDataRequestType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element ref="pay:Subscriber"/>

                        <element name="StartTime" type="time"/>

                        <element name="EndTime" type="time"/>

                        <element ref="dsig:Signature"/>

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

<element name="RetrieveSubscriberData_SU-VA" type="pay:RetrieveSubscriberDataRequestType"/>

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.

<element name="RetrieveSubscriberData_SS-VA" type="pay:RetrieveSubscriberDataResponseType"/>

<complexType name="RetrieveSubscriberDataResponseType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="Record" type="pay:RecordType" />

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="RecordType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <choice>

                        <element name="WhiteRecord" type="pay:WhiteRecordType"/>

                        <element name="GreyRecord" type="pay:GreyRecordType"/>

                        <element name="BlackRecord" type="pay:BlackRecordType"/>

                  </choice>

            </extension>

      </complexContent>

</complexType>

<complexType name="WhiteRecordType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element ref="pay:Subscriber"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="GreyRecordType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element ref="pay:Subscriber"/>

                        <element name="RedeemRecord" type="pay:RedeemRecordType" maxOccurs="unbounded"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="RedeemRecordType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element ref="pay:Amount"/>

                        <element name="DefaultTime" type="time"/>

                        <element name="RedeemTime" type="time"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="BlackRecordType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element ref="pay:Subscriber"/>

                        <element ref="pay:Amount"/>

                        <element name="DefaultTime" type="time"/>

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

<element name="RetrieveSubscriberData_VA-SU" type="pay:RetrieveSubscriberDataResponseType"/>

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.

<element name="DefaultRedistribution_VA-BU" type="pay:DefaultRedistribution_VA-BUType"/>

<complexType name="DefaultRedistribution_VA-BUType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="DefaultReportID" type="string"/>

                        <element name="Account" type="pay:AccountType"/>

                        <element name="AmountDefaulted" type="long"/>

                        <element name="DateOfDefault" type="time"/>

                        <element ref="dsig:Signature"/>

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

<element name="DefaultRedistribution_VA-SS" type="pay:DefaultRedistribution_VA-SSType"/>

<complexType name="DefaultRedistribution_VA-SSType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="DefaultReportID" type="string"/>

                        <element name="DefaultedUser" type="pay:SubscriberType"/>

                        <element name="RemoveVASPCredit" type="pay:RemoveVASPCreditType" maxOccurs="unbounded"/>

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="RemoveVASPCreditType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="AffectedVASP" type="pay:VASPType"/>

                        <element ref="pay:Amount"/>

                        <element name="AffectedOrderNumber" type="string" maxOccurs="unbounded"/>

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

<element name="DefaultRedistribution_SS-VA" type="pay:DefaultRedistribution_SS-VAType"/>

<complexType name="DefaultRedistribution_SS-VAType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="DefaultReportID" type="string"/>

                        <element name="DefaultedUser" type="pay:SubscriberType"/>

                        <element name="RemoveUserCredit" type="pay:RemoveUserCreditType" maxOccurs="unbounded"/>

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="RemoveUserCreditType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="AffectedUser" type="pay:UserType"/>

                        <element ref="pay:Amount"/>

                        <element name="AffectedOrderNumber" type="string" maxOccurs="unbounded"/>

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

<element name="DefaultRedistribution_VA-SE" type="pay:DefaultRedistribution_VA-SEType"/>

<complexType name="DefaultRedistribution_VA-SEType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="DefaultReportID" type="string"/>

                        <element name="DefaultedUser" type="pay:SubscriberType"/>

                        <element name="RemoveCredit" type="pay:RemoveSubscriberCreditType" maxOccurs="unbounded"/>

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="RemoveSubscriberCreditType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="Account" type="pay:AccountType"/>

                        <element ref="pay:Amount"/>

                        <element name="AffectedOrderNumber" type="string" maxOccurs="unbounded"/>

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

<complexType name="CreateVASPAccount_VA-SSType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element name="VASPInfo" type="pay:VASPInfoType"/>

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="VASPInfoType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="CommercialEntity" type="pay:CommercialEntityType"/>

                        <element name="Address" type="pay:AddressType" minOccurs="0"/>

                        <element name="Account" type="pay:AccountType"/>

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

<element name="CreateVASPAccount_SS-VA" type="pay:CreateVASPAccount_SS-VAType"/>

      <complexType name="CreateVASPAccount_SS-VAType">

            <complexContent>

                  <extension base="pay:PaymentProtocolType">

                        <sequence>

                              <choice>

                                    <element ref="pay:VASP"/>

                                    <element name="Fault" type="pay:FaultType"/>

                              </choice>

                              <element ref="dsig:Signature"/>

                        </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

<element name="VASPServiceURLRegister_VA-SS" type="pay:VASPServiceURLRegister_VA-SSType"/>

<complexType name="VASPServiceURLRegister_VA-SSType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element ref="pay:VASP"/>

                        <element name="ServiceURL" type="pay:ServiceURLType" maxOccurs="unbounded"/>

                        <element ref="dsig:Signature"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<complexType name="ServiceURLType">

      <complexContent>

            <extension base="pay:PaymentBaseType">

                  <sequence>

                        <element name="ServiceName" type="pay:ServiceNameType"/>

                        <element name="ServiceURL" type="anyURI"/>

                  </sequence>

            </extension>

      </complexContent>

</complexType>

<simpleType name="ServiceNameType">

      <restriction base="string">

            <enumeration value="CashOrderSEVA"/>

            <enumeration value="CashOrderVAVA"/>

            <enumeration value="CashOrderVABU"/>

            <enumeration value="CreateSubscriberAccountSUVA"/>

            <enumeration value="RetrieveSubscriberDataSUVA"/>       

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

<element name="VASPServiceURLRegister_SS-VA" type="pay:VASPServiceURLRegister_SS-VAType"/>

<complexType name="VASPServiceURLRegister_SS-VAType">

      <complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <choice>

                              <element name="Success" type="pay:SuccessType"/>

                              <element name="Fault" type="pay:FaultType"/>

                        </choice>

                              <element ref="dsig:Signature"/>

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

<element name="VASPServiceURL_VA-SS" type="pay:VASPServiceURL_VA-SSType"/>

<complexType name="VASPServiceURL_VA-SSType">

<complexContent>

            <extension base="pay:PaymentProtocolType">

                  <sequence>

                        <element ref="pay:VASP"/>

                        <element name="ServiceName" type="pay:ServiceNameType"/>

                        <element ref="dsig:Signature"/>

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

<element name="VASPServiceURL_SS-VA" type="pay:VASPServiceURL_SS-VAType"/>

<complexType name="VASPServiceURL_SS-VAType">

            <complexContent>

                        <extension base="pay:PaymentProtocolType">

                                    <sequence>

                                    <choice>

                                                <element name="VASPServiceURI" type="pay:VASPServiceURIType"/>

                                                <element name="Fault" type="pay:FaultType"/>

                                    </choice>

                                    <element ref="dsig:Signature"/>

                                    </sequence>

                        </extension>

            </complexContent>

</complexType>

<complexType name="VASPServiceURIType">

            <complexContent>

                        <extension base="pay:PaymentBaseType">

                                    <sequence>                 

                                                <element ref="pay:VASP"/>

                                                <element name="ServiceURL" type="pay:ServiceURLType"/>

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

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

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:

  1.  SAV – Stationary Audio Visual Device
  2.  CPD – Content Provider Device
  3.  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 log2N 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:

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:

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:

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