Governance of anonymous financial services

[Anne & Lynn Wheeler]

Ian G wrote:
> E.g., Ricardian contracts (my stuff) take the user agreement as a 
> document and bind it into each transaction by means of the hash of the 
> contract;  they also ensure various other benefits such as the contract 
> being available and readable to all at all times, and the acceptability 
> of same, by the simple expedient of coding the decimalisation into the 
> contract.  Ensuring that the contract is readable, applicable and is 
> available to all is a huge win in any court case.
> 
> Other governance tricks:  the usage of signed receipts can be used to 
> construct a full audit of the digital system. Also, signed receipts are 
> strong evidence of a transaction, which leads by some logic to a new 
> regime which we call triple entry accounting.  This dramatically changes 
> the practice of accounting (which feeds into governance).
> 
> With DB side, one trick is to use psuedonym accounts for the basis, and 
> this allows no-loss protocols to be created. Again, this is useful for 
> governance, because if you have a lossy protocol, you have a potential 
> for fraud.

we had done something analogous in the x9.59 financial standard. the x9a10
financial standard group had been given the requirement to preserve the
financial infrastructure for all retail payments. 
http://www.garlic.com/~lynn/x959.html#x959

digital signature on the transaction itself provided for end-to-end
strong authentication (armoring payment transaction as countermeasure
to various kinds of replay attacks ... as have been in the news recently
related to large data breaches and then being able to subsequently
use the information for fraudulent transactions).

one of the "problems" was that some of the other attempts at PKI-related
payments protocols in that period ... were creating enormous 
(two orders of magnitude) processing and  payload bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat

one of the implied x9a10 requirements was efficiency, i.e. mechanism that could be
deployed in ALL environments (internet, point-of-sale, cellphone, etc) ...
and needed to be highly concerned about processing and payload efficiency.

the actual transaction is digitally signed ... and it is also the thing that
is authorized, logged, archived, audited, etc.

so part of x9.59 provided for a hash of the  receipt (contract,  bill-of-materials, 
sku data, "level 3" data, etc) as part of the digitally signed payload
(as opposed to including the whole receipt). Then in any subsequent dispute,
if both parties didn't produce identical receipts ... the hash from the
audited/logged/archived transaction could be used to determine the
valid/correct receipt.

While the receipt wasn't part of the actual audited/archived/logged transaction,
the process provided a mechanism (in cases of disputes) for establishing the
legitimate receipt.

we claimed privacy agnostic for x9.59 ... i.e. there was an account number in
protocol but the degree that any jurisdiction required a binding between an 
account number and an individual was outside the x9.59 protocol. x9.59 was
designed so that it could be used for credit, debit, stored value, ach, etc.
In many jurisdictions, credit & debit can have some "know you customer"
requirements for financial institutions (binding between individuals
and account numbers) ... however there was 1) no requirement to divulge
such bindings during retail transactions and 2) x9.59 applies equally
well to stored-value retail transactions (where there is much less
frequently a requirement imposed for "know your customer".

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com