Usecases: how someone registers and issues money (that is convertible to what WE accept)
GnuPG manual
User-ID to identify your key; typically:"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Note: Typically, the key together with the user ID is signed when assigning trust. But signing the key only is also possible according to the standard.
Miért nem elég, ha az illető adóazonosítója (mondjuk HU prefixszel) a UID comment részébe van írva?
az én UID-om lehetne: "Pityi Palkó (country.HU.8403513018) <blabla@blabla.org>"
Erre lehet keresni, és alá lehet írni.
Azért gondoltuk, hogy country.HU.hash(adoazonosító), hogy az adóazonosító ne legyen benne közvetlenül. Sokan feleslegesen aggályoskodnának.
I want to compile an exact series of gpg commands that leads to /updateAI - Both for the users and the notaries:
- user a creates keypairs
- master key and key for everyday use
- gpg --edit-key ... taxidsha1=hash(HU<personaltaxnr>)
- where HU is the countrycode
- gpg --edit-key ... issuelimit/LETSxxxx=789123
- so any LETS can see the issuing-limit of a user in other LETS groups as well (but not the actually issued amount, and not the acquired amount either). This way by growing the network the risks don't grow, but decay.
- splits the keys and deposits the parts at private friends key for recovery after any key-losing accidents
- without this step, by losing the wallet key the positive part of the wallet (!!!) is also lost. Blame yourself if that happens to you
- injects key into the keyserver network
- user gets notaries and other users examine his certificate (eg. some letter from tax authority that includes his personaltaxnr) and sign his key
- notary of LETSxxxx authorizes issuing limit for LETSxxxx by signing /updateAI max(agreed limit, issuelimit/LETSxxxx)
- user signs /emit (likely his wallet automatically does this when necessary), so he can issue whenever necessary, and converts to any other currency / voucher when needed, using the DigitalMarket
That's the base technology for the thousand-year problem. Edit for completeness !
Resolving duplicates
- What happens if someone tries to create 2 pseudonyms with the same hash(HU<personaltaxnr>) ?
- If one key is withdrawn, and points to the new key, that should not be a big problem
- Otherwise if enough trust accumulates certifying one of the keys, the other keys with same hash(HU<personaltaxnr>) can be safely neglected as offending/fake key. And anyone certifying the fake key should be "stamped"
- ...
- Alice is member of LETS_A
- Bob is member of LETS_B and LETS_L
- issuer_A, issuer_B and issuer_L is the issuer server of LETS_A, LETS_B and LETS_L respectively
- issuer_conn is a special issuer server of connectivity tokens
- market_conn is a DigitalMarket that helps participants trade / convert using tokens of any technically compatible issuer - to help convertibility of LETS currencies
- Transactional load of issuer_conn depends on the implementation of market_conn. Having 1 issuer_conn transaction for each market transaction would be a bit prohibitive (assuming multiple markets, with several millions / day total transactions, appr one for each inter-LETS transfer)
- original plan: the currency of a huge market with tens of thousands of people. A LETS or a small group of LETS systems can choose to not join this huge market, but have their issuer dedicated to issue their connectivity tokens. Convertibility requires that
- the DigitalMarket is mature enough to "route" sanely between these currencies. (probably through the currencies of the biggest markets.
- each such group sets up market rules to convert to/from all other trusted groups. Preferrably all other currencies ! But, in case of concerns they will choose to not trust some (eg. overissued) currencies. The hard part is that these market rules should be kept uptodate when currencies change. New market rules should be added as new currencies show up. A currency administrator can think this way: partition currencies like "trusted" (with conditions), "not trusted" and "requires judgement" (eg. a currency that was trusted earlier but issued amount grew as people joined).
- issuer_limit is a special issuer that participants use to self-limit their issued tokens while participating in more than one LETS groups.
- the transactional load of issuer_limit is very small - even if 1 million participants join per month. Appr 2-4 transactions each time a participant joins a LETS or leaves a LETS. Leaving a LETS means giving up the opportunity to issue in the future. By contract, any earlier issued amount MUST be redeemed before leaving a LETS (of course). On the other hand, anyone can have positive balance (even anonymously) without LETS membership. In other words anyone can give real value to one or more LETS members if they accept it.
Process for Alice:
- Alice uses a program (application, applet, gpg or other) to generate a PKI keypair
- Alice meets a notary. Notary signs Alice's pubkey perhaps with gpg --sign-key (and/or fills in a template document and signs it, see tech-details below). We call this "Auth_Alice document". The document contains
- (cryptographic hash of) scanned photo ID
- (cryptographic hash of) scanned IRS-card or a snailmail from IRS which contains IRS-ID (APEH adóazonosító jel in HU, like 8366260267)
- notary stores the original documents in a safe digital private repository. Without putting documents to wide-open public, other notaries will verify some data arbitrarily (requested file must be shown; examine file content and verify file hash matches the advertised value - not tampered)
- Alice, (using Auth_Alice document) issues 50 korona via issuer_conn
- Alice, (using Auth_Alice document) issues 300 korona via issuer_limit
- Alice, using Auth_Alice document and the trading previously issued 50+300 korona issues 3500 kWh (==350 korona) currency at issuer_A (we assume that LETS_A nominates their currency in kWh, and the group decided that at the time of Alice joins 10kWh = 1 korona)
Process for Bob:
- ...
- very same process, including the notary step: results in Auth_Bob document
- Bob, (using Auth_Bob document) issues 50 korona via issuer_conn
- Bob, (using Auth_Bob document) issues 700 korona via issuer_limit
- Bob, using Auth_Bob document and trading the previously issued 25+300 korona issues 3250 kWh (==325 korona) currency at issuer_A
- Bob, using Auth_Bob document and trading the previously issued 25+400 korona issues 425 korona currency at issuer_B
-
Trading
- for Alice and Bob no LETS group exists they are both member of.
- Had such LETS_x existed, they could directly settle via issuer_x
- They can trade via markets, such as market_conn
- both LETS_A and LETS_B have set up account on market_conn, using issuer_conn tokens to make their (LETS_A / issuer_A and LETS_B / issuer_B) tokens convertible
Signature technical details
- either the notary signs a (filled) template which has the member's pubkey and several other data (mostly hash of separately stored scanned documents)
- or the notary should make 2 signatures somehow ? Or sign the member's pubkey and attach the signed template ?
Signatures on the key are more robust than templates. Statements about the owner of a key are best attached to the key itself by the mechanism defined in RFC4880
We should definitely provide gpg commandline examples to show what's happening (even if most notaries will use net/sourceforge/epoint/swing/SignerApplet.java or similar during everyday actions )
gpg --sign-key
- There are some other options such as --ask-cert-level and --ask-cert-expire that might be useful
- Also, one can use --cert-notation to add pieces of information to the signature.
- (unsigned but filled) template ?
- since templates are typically just glorified key-value pairs, one can use notations like that as well.
- perhaps issuelimit_A=500000 (which is 500.000 korona for LETS_A). Without this key-value pair the configured default limit applies.
Cell suggests a generic condition to allow issueing could be configurable in the issuer server like:
- ACTION=addtoset(key, members)
- CONDITION=signed( key, notaryA) && signed( key, memberB) && different(notaryA, memberB) && is_element_of( memberB, members) && is_element_of( noraryA, notaries)
This involves 1 action (with 1 SQL table containing sets: varchar memberID, varchar setID) and 3 simple (2-input binary output) functions:
- signed()
- is_element_of()
- different()
Reverse polish notation could makes the code easier, simpler (and depend on fewer libraries).
But... we agreed earlier on sg. simpler - good enough for now:
- issuer only verifies that signed( key, notaryA) && is_element_of( notaryA, notaries)
- where notaries can be an SQL table in server database.
- Janis says: It is almost done. Needs some finishing touches and testing. The number of notaries required to enroll a new AI is configurable or unset (which disables this feature).
