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...


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 ... 
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 
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 
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 
specified fields.

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 
doing similar
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 requirements).

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 
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

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" 
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 
for comments/testing

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to