Sviluppo e sperimentazione di
applicazioni iDRM e iPay
Leonardo Chiariglione
1° incontro dmin.it
Torino, 2007/06/25
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
1
Proposta di agenda
No.
Agenda item
Inizio
Fine
1.
Benvenuto, logistica
10:00
10:10
2.
Obiettivi dell’incontro
10:10
10:30
3.
Presentazione specifiche IDP-2.1
10:30
10:45
4.
Presentazione Chillout
10:45
11:00
5.
Presentazione di possibili obiettivi
11:00
13:00
Intervallo pranzo
13:00
14:00
6.
Identificazione di attività in collaborazione
14:00
15:00
7.
Modalità di realizzazione/tempistica sviluppi
15:00
16:00
8.
Azioni per la promozione dell’iniziativa
16:00
16:15
9.
Punto di riferimento dell’attività
16:15
16:30
10.
Altri temi da discutere
16:30
17:00
11.
Chiusura
17:00
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
2
Obiettivi dell’incontro
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
3
Chi è dmin.it, cosa si propone e come
lo vuole raggiungere
• Gruppo aperto e no-profit con l’obiettivo di fare proposte
per consentire all’Italia di acquisire un ruolo primario nello
sfruttamento del fenomeno globale “digital media”
• Per dmin.it questo si ottiene
– Massimizzando la circolazione dei digital media
– Coniugando i requisiti
• Degli autori: libertà di poter offrire le proprie opere
• Degli intermediari: libertà di scelta del ruolo e del modo di
raggiungerlo
• Dei consumatori: libertà di poter accedere ai contenuti
– Agendo sulle modalità di offerta di/accesso a
• Contenuti
• Reti a larga banda
• Servizi di pagamento
• Vediamo come…
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
4
1 – Offerta di/accesso a contenuti
• A livello nazionale è adottata una specifica di
Digital Rights Management interoperabile
(iDRM) che è
• Pubblica
• Realizzata in codice sorgente aperto (Open Source)
• Abilitante tutti i ruoli legittimi di intermediazione, cioè
non prescrittiva di particolari business model
• Se un fornitore offre contenuti con DRM
proprietario su un canale di distribuzione deve
anche offrirli su quel canale
• Con iDRM affinché gli autori possano proporre le loro
opere ed i cittadini possano accedervi con i dispositivi di
loro scelta
• A condizioni eque e non discriminatorie se confrontate
con l’offerta fatta usando la propria tecnologia
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
5
L’iDRM al lavoro
pDRM
iDRM
Canale
distributivo
di tipo 1
dispositivo
pDRM
dispositivo
iDRM
Contenuti
dell’operatore A
pDRM
Canale
distributivo
di tipo 2
iDRM
dispositivo
pDRM
dispositivo
iDRM
pDRM: DRM proprietario
iDRM: DRM interoperabile
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
6
2 – Accesso alla rete a larga banda
1. Un operatore di rete a larga banda può
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) può richiedere ed
ottenere da un operatore di rete a larga banda
1. Il puro accesso “service-agnostic” alla "big Internet“
con le caratteristiche tecniche già offerte dall’operatore
2. A condizioni non discriminatorie nei confronti delle altre
offerte dell’operatore
3. Gli operatori di rete a larga banda
1. Garantiscono l’interoperabilità dei servizi di rete
2. Concordano e forniscono specifici livelli di qualità di
servizio (QoS) ai punti di peering per fornire agli utenti
della rete opportuni livelli di QoS
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
7
L’accesso alla rete a larga banda
secondo dmin.it
Accesso
proprietario
Accesso
proprietario
Rete
proprietaria
dell’operatore A
Rete
proprietaria
dell’operatore B
Rete dell’
operatore C
Rete aperta
dell’operatore A
Peering
Point
Accesso
dmin.it
2007/06/25
Rete aperta
dell’operatore B
Peering
Point
Accesso
dmin.it
Sviluppo e sperimentazione di applicazioni iDRM e iPay
8
3 – Servizi di pagamento “pensati” per
digital media
• Chiunque, compatibilmente con le norme bancarie, può
– Diventare un “Virtual Account Service Provider” (VASP)
– Offrire servizi di “account” non direttamente monetari (punti,
unità ecc.)
• Interoperabili con i servizi offerti da altri operatori (i punti di un
operatore sono “onorati” dall’altro)
• Per transazioni collegate all’uso di digital media
• Effettuate tra “account”
• Ogni “account” si appoggia su uno strumento di pagamento
ad incasso garantito, ad esempio:
– Conto corrente, Carta di credito, Carta prepagata
– Domiciliazione bancaria, Borsellino elettronico
• La sincronizzazione di un “account” con il suo circuito di
appoggio è effettuata su base periodica o a richiesta
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
9
Il “sistema economico” di dmin.it
Utente 1
della catena
del valore
(p.e. Venditore)
Acct11
Acct12
Fornitore di Servizi
di “Account” 1
Negoziazione contenuti
con dati di pagamento
Negoziazione rete
con dati di pagamento
Pagamenti
Utente 2
della catena
del valore
(p.e. Consumatore)
Acct21
Fornitore di Servizi
di “Account” 2
Acct1n
Acct22
Acct2m
Servizi
Condivisi
Conto
Corrente
2007/06/25
Carta di
Credito
Carta
prepagata
Conto
Corrente
Sviluppo e sperimentazione di applicazioni iDRM e iPay
Carta di
Credito
Domicil.
bancaria
10
La roadmap di dmin.it
Set 06
Proposta di interventi su accesso a
– Contenuti (iDRM)
– Rete a larga banda (iNet)
– Sistemi di pagamento (iPay)
Mar 07
Richiesta di soluzioni, interventi normativi e governance
Giu 07
Scelta delle soluzioni e tecnologie
Lug 07
Nuova richiesta suinterventi normativi e governance
Set 07
Nuova versione di interventi normativi e governance
Dic 07
Proposta completa di
– Specifiche tecniche (iDRM/iNet/iPay)
– Interventi normativi
– Governance
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
11
Perché ci troviamo oggi?
• dmin.it ha scelto di lavorare su una vasta gamma di
problemi fondamentali per il futuro
• dmin.it ha scelto le tecnologie necessarie (iDRM, iPay) e lo
strumento per realizzare soluzioni (open source software)
• Occorre però che la comunità nazionale tocchi con mano
che cosa le tecnologie scelte possono dare
• Lo scopo dell’incontro odierno è quindi di costituire un
gruppo con il compito di
–
–
–
–
Concepire
Progettare
Realizzare
Sperimentare
soluzioni abilitate dalle tecnologie iDRM, iNet, iPay scelte da
dmin.it
• Cominciando da iDRM…
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
12
Obiettivi specifici della giornata/1
•
•
•
Condividere la specifica Interoperable DRM Platform
versione 2.1 (IDP-2.1) del DMP
Condividere le caratteristiche operative della piattaforma
Chillout
Presentazione di attività che possono beneficiare di o
essere abilitate da Chillout
–
–
–
•
Attività già in corso
Nuove attività
Possibili progetti nazionali...
Identificazione di
–
–
–
Attività da raccomandare come “attività collaborative dmin.it”
Attività per sviluppare/migliorare nuove funzionalità della
piattaforma
Persone interessate a partecipare
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
13
Obiettivi specifici della giornata/2
• Definizione di
– Modalità realizzative
– Tempistica degli sviluppi
• Promozione dell’iniziativa
• Agganci con altre iniziative
• Se c’è tempo
– Studio del sistema iPay scelto
• Tecnologia adottata
• Realizzazione proposta
– Collegamento con la soluzione iNet
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
14
Presentazione specifiche IDP-2.1
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
15
Presentazione Chillout
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
16
Presentazione di possibili obiettivi
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
17
Possibili aree di collaborazione
•
•
•
•
•
•
•
Contenuti governati in ambiente P2P
Porting di Chillout su dispositivi hardware acquistabili
–
–
–
iPod/PSP/Xbox360
Telefonini
Piattaforme con sistemi opensource e/o interoperable
–
–
garantirne la fonte e la natura
(tramite metadata) renderne chiari impiego, funzionalità, requisiti
minimi, licenza, etc.
Gestione di piccole applicazioni (applet) OS e hardware agnostic
tramite iDRM per
Gestione di servizi interattivi controllati e resi sicuri e
confidenziali tramite iDRM dedicati al DTT ed al mobile (DVB-H).
Gestione di parental control tramite iDRM e metadata.
Tracciabilità dei Contenuti tramite iDRM e metadata
–
–
a fini di DR enforcement
“purging” della rete dai contenuti inaccettabili per legge
Tutte le estensioni di Chillout richieste dagli sviluppi collaborativi
di applicazione
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
18
Contributi
Autore
G.
Iannizzotto
G.
Iannizzotto
W. Allasia
Affil.
Titolo
UniME idDRM: Proposta di applicazione della
tecnologia iDRM ai documenti digitali
UniME isDRM – interoperable service DRM
d p
x x
Eurix EURIXGroup: iDRM in Peer2Peer
Group environment Implementation Plan
UniME personal interoperable DRM (piDRM)
x x
G.
Iannizzotto
F. Berardi
Inrete Personal recording attribution / license
G. Ruffo, R. UniTO FairPeers: Efficient Profit Sharing in Fair
Schifanella
Peer-to-Peer Market Places
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
x x
x x
x x
x x
19
Identificazione di attività in
collaborazione
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
20
Modalità di realizzazione e
tempistica degli sviluppi
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
21
Ambiente collaborativo
•
•
•
•
Riflettore email
Wiki
Repository del software
Server per applicazioni dmin.it
(contenuti, licenze ecc.)
• ...
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
22
Natura del lavoro fatto
collaborativamente
• Piattaforme: sviluppi Open Source da
contribuire a
– dmin.it
– Chillout (preferibile)
• Applicazioni/demo: vari gradi di
condivisione in ordine di desiderabilità
–
–
–
–
–
Codice condiviso all’interno di Chillout  
Codice condiviso all’interno di dmin.it 
Uso dell’applicazione in ambito italiano
Uso dell’applicazione in ambito dmin.it 
Tutto trattenuto da chi ha fatto lo sviluppo  
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
23
Azioni per la promozione dell’iniziativa
• Inviare CS a giornalisti
• Far conoscere il programma di lavoro ad
altri gruppi (e.g. EBU, Chillout)
• Creare pagina wiki puntabile dall’esterno
• Angelo cura la pagina d’ingresso
• Wiki.dmin.it
• CNIPA
• Mondo bancario (Banca Sella, CIM, SSB,
Messina, Guidotti – Intesa SP)
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
24
Punto di riferimento dell’attività
• Giancarlo
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
25
Altri temi da discutere
• iPay
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
26
Il sistema economico di dmin.it
Utente 1
della catena
del valore
(p.e. Venditore)
Acct11
Acct12
Fornitore di Servizi
di “Account” 1
Negoziazione contenuti
con dati di pagamento
Negoziazione rete
con dati di pagamento
Pagamenti
Utente 2
della catena
del valore
(p.e. Consumatore)
Acct21
Fornitore di Servizi
di “Account” 2
Acct1n
Acct22
Acct2m
Servizi
Condivisi
Conto
Corrente
2007/06/25
Carta di
Credito
Carta
prepagata
Conto
Corrente
Sviluppo e sperimentazione di applicazioni iDRM e iPay
Carta di
Credito
Domicil.
bancaria
27
Scenari d'uso
• Un consumatore (Leonardo) compra una canzone dando
istruzioni a Pippo, il suo VASP, di pagare Pluto, il VASP di
Mimmo, un artista da cui vuole comperare direttamente
una canzone senza passare attraverso intermediari
• Un consumatore (Roberta) guarda un programma TV live
pagandosi parte del contenuto attraverso la fruizione di
pubblicità
• Un consumatore (Antonella) compra la musica da un
provider (Mimmo) pagandosela con la fruizione di pubblicità
e con la cessione di alcuni dati privati
• Un consumatore (Luca) compra da un provider (Napsterlike) l'abbonamento mensile per scaricare tutta la musica
che vuole
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
28
Che cosa c’è come specifica iPay
• L'identificazione degli attori
– Utenti
– VASP
– Servizi Condivisi
• I formati dei messaggi scambiati tra gli attori
– per esempio
•
•
•
•
•
•
Creazione di un account (Utente->VASP)
Richiesta Identificativo Univoco (VASP->Servizi Condivisi)
Ordine d'acquisto (Utente->Utente)
Disposizione di Incasso (Utente->VASP->VASP->Utente)
Caricamento default (VASP->Serv.Cond)
ecc.
– in XML Schema
• i protocolli WSDL sono facilmente producibili
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
29
Reference Implementation
• Possibilità 1: partire dal codice OSS Cyclos
(http://project.cyclos.org)
– identificando le corrispondenza di Cyclos ai
requisiti di dmin.it
– identificando le estensioni architetturali e
funzionali di Cyclos necessarie a coprire i
requisiti di dmin.it
– valutando la fattibilità di tali estensioni
– decidere se procedere con Cyclos oppure
implementare la proposta from scratch
• Possibilità 2: partire da zero 
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
30
Modello di comunicazione
Utente
Utente
VASP
VASP
Servizi
Condivisi
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
31
iNet/1
• Requisiti essenziali di servizio di accesso a “big Internet”, “service
agnostic sono:
– Assegnazione statica o dinamica di almeno un indirizzo IP “pubblico”;
– Nessuna limitazione sul numero di port numbers (TCP, UDP)
utilizzabili;
– Nessun filtraggio selettivo del traffico su base:
• “Port number”;
• Indirizzi destinazione o sorgente;
• Servizio applicativo utilizzato;
• Inoltre sono servizi indispensabili:
– Risoluzione dei nomi (DNS);
– Mail forwarding (SMTP).
• Allo stato attuale non viene presa in considerazione la
compatibilità con IPv6.
• Requisiti opzionali sono funzionalità di:
– Accesso “premium” per specifiche direttrici di traffico;
– Multicast e/o streaming (con controllo della banda utilizzata e
prioritizzazione del traffico)
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
32
iNet/2
• Per quanto riguarda il peering, la specifica
BGP-4 definisce in dettaglio come devono
comportarsi gli operatori al punto di
interconnessione, di tipo 1:1 e 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.
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
33
iNet/3
• Qualora l’operatore offra servizi con QoS, area
ancora non consolidata, lungo la catena end-toend devono essere soddisfatti i seguenti requisiti:
– Più classi di servizio in numero prefissato (in dipendenza
dalla tecnologia adottata);
– Mantenimento dei livelli di servizio previsti da ogni
classe lungo tutta la catena, dal nodo sorgente al nodo
destinazione;
– Equivalenza delle classi di servizio di ogni operatore alla
frontiera di peering;
– Uniformità di QoS per il traffico di una classe di servizio,
indipendentemente dalle caratteristiche del traffico
(indirizzi sorgente/destinazione, port number,
applicazione);
– Responsabilità del controllo di flusso al nodo sorgente.
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
34
iNet/4
• Inoltre devono essere specificati i Service
Level Agreement (SLA) che gli operatori
sottoscrivono al fine di rendere
interoperabili i loro servizi di QoS
• Tali SLA potranno essere diversi nel caso
di
– Peering “privato”, cioè attraverso un
collegamento diretto;
– Peering “pubblico”, cioè realizzato presso un
Network Access Point (NAP)
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
35
Chiusura
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
36
Ricordarsi di
http://www.dmin.it/
2007/06/25
Sviluppo e sperimentazione di applicazioni iDRM e iPay
37