Find file
79b6c56 Dec 15, 2013
255 lines (187 sloc) 7.48 KB
Network Working Group J.J. Brucker
Request for Comments: Open-UDC Team
==== OpenUDC Exchange Formats ====
=== Abstract ===
=== Status of This Memo ===
(Today 1st december 2011, it is still a draft).
=== Copyright Notice ===
=== Table of Contents ===
1. Introduction ....................................................
2. Conventions Used in This Document ...............................
3. Validation Nodes act as HTTP Servers ..........................
4. Tree Structure of Validation Nodes ............................
5. Data expected in the tree structure .............................
5.1 Formats used for parameters update
5.2 Formats used for transactions
5.3 Propagation mechanism
5.4 MIME types (a priori deprecated)
1.== Introduction ==
The OpenUDC project aims to provide a open, democratic and secure
monetary system, compatible with universal dividend.
This document describe the MIME-types used in to described the
different datas which need are exchanged in OpenUDC implementations.
Only the Content-Type field is used, which permit more flexible uses:
It make it compatible with almost all multipart media type as defined
in section 5.1 of [RFC2046].
But
OpenPGP standard [RFC4880].
2.== Conventions Used in This Document ==
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3.== Validation Nodes Overview ==
Validation Nodes, act as HTTP Servers.
There in no restriction on the port number to reach a Validation
Deamon, although port 11371 or 80 are recommanded.
Validation Nodes MUST manage "GET" and "POST" word as specified by
the protocol HTTP/1.0.
Validation Nodes SHOULD manage "HEAD" word and "Range" parameter, as
specified by the protocol HTTP/1.1, cf. [rfc2616].
Validation Nodes MUST manage the MIME types defined in this document
(cf sections ..) and send them in the "Content-Type" parameter.
4.== Tree Structure of Validation Nodes
As each Nodes act as an HTTP server, Node Ressources MUST be
available trough such kind of URL :
* http://NodeHostame[:port]/...
or
* https://NodeIP[:port]/...
or
* httpgp://NodeIP[:port]/...
A node MUST provide determined ressources at determined
location.
Here is an OverView of such tree structure :
http[s]://Node[:port]/...
|-- pks/
| |-- add
| `-- lookup
|-- udc/
| |-- update
| |-- validate
| |-- log
| |-- log.1
| |-- log...
| `-- [currency_code]/
| |-- keys
| |-- synthesis
| |-- databases/
| | `-- [PARAMETERS_NUM]/
| | |-- 1.bdb
| | |-- ...
| | |-- 1024.bdb
| | `-- ...
| |-- params/
| | |-- synthesis
| | `-- [PARAMETERS_NUM]/
| | |-- [PARAMETERS_NUM].sheet
| | |-- [PARAMETERS_NUM].fprs
| | `-- [PARAMETERS_NUM]_[FPR].sig
| |-- peer/
| | |-- self
| | |-- register
| | `-- list
| `-- transactions/
| |-- 20D11AC53DAE0E19DFEEE14657A135297E9DF1BF/
| |-- 1B0C7D91A7A1A833C32D4E156AEEFE2C96193F28/
| | |-- 1.gpg
| | |-- ...
| | `-- 3.gpg
| `-- 5FDA8373344F3868D24D8ED280B1DF4F7FE6695D/
| `-- 1.gpg
`-- udid2/
|-- geolist_FRA.txt.asc
|-- geolist_ITA.txt.asc
|(...)
`-- index.html
5.== Data expected in the tree structure ==
OpenUDC application use the Content-Type "multipart/msigned",
specified in the "HTTP OpenPGP Authentication" draft, to exchange
signed data.
5.1= Formats used for parameters update =
The "udc/update" url is used to POST parameters update with at
least the minimum number of required signatures. Signatures MUST by
done by differents keys known in the previous parameters.
POST data MUST have the content-type multipart/msigned, as described
in [...].
After being validated by a node, the parameters update is propagated
through other nodes. This is done in 2 steps :
- The node signs also the parameters update and add its signature to
the POST data.
- Then it propagate it using the mechanism described above.
There are 5 levels of fingerprints_status :
* 0 - UNKNOWN (Reserved for eventual futur use)
* 1 - DELETE (Reserved for eventual futur use)
* 2 - REJECTED (Reserved for eventual futur use)
* 3 - ACTIVE (accepted in previous parameters and not revoked or rejected since)
* 4 - ALIVE (will receive a part of the new currency units)
* 5 - VOTER (ALIVE and which may vote for next one)
[VERSION_FORMAT]
[SETNUM]
[CURRENCY CODE]
[FACTORS]
[ Total NUMBERS of FPR by STATUS (since the first parameters update)]
[MINIMAL NUMBER OF ADMIN's SIGNATURES for next parameters update]
[list of new FINGERPRINTS or which status have change STATUS number]
Example:
42
1
uni
2 1 3 0 1 3 0 1 3 2 0 1
0 0 0 16 15 5
3
FD289C703E2E54C8BBED7CD08BAA38841BA5F17B:4
05AA4007A3428EBE6BF3B751D403380F6656CBEC:4
6089A78D77BC6C7A1A2EC7F097E9443A0AA85FA4:3
20D11AC53DAE0E19DFEEE1465D2662E0F300EBAD:5
AB49FC7C3EC6D4A2259B0508FB29CDDA17A7E2AE:4
5FDA8373344F3868D24D8ED280B1DF4F7FE6695D:5
18F938BD3BBBF9190B77EABB57A135297E9DF1BF:5
5.2= Formats used for transactions =
application/udc-t-cheque ("cheque")
_VERSION_FORMAT_
si _VERSION_FORMAT_ == "d=tt2"
_CURRENCY_NAME_
_FINGERPRINT_SOURCE_
_FINGERPRINT_DESTINATION_
_BINARY_VALUE (POWER ?)_-_CREATION_SHEET_ID_-_JOB_ID_+_EXCHANGE_COUNTER_ _FINGERPRINT_PREVIOUS_OWNER_ _BINARY_VALUE (POWER ?)_-_CREATION_SHEET_ID_-_JOB_ID_ _EXCHANGE_COUNTER_
...
Example:
d=tt2
test2
20D11AC53DAE0E19DFEEE1465D2662E0F300EBAD
5FDA8373344F3868D24D8ED280B1DF4F7FE6695D
4-3-1 1
32-2-8 2 D8ED280B1DF4F7FE669520D11AC53DAE0E19DFE 4-1-2 3
64-2-0 1
5.3= Propagation mechanism =
This section describe how POST data which have to be spread
immediately in the network are propagated to other nodes.
This concern especially "udc/create", "udc/validate" and
"udc/peer/register" url interfaces.
This mechanism required that each nodes know accurately the (same)
pool of other nodes.
The pool synchronization is also done when using "udc/peer/register"
url interface (so almost "recursively").
Each node MUST declare and use the same peer list. The list is
sorted by alphabetical order of the node's OpenPGP fingerprint.
(It may change in the futur by considering the node's network
topology to reduce the time of propagation - TODO. )
Propagation is done using specific parameters in the query string.
example:
POST "udc/create?pdeep=2&porigin=27DF2AB5CA52B6D7A5A61974009AE2968C8F5FDA
5.4= MIME types (a priori deprecated) =
cf: [RFC2046] : http://www.bortzmeyer.org/2046.html
[RFC3156] : http://www.ietf.org/rfc/rfc3156.txt
MIME types used by OpenUDC Nodes and Clients
text/udc-report
contain status code of the transaction, and a status string.
application/pgp-signature ("receipt of the cheque")
contain detached signature (ASCII-armored or not) of the application/udc-t-cheque content by the receipt.
application/udc-t-validation
contain detached signature (ASCII-armored or not), signed by a validation node of :
the application/udc-t-cheque content
and the status code of the transaction.
application/pgp-signature ("vote of the creation sheet")
application/pgp-keys
MIME types for other applications (like mail client) :
application/udc-transaction
application/udc-update