Governance of anonymous financial services

Tue Apr 3 14:52:21 EDT 2007

Ian G wrote:
> OK, on the face of it, you seem to have been doing triple entry (with 
> the twist of a hash).  Actually I am not so sure that it is even twisted 
> ... as you are simply saying that someone somewhere was logging the 
> hash;  but not who was storing the receipts.
> 
> To point:  is this written up anywhere?  <gollum>  did I really ask 
> that? ;)
> 
> I wrote this concept up in a paper and am very happy to expand to 
> include other art and implementations, given more than copious free time...
> 
> http://iang.org/papers/triple_entry.html
> 
> I'm integrating (or should be) the work that Todd Boyle has done on 
> accounting, because his concept is more rather than less analogous.

re:
http://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services

so applying x9.59
http://www.garlic.com/~lynn/x959.html#x959

mapping to iso 8583 (i.e. credit transactions, debit transactions ... and even some
number of stored-value transactions carried by some point-of-sale terminal and
... at least part of the financial network)
http://www.garlic.com/~lynn.8583flow.htm

you have the standard iso8583 financial transactions with a x9.59 addenda ... that includes
a digital signature, a hash of the receipt and some misc. other stuff.

existing infrastructure advises that both merchant and consumer retain (paper) receipts (in
case of disputes). x9.59 financial standard didn't specify/mandate how that might be
done ... but provided for support for applications for doing.

the financial transaction was already required to be archived/logged for all sorts of
regulations and business processes (as evidence some number of recent breach references). 

In the mid-90s, the x9a10 financial standard working group had been given the requirement
to preserve the integrity of the financial infrastructure for ALL retail payments. In numerous
other references I've mentioned that doing required taking into account all sorts of
considerations as part of x9.59 standard (including countermeasures to fraudulent transactions
from breaches), it had to be extremely lightweight because of numerous considerations when
you are asked to consider ALL retail transactions (including looking forward to various c
ontactless, wireless, cellphones, transit turnstyles, etc), and maximizing the optimal
use of all the existing processes and flows.

In any case, as a result, the "x9.59" transaction would be logged/archived as part of existing standard financial transaction processes ... which includes the digital signature against the
full transaction ... where the full transaction ... along with the digital signature
is being logged ... including the receipt hash and the additional x9.59 specified fields.

the "receipt", that is hashed, isn't specified as part of the x9.59 protocol standard
... but is assumed to be whatever is necessary to support resolution, in case of any 
dispute (at least the equivalent of saying that both the merchant and consumer retained
paper receipt copies in the case of dispute).

we actually may have done too good a job. a lot of efforts that have worked on doing similar
or related efforts ... essentially viewed it as profit opportunities. the x9a10 standards
worked view all the "stuff" as added expense ... to be aggressively eliminated as much as
possible. For instance in the AADS chip strawman
http://www.garlic.com/~lynn/x959.html#aads

in the mid-90s, i would semi-facetiously say that we would take a $500 mil-spec part, 
aggressively cost reduce it by 2-3 orders of magnitude, increase its security/integrity,
have it form-factor agnostic (as well as being able to meet contactless transit turnstyle 
requirements).

to compound the problem ... we also did a bit of work on being able to change the
institutional-centric "something you have" authentication paradigm to a person-centric
paradigm ... i.e. rather than having one "something" per institution ... you could have
one (or a very few) "somethings" per person (could be viewed as creating the "something you are"
biometric authentication analogy for "something you have" authentication). misc. past
posts mentioning 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

so having something that was aggressively cost reduced by 2-3 orders of magnitude, more
secure ... and instead of having one per institution/environment (that a person was 
involved with), they would have only one (or a very few). overall this could have represented
possibly four orders of magnitude cost reduction (that many others were viewing as potential
profit opportunity).

in any case, who would be the stack-holders interested in something that eliminates nearly all
fraud and nearly all costs?

a few past posts mentioning working on change-over to a "person-centric" paradigm:
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
http://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
http://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
http://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing

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