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
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...
I'm integrating (or should be) the work that Todd Boyle has done on
accounting, because his concept is more rather than less analogous.
http://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial
so applying x9.59
mapping to iso 8583 (i.e. credit transactions, debit transactions ... and even
number of stored-value transactions carried by some point-of-sale terminal and
... at least part of the financial network)
you have the standard iso8583 financial transactions with a x9.59 addenda ...
a digital signature, a hash of the receipt and some misc. other stuff.
existing infrastructure advises that both merchant and consumer retain (paper)
case of disputes). x9.59 financial standard didn't specify/mandate how that
done ... but provided for support for applications for doing.
the financial transaction was already required to be archived/logged for all
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
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
considerations as part of x9.59 standard (including countermeasures to
from breaches), it had to be extremely lightweight because of numerous
you are asked to consider ALL retail transactions (including looking forward to
ontactless, wireless, cellphones, transit turnstyles, etc), and maximizing the
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
is being logged ... including the receipt hash and the additional x9.59
the "receipt", that is hashed, isn't specified as part of the x9.59 protocol
... 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
or related efforts ... essentially viewed it as profit opportunities. the x9a10
worked view all the "stuff" as added expense ... to be aggressively eliminated
as much as
possible. For instance in the AADS chip strawman
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
to compound the problem ... we also did a bit of work on being able to change
institutional-centric "something you have" authentication paradigm to a
paradigm ... i.e. rather than having one "something" per institution ... you
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).
posts mentioning 3-factor authentication paradigm
so having something that was aggressively cost reduced by 2-3 orders of
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
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"
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
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
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]