ID "theft" -- so what?

[Jerrold Leichter]

| 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