ID "theft" -- so what?

[Jeffrey I. Schiller]

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 <jsd at av8n.com>
>| To: Perry E. Metzger <perry at piermont.com>
>| Cc: cryptography at 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 majordomo at metzdowd.com
>
>  
>

-- 
=============================================================================
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
jis at mit.edu
============================================================================

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20050720/51ed12d2/attachment.pgp>