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
