Proposta

Un sistema flessibile di micropagamenti a punti per digital media
A. Ardizzone (IULM), L. Barbarito (IULM), F. Chiariglione (CEDEO.net), M. Cosenza (Sinapsi),
G.L. Dettori (dpixel), R. Enni (RAI)
Executive Summary
Questo documento è una proposta fatta a Digital Media in Italia dalle persone segnate come autori in
capo al documento. La proposta è fatta in risposta alla “Richiesta di tecnologie e soluzioni per la
realizzazione delle proposte dmin.it” [1] e, specificatamente, alla sezione 5.3 “Sistemi di pagamento
flessibili”.
Indice
Executive Summary ............................................................................................................................. 1
Indice .................................................................................................................................................... 1
1
Introduzione ................................................................................................................................. 2
2
Schema di riferimento .................................................................................................................. 2
3
Requisiti di sistema ...................................................................................................................... 3
4
Scenari d’uso ................................................................................................................................ 5
4.1
Leonardo compera una canzone da Mimmo ........................................................................ 5
4.2
Roberta guarda un programma TV live................................................................................ 6
4.3
Antonella ascolta la musica pagandola con la pubblicità ..................................................... 6
4.4
Luca ascolta musica in abbonamento ................................................................................... 7
5
Soluzione tecnica.......................................................................................................................... 9
5.1
Gli elementi da standardizzare ............................................................................................. 9
5.1.1
Gli attori ....................................................................................................................... 9
5.1.2
Le comunicazioni ....................................................................................................... 10
5.2
Rappresentazione XML delle strutture dati ....................................................................... 10
5.2.1
Creazione account (createAccount) ........................................................................... 10
5.2.1.1 Subscriber – VASP................................................................................................. 10
5.2.1.2 VASP – SS ............................................................................................................. 11
5.2.1.3 SS – VASP ............................................................................................................. 11
5.2.1.4 VASP – Subscriber................................................................................................. 12
5.2.2
Ordine d'acquisto ........................................................................................................ 12
5.2.2.1 Subscriber (BU) – Subscriber (SE) ........................................................................ 12
5.2.3
Disposizione d'incasso ............................................................................................... 13
5.2.3.1 Subscriber (SE)– VASP ......................................................................................... 13
5.2.3.2 VASP – VASP ....................................................................................................... 14
5.2.3.3 VASP – Subscriber (BU) ....................................................................................... 14
5.2.4
Disposizione di pagamento ........................................................................................ 15
5.2.4.1 Subscriber (BU) – VASP ....................................................................................... 15
5.2.4.2 VASP – VASP ....................................................................................................... 16
5.2.4.3 VASP – Subscriber (SE) ........................................................................................ 17
5.2.5
Caricamento dati utente insolvente ............................................................................ 18
5.2.5.1 VASP – SS ............................................................................................................. 18
5.2.6
Consultazione dati utente ........................................................................................... 19
5.2.6.1 VASP – SS ............................................................................................................. 19
5.2.6.2 Subscriber – SC ...................................................................................................... 19
5.2.6.3 SS – VASP ............................................................................................................. 20
5.2.6.4 VASP – Subscriber................................................................................................. 20
5.2.6.5 SS – User ................................................................................................................ 20
5.2.7
Ridistribuzione default ............................................................................................... 21
5.2.7.1 VASP – Subscriber................................................................................................. 21
5.2.7.2 VASP – SS ............................................................................................................. 21
5.2.7.3 SS – VASP (SE) ..................................................................................................... 22
5.2.7.4 VASP (SE) – Subscriber (SE) ................................................................................ 23
5.3
I protocolli .......................................................................................................................... 24
6
Reference software ..................................................................................................................... 24
6.1
Descrizione della soluzione di partenza ............................................................................. 24
6.2
Estensioni necessarie .......................................................................................................... 28
6.3
Agganci a iDRM ................................................................................................................ 28
7
Conformità della proposta .......................................................................................................... 28
7.1
Conformità ai requisiti ....................................................................................................... 28
7.1.1
Requisiti generali........................................................................................................ 28
7.1.2
Requisiti tecnici .......................................................................................................... 30
7.1.3
Requisiti di business ................................................................................................... 31
7.2
Conformità ai criteri della richiesta .................................................................................... 31
7.3
Conformità al contesto normativo italiano ......................................................................... 33
8
Bibliografia................................................................................................................................. 33
Annex A – Modulo di registrazione ................................................................................................... 34
Annex B – Modulo per copertura delle proposta ............................................................................... 36
Annex C – Glossario .......................................................................................................................... 37
Annex D – Argomenti pro e contro la convertibilità fissa ................................................................. 38
1
Introduzione
In questa proposta si definisce un sistema di pagamento specifico conforme ai requisiti generali
della Richiesta di tecnologie e soluzioni per la realizzazione delle proposte dmin.it [1] ed una sua
possibile realizzazione basata su un Local Exchange Trading System (LETS) [2] chiamato cyclos
[3].
2
Schema di riferimento
Nella “proposta operativa” di dmin.it è dato il seguente schema di riferimento per il sistema di
pagamento dmin.it
Fig. 1 – Schema di riferimento del sistema di pagamento dmin.it [1]
3
Requisiti di sistema
In questo capitolo si raccolgono in modo sistematico alcuni dei requisiti del sistema di pagamenti
contenuti nella richiesta [1] ed altri requisiti sviluppati specificatamente per questa proposta. Si
prega di notare che alcune di queste ipotesi sono state introdotte per facilitare la progettazione del
sistema ma alcune potrebbero essere rimosse o modificate.
Notare la nomenclatura
1.
2.
3.
4.
Utente: ogni attore che opera nel sistema di pagamento
Subscriber: un attore che ha un Account su un VASP
VASP: Virtual Account Service Provider
Servizi Condivisi
1. Il sistema di pagamenti proposto è parallelo e non sostitutivo di altri sistemi di pagamento (già in
[1])
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
a. Uno o più Account
b. Presso uno o più VASP
c. Con o senza possibilità di convertire punti in moneta reale
d. Eventualmente con dei limiti prefissati al livello di punti negativi cumulabili
e. Da usare dal titolare per regolare i suoi pagamenti, se la sua controparte accetta
3. Gli Account sono
a. Basati su un’unità di conto (punti) che è unica per tutto il sistema di pagamenti proposto ed
accettata da tutti i VASP
b. Dipendenti da un solo sistema di pagamento in moneta reale (relazione biunivoca)
c. Sincronizzati periodicamente o a richiesta degli Utenti con dei sistemi di pagamento in
moneta reale ad incasso garantito
d. Gerarchici, cioè possono contenere dei Sub-Account
e. Non gravati/beneficiati di interessi sui punti depositati
f. 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
a. Sono convertibili in moneta reale a richiesta dell’Utente titolare dell’Account o a intervalli
determinati
b. Rappresentano un valore monetario molto piccolo (e.g. 0,001 €) per permettere, ad esempio,
impulse buying/selling
c. Hanno un rapporto
i.
Espresso da un numero qualsiasi
ii.
Determinato all’istante t0 dalla Governance dei sistema economico dmin.it
iii. Dopo di che il valore rimane fisso oppure varia (v. Annex C)
5. Esiste un punto di raccolta dati chiamato Servizi Condivisi che
a. È unico nel sistema economico dmin.it
b. Raccoglie informazione sui default dei titolari di Account dai VASP
c. Fornisce su richiesta informazione sulle trasgressioni dei titolari degli Account a
i.
Un VASP
ii.
Un Utente solamente per reperire informazioni riguardo a se stesso
d. È 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
a. Ispezioni ai “libri contabili” dei VASP
b. 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
a. Tra tutti coloro che sono stati pagati a punti dopo l’ultima sincronizzazione conclusasi con
successo
b. 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
a. L’informazione necessaria per permettere loro di pagare l’IVA come per legge
b. 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
a. Servizi Condivisi
b. 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
a. All’interno del VASP
b. All’interno del sistema di pagamenti proposto mediante associazione all’ID del VASP
4
Scenari d’uso
4.1 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).
1. Leonardo a. Visita il sito di Mimmo
c. Vede una canzone che gli piace
d. È 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
e. Scarica il file della canzone cifrata Da Mimmo
f. Manda a Mimmo l'Ordine di Acquisto contente l’ID dell'account da cui effettuerà
il pagamento
2. Mimmo
a. Manda una Disposizione d’Incasso al suo VASP Pluto
3. Pluto
a. Consulta i Servizi condivisi
b. Inoltra al VASP Pippo di Leonardo la Disposizione d’Incasso
4. Pippo
a. Informa Leonardo della ricezione della Disposizione d’Incasso
5. Leonardo a. Dà l’OK a Pippo
6. Pippo
a. Accredita i 100 punti sul conto di Mimmo presso Pluto
7. Pluto
a. Comunica l’avvenuta ricezione del pagamento a Mimmo
8. Mimmo
a. Confeziona la licenza temporanea
b. Comunica a Leonardo che la licenza temporanea è pronta
9. Leonardo a. Scarica la licenza temporanea da Mimmo
b. Ascolta la canzone come da termini della licenza temporanea
10. Pippo
a. Sincronizza con il conto corrente di Leonardo; risultato: successo
(dopo 12 gg) b. Comunica il successo a Pluto
11. Pluto
a. Comunica il successo a Mimmo
12. Mimmo
a. Confeziona la licenza definitiva
b. Comunica a Leonardo che la licenza definitiva è pronta
13. Leonardo a. Scarica la licenza definitiva
b. Ascolta la canzone come da termini della licenza definitiva
14. Ovvero
a. Sincronizza con il conto corrente di Leonardo; risultato: insuccesso (e.g.
Pippo
insufficienza di fondi)
(dopo 12 gg) b. Comunica l’insuccesso a Pluto
c. Comunica l’insuccesso a Leonardo
d. Computa quanti punti ogni utente che ha ricevuto pagamenti in punti da
Leonardo dopo l’ultima sincronizzazione deve restituire
e. Invia una comunicazione ai Servizi Condivisi contenente la lista
i.Degli utenti
15. Servizi
Condivis
i
16. Pluto
ii.Dei punti che ognuno deve restituire
iii.Degli Account su cui tale operazione va fatta
a. Comunica ad ogni VASP ammontare ed Account
a. Comunica l’insuccesso a Mimmo
b. Detrae dal conto di Mimmo l’ammontare di punti comunicato dai Servizi
Condivisi
17. Leonardo a. Non può più sentire la canzone di Mimmo
(dopo 15 gg)
4.2 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.
1. Roberta 1.
2.
3.
4.
2. Publi+ 1.
3.
4.
5.
6.
7.
Roberta
Publi+
Roberta
Publi+
Roberta
1.
1.
1.
1.
1.
2.
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+
Invia via internet un’EAG (Electronic Advertisement Guide) di pubblicità. Ogni
entry ha associato il suo numero di punti dmin
Sceglie 3 entry di pubblicità per accumulare il numero di punti desiderato
Invia via internet le 3 entry di pubblicità
Guarda le 3 entry
Accredita i punti accumulati sul virtual account di 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.3 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.
1. Antonella 1. Visita il sito di Mimmo
2. Vede una canzone che le piace
3. È d’accordo sulle condizioni del modello di licenza che dice
1. “Costa” 1 minuto di pubblicità
2. Con la fornitura di un profilo di profondità stabilita
3. Da ascoltare ogni volta prima dell’ascolto del brano
4. Manda a Mimmo l’ordine di acquisto con
1. Il suo “profilo” di profondità richiesta nella licenza
2. Una licenza d’uso che permette di utilizzare il profilo solo per le
necessità del servizio in questione
2. Mimmo
Manda a Publi+
1. La richiesta di pagamento per la canzone
2. Il profilo con relativa licenza (con sublicence)
3. Publi+
1. Accetta la richiesta di pagamento
2. Manda la disposizione di pagamento della canzone al suo VASP Paperino
3. Chiede a Mimmo i dati di Antonella per confezionare la pubblicità “su misura”
per lei
4. Mimmo
Manda al suo VASP Pluto
1. La disposizione di incasso
2. I dati di Antonella
3. La canzone cifrata richiesta da Antonella
5. Pluto
Manda la disposizione di incasso a Paperino
6. Paperino 1. Detrae i punti dal conto di Publi+
2. Manda i punti a Pluto
7. Pluto
1. Incassa i punti
2. Manda i dati di Antonella a Paperino
8. Paperino Prepara e manda a Pluto il pacchetto pubblicitario da allegare al brano
9. Pluto
1. Riceve la pubblicità per Antonella
2. Confeziona il pacchetto canzone cifrata+pubblicità
3. 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.4 Luca ascolta musica in abbonamento
In questo scenario Luca si abbona ad servizio di musica “Dormi bene” modellato sull’offerta
“Napster” (finché sei abbonato scarichi e senti tanta musica quanta vuoi)
1. Luca
1. Dormi
bene
2. NASP
1. Visita il sito di Dormi bene
2. Visualizza le condizioni di abbonamento al servizio
3. È d’accordo sulle condizioni di abbonamento che dicono
1. “Costa” 100 punti al mese
2. Consente di scaricare un numero illimitato di brani musicali
3. I brani possono essere ascoltati solamente fino a quando
l'abbonamento è attivo
4. Si registra sul sito di Dormi bene
5. Manda a Dormi bene l'ordine di acquisto dell'abbonamento contenente le
coordinate del proprio account virtuale
1. Riceve l'ordine di acquisto dell'abbonamento dal nuovo utente registrato
2. Compila ed invia al proprio VASP (NASP) la Disposizione di Incasso
corrispondente all'ordine di acquisto
1. Riceve la disposizione di incasso da Dormi bene
2. Consulta i Sevizi Condivisi
3. Servizi
1. Riceve la richiesta di consultazione per Luca
Condivisi 2. Consulta le blacklist e le greylist
3. Invia il risultato a NASP
4. NASP
1. Riceve il risultato di consultazione dei Servizi Condivisi1
2. Invia la disposizione di incasso al VASP di Luca (LASP)
5. LASP
1. Riceve la disposizione di incasso da NASP
2. Richiede a Luca l'OK per il pagamento
6. Luca
1. Riceve la richiesta di nulla osta per il pagamento
2. Invia l'ok per il pagamento a LASP
7. LASP
1. Riceve l'ok per il pagamento
2. Esegue la transazione di pagamento a Dormi bene attraverso NASP
(decrementa il di 100 punti il conto di Luca)
8. NASP
1. Riceve la transazione di pagamento della disposizione di incasso
2. Accredita di 100 punti il contro di Dormi bene
3. Notifica Dormi bene dell'avvenuto pagamento dell'abbonamento da parte di
Luca
9. Dormi
1. Riceve la notifica del pagamento della disposizione di incasso
bene
2. Attiva l'utenza di Luca
3. Notifica Luca dell'attivazione dell'utenza
10. Luca
1. Riceve da Dormi bene la notifica dell'attivazione della sua utenza
2. Si autentica su sito di Dormi bene
3. Sceglie i brani da scaricare
11. Dormi
1. Confeziona i package cifrati dei brani
bene
2. Confeziona le licenze temporanee dei brani scelti da Luca
3. Notifica Luca della disponibilità dei brani e delle corrispondenti licenze
12. Luca
1. Scarica i brani e le corrispondenti licenze sul proprio SAV
2. Eventualmente trasferisce i brani dal SAV al PAV
13. LASP
1. Esegue la conversione mensile sul circuito di pagamento associato all'account
di Luca
2. Comunica a NASP il risultato della conversione
14. NASP
1. Riceve da NASP il risultato della conversione
2. Se il risultato è positivo notifica Dormi bene del successo della conversione
3. Ee il risultato è negativo
1. notifica la blacklist/greylist dei Servizi Condivisi
2. notifica Dormi bene dell'insuccesso della conversione
3. addebita Dormi bene di 100 punti
15. Servizi
1. Riceve la notifica dell'insuccesso della conversione
Condivisi 2. Alimenta la lista delle frodi
3. Assegna Luca alla lista opportuna (blacklist o greylist)
16. Dormi
1. Riceve la notifica del fallimento (insoluto) della conversione e
bene
dell'addebitamento di 100 punti sul proprio account
2. Decide cosa fare con il cliente insolvente
1 La use case si riferisce al caso in cui la consultazione dei servizi condivisi dia esito positivo. Viceversa sarebbe
necessario notificare Napster dell'esito negativo della consultazione e lasciare a ques'ultimo la decisione di come
procedere.
17. Dormi
bene
18. Luca
19. Dormi
bene
20. NASP
21. LASP
22. Luca
23. LASP
24. NASP
25. Dormi
bene
26. Luca
5
1. Al termine del periodo di abbonamento di Luca notifica quest'ultimo della
possibilità di rinnovare l'abbonamento e delle condizioni applicate al rinnovo
1. Riceve la notifica del termine del periodo di abbonamento e della possibilità
di rinnovare lo stesso
2. Se non rinnova l'abbonamento e prova a eseguire i brani scaricati con licenza
temporanea, non riesce ad ascoltarli
3. Se decide di rinnovare l'abbonamento invia a Dormi bene l'ordine di acquisto
del rinnovo dell'abbomento
1. Riceve l'ordine di acquisto del rinnovo dell'abbonamento
2. Emette ed invia a NASP la disposizione di incasso
1. Riceve la disposizione di incasso
2. Consulta i Servizi Condivisi2
3. Inoltra la disposizione di incasso a LASP
1. Riceve la disposizione di incasso
2. Richiede a Luca l'ok per il pagamento della disposizione di incasso
1. Riceve la richiesta di ok per il pagamento
2. Accetta ed invia l'ok per il pagamento
1. Riceve l'ok per il pagamento
2. Esegue la transazione (addebito di altri 100 punti sull'account di Luca)
3. Trasmette la transazione di pagamento a NASP
1. Riceve la transazione di pagamento
2. Accredita l'account di Dormi bene di 100 punti
3. Notifica Dormi bene dell'avvenuto pagamento
1. Riceve la notifica dell'avveunuto pagamento di Luca
2. Rinnova le licenze temporanea per il prolungamento del periodo di
abbonamento
3. Notifica Luca della disponibilità delle nuove licenze
1. Si autentica sul sito di Dormi bene
2. Scarica sul SAV le nuove licenze temporanee (eventualmente le trasferisce
anche su PAV)
3. Esegue i brani
Soluzione tecnica
5.1 Gli elementi da standardizzare
In questa sezione si elencano gli elementi che richiedono standardizzazione.
5.1.1 Gli attori
Il sistema dmin.it ha 4 tipologie di attori:
1. Il Subscriber
2. Il VASP
3. I Servizi Condivisi
2 In questa parte del processo non viene presa in considerazione un esito negativo dell'interrogazione del servizi
condivisi
4. I circuiti tradizionali di pagamento
5.1.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
5.2 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.
5.2.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:
5.2.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_SUVAType"/>
<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 1: 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.
5.2.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_VASSType"/>
<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 2: CreateSubscriberAccount_VA-SS
Questo messaggio contiene informazioni personali del richiedente.
5.2.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_SSVAType"/>
<complexType name="CreateSubscriberAccount_SS-VAType">
<complexContent>
<extension base="pay:PaymentProtocolType">
<sequence>
<choice>
<element ref="pay:User"/>
<element name="Fault" type="pay:FaultType"/>
</choice>
<element ref="dsig:Signature"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 3: 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.
5.2.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_SSVA in risposta dai Servizi Condivisi.
<element name="CreateSubscriberAccount_VA-SU" type="pay:CreateSubscriberAccount_VASUType"/>
<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 4: 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.
5.2.2 Ordine d'acquisto
Nel momento in cui un utente decide di acquistare un contenuto da un altro utente, il seguente
messaggio è inviato dall'acquirente al venditore:
5.2.2.1 Subscriber (BU) – Subscriber (SE)
PurchaseOrder è inviato da un Subscriber acquirente ad un Subscriber venditore
<element name="PurchaseOrder" type="pay:PurchaseOrderType"/>
<complexType name="PurchaseOrderType">
<complexContent>
<extension base="pay:PaymentProtocolType">
<sequence>
<element name="ContentID" type="anyURI"/>
<element name="LicenseCategory" type="pay:LicenseCategoryType"
minOccurs="0"/>
<element name="Buyer" type="pay:UserType"/>
<element name="BuyerVASP" type="pay:VASPType"/>
<element name="Beneficiary" type="dsig:KeyInfoType"/>
<element ref="dsig:Signature"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 5: PurchaseOrder
Questo messaggio contiene l'identificativo del contenuto che l'acquirente è intenzionato ad
acquistare, il tipo di licenza desiderata, informazioni personali, il proprio VASP, e chi è il
beneficiario a cui va intestata la licenza (eventualmente diverso da chi emette l’ordine).
5.2.3 Disposizione d'incasso
Nel momento in cui un venditore riceve un ordine d'acquisto, i seguenti messaggi vengono scambiati
tra i vari attori:
5.2.3.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:UserType"/>
<element name="BuyerVASP" type="pay:VASPType"/>
<element name="Seller" type="pay:UserType"/>
<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 6: 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 su se stesso, informazioni sul conto
corrente virtuale su cui il pagamento dovrà essere depositato, l'ammontare della cifra e l'IVA sulla
transazione.
5.2.3.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:UserType"/>
<element name="BuyerVASP" type="pay:VASPType"/>
<element name="Seller" type="pay:UserType"/>
<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 7: 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 su se stesso, informazioni sul conto
corrente virtuale su cui il pagamento dovrà essere depositato, l'ammontare della cifra e l'imposta
sulla transazione.
5.2.3.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:UserType"/>
<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 8: 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.
5.2.4 Disposizione di pagamento
Nel momento in cui un venditore riceve una disposizione d'incasso, i seguenti messaggi vengono
scambiati tra i vari attori:
5.2.4.1 Subscriber (BU) – VASP
PaymentOrder_BU-VA è inviato dal venditore 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:UserType"/>
<element name="BuyerAccount" type="pay:AccountType"/>
<element name="Amount" type="long"/>
<element name="Seller" type="pay:UserType"/>
<element name="SellerAccount" type="pay:AccountType"/>
<element name="SellerVASP" type="pay:VASPType"/>
<element name="VAT" type="pay:VATType"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 9: 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.
5.2.4.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:UserType"/>
<element name="BuyerAccount" type="pay:AccountType"/>
<element name="Amount" type="long"/>
<element name="Seller" type="pay:UserType"/>
<element name="SellerAccount" type="pay:AccountType"/>
<element name="SellerVASP" type="pay:VASPType"/>
<element name="VAT" type="pay:VATType"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 10: 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.
5.2.4.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:UserType"/>
<element name="BuyerAccount" type="pay:AccountType"/>
<element name="Amount" type="long"/>
<element name="VAT" type="pay:VATType"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 11: 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.
5.2.5 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.
5.2.5.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:UserType"/>
<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 12: PaymentOrder_VA-SC
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.
5.2.6 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.
5.2.6.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:User"/>
<element name="StartTime" type="time"/>
<element name="EndTime" type="time"/>
<element ref="dsig:Signature"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 13: RetrieveSubscriberData_VA-SS
Questo messaggio contiene l' identificativo dell'utente di cui il VASP vuole conoscere eventuali
default, e l'indicazione del periodo interessato.
5.2.6.2 Subscriber – SC
RetrieveSubscriberData_SS-SU è inviato da un Subscriber per richiedere ai Servizi Condivisi la lista
dei default da lui stesso commessi in un certo periodo temporale.
<element name="RetrieveSubscriberData_SS-SU"
type="pay:RetrieveSubscriberDataRequestType"/>
Figure 14: RetrieveSubscriberData_SS-SU
Questo messaggio, come il precedente, contiene l' identificativo dell'utente che vuole conoscere
eventuali default e l'indicazione del periodo interessato.
5.2.6.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 ref="pay:User"/>
<element name="Record" type="pay:RecordType" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="dsig:Signature"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 15: 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.
5.2.6.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 16: 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.
5.2.6.5 SS – User
RetrieveSubscriberData_VA-SU è inviato dai Servizi Condivisi ad un utente in risposta ad un
messaggio RetrieveSubscriberData_SS-SU.
<element name="RetrieveSubscriberData_SS-SU"
type="pay:RetrieveSubscriberDataResponseType"/>
Figure 17: RetrieveSubscriberData_SS-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.
5.2.7 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.
5.2.7.1 VASP – Subscriber
RetrieveSubscriberData_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 18: RetrieveSubscriberData_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.
5.2.7.2 VASP – SS
RetrieveSubscriberData_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:UserType"/>
<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 name="Amount" type="long"/>
<element name="AffectedOrderNumber" type="string"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 19: RetrieveSubscriberData_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.
5.2.7.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:UserType"/>
<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 name="Amount" type="long"/>
<element name="AffectedOrderNumber" type="string"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 20: RetrieveSubscriberData_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.
5.2.7.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:UserType"/>
<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 name="Amount" type="long"/>
<element name="AffectedOrderNumber" type="string"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 21: RetrieveSubscriberData_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.
5.3 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.
6
Reference software
6.1 Descrizione della soluzione di partenza
Dopo lunga ricerca in rete sulla disponibilità di sistemi OSS di gestione di transazioni commerciali
ed economiche tra parti, si è identificato Cyclos [2] come potenziale punto di partenza allo scopo di
ridurre i tempi di sviluppo della soluzione medesima. Le particolarità dei requisiti del sistema di
pagamento di dmin.it sono però tali da richiedere, anche per Cyclos, una profonda revisione
architetturale per adattarlo alle specifiche esigenze di dmin.it.
Il maggiore sforzo di adattamento riguarderà il disaccoppiamento delle funzionalità applicative di
Cyclos dal corrispondente RDMS. Infatti, tutti gli Account di Cyclos sono ospitati all'interno di un
unico DB Server che gestisce in modo nativo le transazioni economiche tra i vari Account. E' quindi
evidente che per soddisfare i requisiti del sistema di pagamento di dmin.it è necessario che gli
Account interessati dalle transazioni economiche possano essere ospitati su VASP differenti, ossia
sugli RDBMS dei rispettivi VASP. In prima approssimazione sarà quindi necessario modificare
Cyclos in modo tale che sia possibile installare almeno due istanze di Cyclos, dove ogni istanza
rappresenterebbe un singolo VASP. In questo modo ogni istanza di Cyclos avrà i propri Account. Le
transazioni tra Account residenti in una istanza di Cyclos e Account residenti su un'altra istanza di
Cyclos dovranno quindi avvenire nel rispetto dei protocolli/formati di comunicazione definiti in
dmin.it, garantendo, per altro, le proprietà ACID delle transazioni medesime3. Nell'ipotesi che le
transazioni economiche, tra un Account ospitato da una istanza di Cyclos e un altro Account ospitato
da un'altra istanza di Cyclos, avvengano in tempo quasi-reale, ciò significa adottare un transaction
manager che soddisfi le proprietà ACID nel contesto delle due istanze di Cyclos come se si trattasse
di una sola istanza (two-phase commit4).
Per la reference implementation della proposta si è pensato di partire da Cyclos perché la sua
architettura applicativa e le componenti OSS utilizzate al suo interno sono lo state of the art nel
contesto delle applicazioni JEE (Java Enterprise Edition) e possono essere prese come importante
riferimento. Tuttavia non si esclude che a fronte di una più approfondita analisi di Cyclos si possa
decidere di implementare from scratch l'intera reference implementation.
L’architettura di cyclos è rappresentata nella figura sottostante.
3 http://en.wikipedia.org/wiki/ACID
4 http://en.wikipedia.org/wiki/Two_phase_commit
3. L'utente (qualsiasi ruolo applicativo) parla con Cyclos attraverso un set di funzioni applicative.
4. Ogni utente può creare ed eseguire disposizioni di incasso (i.e. richieste di pagamento),
disposizioni di pagamento (prive di una corrispondente richiesta di pagamento) e ritiro di
disposizione di incasso (ossia pagare le disposizioni di incasso ricevute da altri utenti).
5. Oltre a queste funzioni sono disponibili molte altre funzioni (e.g. gestione dei contatti, gestione
di annunci domande/offerte di prodotti&servizi, ecc.) che però non sono utili (almeno come
requisiti del sistema di pagamento di dmin.it).
6. L'utente di amministrazione gestisce il censimento di tutti gli altri utenti e dei corrispondenti
account.
Le differenze tra le ipotesi alla base di cyclos e dmin.it sono
dmin.it
cyclos
1. Esistono dei VASP che permettono agli
utenti di stabilire
Esiste un solo VASP che permette agli utenti di
stabilire uno o più Account
a. Uno o più Account presso uno o più
VASP
Esistono varie tipologie di User (Member,
Admin e Broker) e di Account associati agli
User. Gli User di tipo Member sono assimilabili
agli Account, mentre l'Admin ha funzioni di
amministrazione degli Account. Va quindi
identificato il set minimale di funzionalità di
amministrazione VASP e verificate quali di
queste trovino una corrispondenza nelle
funzionalità degli User di tipo Admin di Cyclos.
Gli User di tipo Broker rappresentano in Cyclos
degli intermediari tra i Buyers e i Suppliers.
Allo stato attuale delle specifiche dmin.it tale
ruolo non è necessario
2. Gli Account sono
a. Basati su un’unità di conto (punti) che è a.Basati su un’unità di conto (unit) che è unica
unica per tutto il sistema dmin.it ed
per tutto il sistema Cyclos
accettata da tutti i VASP
b. Dipendenti da un solo sistema di
pagamento in moneta reale (relazione
biunivoca)
b. non ci sono vincoli sul sistema di pagamento
sottostante (vedi d.). Sarà quindi necessario
introdurre la possibilità di associare ad un
Account uno ed un solo sistema di pagamento
in moneta reale. Inoltre sarà necessario
consentire la modifica di tale relazione di
associazione allo scopo di consentire all'utente
di cambiare il sistema di pagamento reale
sottostante.
c. Gestiti da applicazioni con interfacce
standard
c.Gestiti in modo omogeneo all'interno di
Cyclos. Ciò significa che aldilà di possibili
personalizzazione del look&feel delle
funzionalità applicative, sarà necessario
introdurre uno strato di disaccoppiamento che
consenta di implementare le interfacce standard.
d. Sincronizzati periodicamente o a
richiesta con dei sistemi di pagamento
in moneta reale ad incasso garantito
d.Non esiste un sistema di sincronizzazione
schedulabile, ma esiste l'interfaccia per la
conversione in moneta reale verso alcuni
sistemi tradizionali di pagamento (i.e. carta di
credito). In prima fase si ipotizza di eseguire
una sincronizzazione manuale.
e. Gerarchici, cioè possono contenere dei
Sub-Account
e.Non esiste il concetto di gerarchia dei conti,
ma solo il concetto di broker (i.e. intermediario)
tra domanda e offerta che, però non corrisponde
al requisito. La possibilità che un Account
possa creare almeno un livello di Sub-Account
va quindi implementata da zero.
f. Non gravati/beneficiati di interessi sui
punti depositati
f.Non richiede che gli account siano
gravati/beneficiati di interessi sui punti
depositati (ma non ne è esclusa la possibilità)
3. La funzione di VASP è cumulabile con altre 3. La funzione VASP è cumulata con altre
funzioni
funzioni applicative
4. Un VASP può offrire servizi senza
permettere la conversione dei punti in
moneta reale
4. Un VASP può offrire servizi senza
permettere la conversione dei punti in moneta
reale
5. Ogni utente di una Catena del Valore può, 5.Ogni utente di una Catena del Valore regola i
se la sua controparte accetta, regolare i suoi suoi pagamenti in unità di conto, ma è prevista
pagamenti in punti
anche la possibilità di convertire in moneta
reale
6. La configurazione e gestione delle
transazioni è più flessibile perché
6.La configurazione e gestione delle transazioni
è più flessibile perché
a. I punti sono convertibili in moneta reale a. Funzionalità è supportata solo manualmente e
“a tempo”
non schedulabile
b. I punti rappresentano un valore
monetario molto piccolo (e.g. 0,001 €)
con un rapporto
i. Espresso da un numero qualsiasi
ii.
b.Il sistema consente di rappresentare una
qualsiasi unità di conto coerente per l'intero
sistema
i.Espresso da un numero qualsiasi
La conversione dei punti in moneta ii. Funzionalità di conversione solo
reale reale è a tasso fisso o variabile parzialmente supportata
iii. Da identificare chi definisce il tasso NA
di conversione
iv.
Ha un valore determinato all’istante NA
t0
7. Esiste un punto di raccolta dati chiamato
Servizi Condivisi che raccoglie
a. Default degli Account holder
7.Non Esiste un punto di raccolta dati chiamato
Servizi Condivisi che raccoglie le segnalazioni
di default e le consultazioni delle segnalazioni.
Questo servizio va implementato all'esterno di
Cyclos.
a. vedi sopra
8. Ad ogni transazione fatta su una catena del 8. Può essere applicata l'IVA. Tuttavia va
valore dovrà essere applicata l’IVA (perché verificata la possibilità di assegnare tassi di
i tassi possono non essere omogenei)
IVA differenti per ogni transazione
9. Il VASP potrebbe offrire il servizio di
fatturazione ai suoi clienti business...
9. E disponibile un servizio di reportistica le cui
funzionalità sono da approfondire
10. L’intero sistema (almeno i Servizi
Condivisi) deve poter essere alimentato da
una tassa di partecipazione (e.g. prelevata
ad ogni transazione)
10. Funzionalità non implementata in Cyclos
11. Ogni utente del sistema dmin.it è
identificato dal suo codice fiscale (?)
11. Ogni utente del sistema dmin.it è
identificato dal un identificativo univoco. Va
verificato se è possibile estendere le proprietà
degli utenti per aggiungere ad ognuno di essi il
codice fiscale
12. Ogni account ha un ID univoco all'interno
dell'intero sistema e generato dai Servizi
Condivisi
12.Funzionalità non implementata
13. Unico all’interno del VASP
NA
14. Unico nel sistema dmin.it mediante
associazione all’ID del VASP
NA
6.2 Estensioni necessarie
Per poter portare Cyclos a supportare le funzionalità del sistema di pagamenti dmin.it si richiedono,
come descritto in precedenza numerose e profonde estensioni. La valutazione dell'impatto di tali
estensioni produrrà un documento di fattibilità comprensivo di un piano di lavoro. Nel caso in cui
suddetti impatti risultassero eccessivi, in alternativa si produrrà un piano di lavoro della reference
implementation realizzata from scratch. Le principali estensioni previste allo stato attuale di
conoscenza di Cyclos sono le seguenti:
1.
2.
3.
4.
5.
6.
Supporto di più di un VASP e two-phase commit tra più VASP
Distacco dei Servizi Condivisi dal VASP
Supporto di una gerarchia di account
Supporto delle strutture dati definite in questa proposta
Supporto all’IVA differenziata
Applicazioni per gestire gli account (estratto conto, aggiunta punti, sincronizzazione a
richiesta...)
7. ...
6.3 Agganci a iDRM
Come si vede dagli scenari d’uso presentati il sistema di pagamento proposto e la piattaforma iDRM
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 – anche se non esplicitamente proposti in questo
documento – 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.
7
Conformità della proposta
7.1 Conformità ai requisiti
In questa sezione si esamina la conformità della proposta con i requisiti dell’Executive Summary e
di 5.3.
7.1.1 Requisiti dell’Executive Summary
1. dmin.it cerca tecnologie e soluzioni per cui
a. Non sia necessaria una licenza per l’uso di eventuali
Diritti di Proprietà Intellettuale (IPR)
b. Se necessaria la licenza sia
i. Non onerosa oppure
ii. Ottenibile a condizioni eque, ragionevoli e non
discriminatorie (cosiddette FRAND);
2. Gli elementi di Proprietà Intellettuale necessari per la
realizzare e praticare le proposte di soluzioni o tecnologie
devono essere identificati o devono essere indicati i mezzi
mediante i quali tale informazione possa essere recuperata;
3. Non saranno considerate proposte la cui realizzazione e
pratica richieda l’uso IPR di cui non si possa ottenere
licenza ad una delle condizioni sopraelencate;
4. Deve essere rilasciata a dmin.it una realizzazione in codice
sorgente con licenza Open Source “business friendly” per
le tecnologie/soluzioni che saranno scelte.
Per la soluzione proposta
1. Non viè IPR degli autori
2. Non è noto IPR di terze parti
Vedi sopra
Vedi sopra
Vedi sopra
Vedi sopra
La proposta identifica una prima
realizzazione Open Source da cui
derivare la voluta realizzazione
secondo i criteri che dmin.it
deciderà di applicare
7.1.2 Requisiti generali
In questo paragrafo si confrontan le funzionalità della proposta con i requisiti di 5.3.1
I servizi di pagamento devono soddisfare i seguenti
requisiti:
1. Facilmente accessibili alla fascia giovane della
popolazione
a. Disponibilità di account virtuali appoggiati a
sistemi tradizionali di pagamento e/o incassi
definibili e gestibili dai legittimi intestatari
(p.e. genitori);
b. Uso di unità di valore non direttamente
monetaria (p.e. punti, credits);
c. Convertibilità in euro su base periodica dei
saldi positivi e negativi degli account
espressi in unità non monetaria sui
sottostanti sistemi di pagamento e/o incassi;
2. Senza garanzie bancarie
a. Gli eventuali insoluti al momento della
conversione dei saldi negativi da unità non
monetaria ad euro non devono richiedere
garanzie bancarie;
b. Annullabilità degli acquisti di digital media
il cui pagamento sia rimasto insoluto;
c. Disponibilità di servizi centralizzati di
Sì
Sì
Sì
La proposta ridistribuisce gli oneri derivanti
dalla conversione di un eventuale saldo
negativo comunicando il fatto ai Servizi
Condivisi
La proposta considera uno specifico scenario
d’uso in cui il requisito è soddisfatto dalla
combinazione licenza temporanea/definitiva.
La soluzione proposta lo soddisfa
Sì
segnalazione di frodi/insoluti;
3. Capace di supportare qualsivoglia modello di
business, in particolare
a. Il valore dei digital media è riconosciuto
dagli inserzionisti pubblicitari;
b. Il valore dei digital media è riconosciuto
dagli utenti;
4.
5.
6.
7.
c. Il valore dei digital media è riconosciuto con
un sistema ACS (Alternative Compensation
System);
d. Il valore dei digital media è riconosciuto
attraverso una qualsiasi modulazione dei tre
precedenti modelli di business;
Capace di supportare qualsivoglia attore di
qualsiasi catena del valore
a. Creatori/produttori
b. Intermediari
c. Utenti finali/consumatori
Adottati a livello nazionale dall'autorità pubblica
ed integrato con iDRM e con l’accesso alla ed
uso della rete a larga banda
Realizzabili ed erogabili da chiunque soddisfi i
requisiti normativi e di legge
Con possibilità da parte di chiunque di
a. Ottenere certificazione di conformità dei
servizi di pagamento
b. Erogare servizi di pagamento certificati a
La proposta presenta uno specifico scenario
d’uso in cui il requisito è soddisfatto
La proposta soddisfa il requisito perché
1. Un utente deve pagare punti per acquisire
un dato contenuto
2. Il mancato pagamento reale di un digital
media è segnalato ai Servizi Condivisi
Un sistema ACS potrebbe innestarsi sul
sistema di pagamento proposto
Sì
Sì
Sì
Sì
La proposta individua i punti di aggancio con
la piattaforma iDRM
Sì
La proposta specifica integralmente il
sistema e quindi una realizzazione può essere
sottoposta a test di conformità
Sì
terze parti.
7.1.3 Requisiti tecnici
In questo paragrafo si confrontano le funzionalità tecniche della proposta con i requisiti di 5.3.1
La soluzione e le tecnologie proposte devono
contenere:
1. La definizione e l'identificazione univoca di
tutti gli attori coinvolti nelle varie catene
del valore:
a. Persone fisiche: consumatori/utenti
Sì, sono “utenti”
finali
b. Persone giuridiche: creatori,
Sì, sono “utenti”
intermediari
c. Erogatori dei servizi di pagamento o
Sì, sono “utenti”
VASP (Virtual Account Service
Provider)
d. Erogatori di servizi comuni: servizi di
utilità comune all'intero sistema (p.e.
servizi di segnalazione di frodi ed
insoluti all'interno del sistema)
2. La definizione di virtual account
a. Ogni persona fisica/giuridica può essere
l'intestatario di uno o più virtual
account erogati da uno o più VASP
b. I virtual account si appoggiano a
sistemi tradizionali di pagamento e/o
incasso
c. Più virtual account possono appoggiarsi
allo stesso sistema di pagamento e/o
incasso di appoggio
3. La definizione delle disposizione di
pagamento e di incasso
a. Ogni virtual account può
ricevere/emettere pagamenti/incassi
destinati/provenienti da altri virtual
account
4. La specifica dei protocolli e delle strutture
dati scambiati tra gli attori del sistema di
pagamento
Sì, i Servizi Condivisi
Sì
Sì
Sì
Sì
La proposta contiene le specifiche e le
rappresentazioni XML delle strutture dati da cui i
protocolli WSDL saranno facilmente deducibili
quando si passerà alla realizzazione della
reference implementation
7.1.4 Requisiti di business
Gli autori rilasciano il contenuto di questa proposta a dmin.it perché sia usato come base per la
specifica di un sistema flessibile di pagamenti per digital media, così come dai programmi pubblicati
in [1]. Qualora invece questa proposta non fosse, neppure in parte, accettata, gli autori se ne
riservano tutti i diritti di sfruttamento.
7.2 Conformità ai criteri della richiesta
Questa proposta è stata redatta avendo a mente i criteri esplicitati nel capitolo 3 di [1]
Testo del capitolo 3 di [1]
Per essere ammissibile una proposta deve
fornire uno o più di uno dei seguenti elementi:
1. Tecnologie che soddisfino uno o più
requisiti rilevanti per l’argomento di questa
richiesta di proposte;
2. Riferimenti a standard e specifiche aperte
che siano rilevanti per la richiesta e già
pronti o prossimi al completamento;
Conformità al testo
La proposta soddisfa tutti i requisiti della
richiesta [1]
I proponenti non sono al corrente di standard e
specifiche aperte che siano rilevanti per la
richiesta [1] e per la proposta fatta
3. Commenti sulla validità dei requisiti e/o
proposta di requisiti tecnici aggiuntivi.
Inoltre una proposta dovrà contenere
obbligatoriamente:
1. Il modulo di registrazione (Allegato B)
completamente compilato e firmato, in
particolare la parte relativa agli eventuali
IPR della proposta;
2. Il modulo (Allegato C) in cui si indichino
quali requisiti sono soddisfatti e quali no.
Inoltre una proposta potrà contenere:
1. Una realizzazione (ad esempio un
dimonstratore) con una descrizione
dettagliata del sistema ed ogni altra
informazione rilevante;
2. Mezzi per verificare la conformità di una
realizzazione;
3. Ogni altra informazione aggiuntiva
considerata importante per facilitare la
valutazione della proposta
Testo del capitolo 4 di [1]
Avranno preferenza le tecnologie e le soluzioni
che:
1. Sono basate o costruite su standard o
specifiche aperte;
2. Non richiedono royalty o costi di licenza (a
parte costi di manutenzione opzionali);
3. Sono dimostrabili come effettivamente
funzionanti (ad esempio con un
dimostratore);
4. Sono scalabili in funzionalità;
5. Sfruttano concretamente comunanze e
similitudini tra i vari requisiti;
6. Forniscono una risposta coesa ed integrata
ad un gran numero di requisiti invece di
essere un coacervo di soluzioni individuali e
non integrate in risposta a requisiti
Nel capitolo 3 di questa proposta sono stati
introdotti requisiti di sistema che si ritiene
integrino positivamente quelle indicati in [1]
L’allegato B è stato debitamente compilato
L’allegato C è stato debitamente compilato
Non è offerta una realizzazione ma la proposta fa
riferimento alla soluzione cyclos che viene
proposta come punto di partenza di una
realizzazione dmin.it
I proponenti intendono lavorare con dmin.it per
sviluppare mezzi (ad esempio tramite una
“reference implementation”) che consentano di
mettere sotto test una realizzazione
La proposta è decisamente mirata ai requisiti
della richiesta di proposte [1]
Commenti al testo
I proponenti non sono al corrente di standard e
specifiche aperte che siano rilevanti per la
richiesta [1] e per la proposta fatta
I proponenti non intendono richiedere royalty o
costi di licenza e non sono al corrente di terze
part in posizione tale da fare tali richieste
Sistemi LETS sono stati sviluppati e sono
attualmente in uso. Il sistema cyclos proposto
come base di partenza per lo sviluppo di una
soluzione dmin.it è attualmente funzionante.
La proposta fatta non presuppone una specifica
implementazione. È però possibile avere
un’implementazione con caratteristiche di
scalabilità
Nella proposta le varie componenti sono
mutuamente integrate
Sì
individuali.
N.B.: Gli elementi della lista non hanno un
ordine specifico.
7.3 Conformità al contesto normativo italiano
I proponenti ritengono che la soluzione proposta sia conforme al contesto normativo italiano. È
opportuno comunque notare che alla governance del sistema di pagamenti proposto potrebbe essere
demandata la gestione di alcune specificità della proposta.
8
Bibliografia
[1] Richiesta di tecnologie e soluzioni per la realizzazione delle proposte dmin.it,
http://www.dmin.it/proposta/richiesta-tecnologie-soluzioni.doc
[3] Local Exchange Trading Systems, Wikipedia,
http://en.wikipedia.org/wiki/Local_Exchange_Trading_Systems
[2] http://project.cyclos.org/
Annex A – Modulo di registrazione
Ente/società
Contatto:
Indirizzo:
Telefono:
Fax:
Email:
Titolo della proposta:
Abstract:
CEDEO.net
dpixel
Libera Università di Lingue e Comunicazione IULM
RAI – Radiotelevisione Italiana
Sinapsi
Giacomo Cosenza
Via Bligny, 27
20136 Milano
02 582095.1
02 582095.21
[email protected]
Un sistema flessibile di micropagamenti a punti per digital
media
La proposta di sistema di micropagamenti è allineata ai requisiti
della richiesta di proposte [1] e contiene alcune specificità che la
rendono flessibile ed estendibile.
Per rendere il sistema di pagamento di più pratica realizzazione
sono state introdotte alcune ipotesi di sistema al di là di quelle
presenti nella richiesta.
È definito l’intero set di messagi che devono essere scambiati tra
gli utenti del sistema e ne è data la rappresentazione WSDL.
È anche descritto come sia possibile ricavare una realizzazione
della proposta partendo dal codice Open Source di cyclos [2]
Status dell’IPR
IP essenziale:
Non ci sono diritti di proprietà intellettuale noti
Come sopra
Tempo richiesto per la
presentazione:
Dimostrazione:
Dispositivi e altro
supporto richiesto per
eventuale demo:
30 mn.
No
No
Nome: Giacomo Cosenza
Funzione nell’azienda: Amministratore Delegato
Data: 2007/05/31
Firma:
Annex B – Modulo per copertura delle proposta
Legenda:
#
T= copertura completa
P= copertura parziale
N=non coperto
Requisiti
Tutti i requisiti sono coperti
Coperto
(T/P/N)
T
Commenti
Annex C – Glossario
Termine
Disposizione di incasso
Accettazione della disposizione di incasso
(Disposizione di pagamento)
Rifiuto della disposizione di incasso
Non risposta
Definizione
Transazione tra creditore e debitore che si realizza
in un invio di dati (da definire)
1. Dal creditore al suo VASP
2. Dal VASP del creditore al VASP del debitore
3. Dal VASP del debitore al debitore
Transazione tra debitore e creditore che si realizza
in un invio di dati (da definire)
1. Dal debitore al suo VASP
2. Dal VASP del debitore al VASP del creditore
3. Dal VASP del creditore al creditore
Come per l’accettazione ma con payload diverso
La mancata comunicazione del debitore al creditore
Annex D – Argomenti pro e contro la convertibilità fissa
La stabilità o la variabilità del tasso di conversione tra i punti del sistema di micropagamenti e la
moneta reale è uno degli elementi critici del sistema che dmin.it intende realizzare. La soluzione
proposta non dipenda dalla scelta, ma i proponenti ritengono utile fornire alcuni elementi che
dmin.it potrà decidere di utilizzare al momento della decisione.
Argumenti in favore della variabilità del tasso di conversione
1. Un tasso variabile consentirà a dmin.it di creare un mondo parallelo dove la percezione del
valore dei contenuti sarà “diverso”
2. Avere una percezione diversa è necessario se non si vuole portare nel mondo parallelo le
contraddizioni accumulate negli ultimi 10 anni di digital media nell’”altro” mondo
3. Mondi paralleli come SecondLife hanno un cambio non fisso
Argomenti in favore della fissità del tasso di conversione
1. Un tasso fisso facilita le transazioni amplificando le possibilità di scambio:
a. Aiuta i consumatori e i produttori a capire in modo chiaro rispettivamente per gli uni quanto
costa al momento dell’acquisto un bene e quanto costerà al momento del pagamento e per gli
altri quanto incassa al momento della vendita del bene in termini di punti e a quanti euro
corrispondonderanno al momento della conversione (se fosse variabile i due potrebbero non
coincidere e ciò genererebbe un “rischio di cambio”). I sistemi a tassi fissi danno maggior
certezza sulla somma da incassare/pagare e dunque generano un maggior volume di scambi;
b. Aiuta i consumatori a decidere se acquistare o meno. Libri, brani musicali, film, riviste, etc,
come tutti i “beni a contenuto informativo” sono “beni esperienza”, ovvero la cui utilità (e
qualità) non è (facilmente e/o con precisione) valutabile prima dell’uso. Tale caratteristica
risulta da una parte essere un freno all’acquisto, dall’altra abbassa la disponibilità a pagare
del consumatore (è disposto a pagare un prezzo più basso di quello che pagherebbe se
potesse conoscere la qualità del bene prima dell’acquisto). Se poi il prezzo fosse espresso
solo in dminvaluta e tutti sapessero che può variare nel tempo, sarebbe più difficile capire
qual è effettivamente il prezzo da pagare (in termini di euro), e ciò costituirebbe una ulteriore
barriera psicologica nella scelta se acquistare o meno. In generale, la possibilità di capire
semplicemente qual’è effettivamente il prezzo di un bene senza ricorrere al calcolo del
cambio, renderebbe di più semplice comprensione il mondo dmin riducendo confusione del
consumatore che si rivolge per la prima volta ad un nuovo sistema;
c. È vero che il consumatore è sempre più anche produttore (“prosumer”), ma nei mercati dei
media questi ruoli, salvo poche eccezioni, sembrano ancora nettamente distinti. Dato che il
commercio elettronico in Italia non è ancora molto diffuso, dare la possibilità a chi vende
musica on line (o libri, film, etc…) di convertire i punti guadagnati, senza oscillazioni che ne
modificano il valore reale e che dipendono dal successo del sistema dmin, per acquistare
beni e servizi nel mondo reale, amplifica le possibilità di scambio;
2. Implica la necessità di una autorità che fissi la parità all’inizio e poi ne amministri le variazioni.
Nei mercati delle valute “vere” le oscillazioni dei tassi di cambio avvengono in base
all’abbondanza / scarsità delle monete (dollaro, euro, yen, etc) nei mercati valutari. Ma se i punti
dmin non possono essere “scarsi”, l’autority che ne amministra le variazioni deve seguire certe
regole e certi interessi. Se volesse fare quelli dei venditori apprezzerebbe il cambio in periodi di
maggior crescita dei volumi e lo ridurrebbe in caso di crisi. Per i compratori questo però non è
positivo, anche perchè capiscono che questo apprezzamento del cambio non è giustificato da un
aumento dei costi di produzione o vendita. In alternativa l’authority potrebbe avere una
composizione mista: venditori e consumatori, ma ciò implicherebbe l’esistenza di forze
sistematicamente contrapposte e conflittuali, ma occorre che tutti si fidino del sistema che fissa
la parità;
3. Espone il sistema alla possibilità di attacchi speculativi sul cambio. Più un sistema è piccolo e
più è soggetto a possibili attacchi speculativi da parte di chi (venditore dmin) dopo avere
accumulato molti punti in dmin valuta cerca di forzare il cambio in suo favore appena prima di
riscuotere.
Per queste argomentazioni un tasso fisso sembra una scelta più prudente in termini di sicurezza della
transazione sia per i consumatori che per i produttori. Ciò aumenterebbe anche la comprensione del
mondo dmin e quindi la diffusione e l’uso.