Btw. There are credit card issuers (AT&T Universal is one) that permits you to create a virtual one-time use credit card (with a time limit and $$ limit if you want).
So when I shop at a merchant I don't want to trust, I open another browser window and go to my issuers website and obtain a one-time card number and use it at the merchant site. I can usually see immediately after the purchase that the card has been used (on the issuers website) so I know the merchant is checking the card in real time. Apparently there is wallet software that will do this in a more automated fashion, but it isn't available for my platform (non-Windows). Jerrold Leichter wrote: >| Date: Wed, 13 Jul 2005 16:08:20 -0400 >| From: John Denker <[EMAIL PROTECTED]> >| To: Perry E. Metzger <[EMAIL PROTECTED]> >| Cc: cryptography@metzdowd.com >| Subject: Re: ID "theft" -- so what? >| ... >| Scenario: I'm shopping online. Using browser window #1, I >| have found a merchant who sells what I want. in the checkout >| phase. >| >| Now, in browser window #2, I open a secure connection to my >| bank. The bank and I authenticate each other. (This is >| two-way authentication; one possible method is SSL certificate >| on the bank's part, and a password or some such on my part.) >| >| ... >| As a refinement, I could ask the bank to issue a number that >| was not only restricted to a single use, but also restricted >| as to dollar amount. As a further refinement, it could be >| restricted to a particular merchant. >| >| Everything to this point is upward-compatible with existing >| systems. The merchant doesn't even need to know there's >| anything special about this card number; the charge moves >| through existing processing channels just like any other. >| >| As a further refinement, once the system is established, >| the merchant could provide, on the checkout page, a number >| that encodes in some standard format various details of >| the transaction: merchant ID, date, dollar amount, and >| maybe even a description of the goods sold. I cut-and-paste >| this code from the merchant to the bank, and let the bank >| site decode it. If it looks correct, I click OK and then >| the bank generates a response that the merchant will >| accept in payment. If necessary I can cut-and-paste this >| from the bank to the merchant ... but it would make more >| sense for the bank to transmit it directly to the merchant. >| This further increases security, and also saves me from >| having to enter a lot of billing detail.... >In effect, what you've done is proposed a digital model of *checks* to >replace the digital model of *credit cards* that has been popular so far. >In the old days, paper checks were considered hard to forge and you were >supposed to keep yours from being stolen. Your physical signature on the >check was considered hard to forge. Checks were constructed in a way >that made made alteration difficult, binding the details of the transaction >(the payee, the amount being paid) and the signature to the physical >instrument. > >There was a time when checks were accepted pretty freely, though often with >some additional identification to show that you really were the person whose >name was on the check. > >Credit cards and credit card transactions never bound these various features >of the transaction nearly as tightly. Stepping back and looking at the >two systems, it seems that using the check model as the starting point for >a digital payment system may well be better than using credit cards, whose >security model was never really as well developed. When I handed a check to >a vendor, I had (and to this day have) excellent assurance that he could >not change the amount, and (in the old days) reasonable assurance that he >could not create another check against my account. (Given digital scanners >on the one hand, and the "virtualization" of the check infrastructure, from >the ability to initiate checking transactions entirely over the phone to >check truncation at the merchant on the other, this is long gone. It would be >nice to recover it.) > -- Jerry > >--------------------------------------------------------------------- >The Cryptography Mailing List >Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > > > -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice [EMAIL PROTECTED] ============================================================================
signature.asc
Description: OpenPGP digital signature