Charles M. Hannum wrote: > As long as the "credit card" has no display, you're still trusting the > terminal to give the purchaser correct information. If you're using a smart > "credit card" that participates directly in the transaction, storing > transaction data, signed by the processor's system, on the card would be > useful for repudiation. You could even have a way of downloading the data > directly into Quicken and using it to check invoices automatically.
absolutely ... see comment at end of early post in this thread about paranoid consumers ... http://www.garlic.com/~lynn/aadsm19.htm#38 as part of the charge to x9a10 financial standards working group to preserve the integrity of the financial infrastructure for all retail payments (aka debit, credit, ach, stored-value, etc as well as internet, pos, face-to-face, moto, etc) ... there were some other provisions in x9.59 payment standard http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy for use with private PC-based internet transactions and/or enhanced personal point-of-sale device (cellphone, pda, etc). there is a data field defined in the x9.59 that was specifically put in place for use as personal transaction number (or a virtual check number if you are so disposed). it was specifically designed for supporting electronic reconciliation between transactions and various possible electronic statements. in the mapping from x9.59 to iso 8583 payment transaction description http://www.garlic.com/~lynn/8583flow.htm it is referred to as a LUID (costomer/locally unique number) ... although there is not actual requirement for it to be unique and/or even anything other than NULL. the standard suggests that if the LUID field is present as part of an x9.59 transaction, that the institution should include it any statements provided the customer (analogous to the way that check numbers are provided on statements). X9.59 also provides for an optional field for hash of order detail. basically what the user signs, can include the hash of the invoice/order. the merchant then is to validate that any (non-null) invoice/order hash included in the signed x9.59 message corresponds to hash of their invoice/order ... if the two hashes don't match ... don't submit the transaction for payment. If the merchant disputes the invoice/order later ... and the user happens to have included the hash of invoice/order in the payment transaction ... then the disputed invoice/order submitted by the merchant better have a hash that matches what is in the signed payment transaction. this avoids requiring that the invoice/order has to be part of the payment transaction ... but leaves around some amount of detail that can be used as supporting evidence in the event of any dispuate. there is a EU FINREAD standard for a personal financial termainal that talks about countermeasures for things like keylogging and making sure the value of the transaction is correctly displayed http://www.garlic.com/~lynn/subpubkey.html#finread from the x9.59 perspective, there was a lot of work on allowing that such a terminal could co-sign the transaction ... providing the financial institution some risk indication about the person authenticating the transaction as well as risk indication about the environment in which the transaction occured (aka EU FINREAD specified requirements for the personal financial termainal ... but didn't actually require proof that such a terminal was actually used). some of the characteristics of the EU FINREAD terminal are similar to the security module requirements for POS terminals. The issue is that both the users as well as the financial institutions may have no indication that a POS terminal with specific integrity level was in use for any specific transaction (making it difficult to fully do parameterized risk management ... i.e. calculate all the possible fraud and risk factors on a transaction by transaction basis). the identified issue leading up to the privatly owned display and keypad at POS ... is that even if there was a tamper resitent security module in a tamper resistent post-of-sale terminal ... that also co-signed the transaction ... there is still POS vulerability with things like overlays (i.e. a compromised MITM display/keypad sitting between the user and the real POS secure terminal). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]