[17956] in cryptography@c2.net mail archive
Re: ID "theft" -- so what?
daemon@ATHENA.MIT.EDU (Jeffrey I. Schiller)
Thu Jul 21 10:40:44 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Wed, 20 Jul 2005 23:52:19 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Jerrold Leichter <jerrold.leichter@smarts.com>
Cc: John Denker <jsd@av8n.com>,
"Perry E. Metzger" <perry@piermont.com>, cryptography@metzdowd.com
In-Reply-To: <Pine.SOL.4.61.0507141853500.26629@frame>
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigAD77DD309A9BF7E58BA8DABE
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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@av8n.com>
>| To: Perry E. Metzger <perry@piermont.com>
>| 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 majordomo@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@mit.edu
============================================================================
--------------enigAD77DD309A9BF7E58BA8DABE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC3xvz8CBzV/QUlSsRAkRzAJ9J5FnLCJiwVZRMwKV5Xhg0Go8QswCgsLHa
efIKBUXcn13LyF7UNUOtj9g=
=sMq7
-----END PGP SIGNATURE-----
--------------enigAD77DD309A9BF7E58BA8DABE--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
