Jeffrey I. Schiller wrote: > 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).
an analogy i've used recently with respect to userid/password paradigm, is that account numbers are being concurrently used for both the userid function (requiring security *integrity* but not security *confidentiality*) as well as the password function (requiring strong security *confidentiality*). as a result there are frequently diametrically opposing requirements where the muiltitude of userid-type business functions require access to the account number ... at the same time, the password-type functions require that the account number be kept strictly *confidential* and not be available at all. the x9a10 working group was given the requirement to preserve the integrity of the financail infrastructure for all retail payments. the resulting x9.59 protocol http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#x959 * allowed for single round-trip, straight-through processing found at many point-of-sale ... w/o requiring extraneous protocol chatter * created a strictly enformed separation of the account number as a userid-type function from digital signature as a password-type function this eliminated the strongly conflicting goals of very weak *confidentiality* requirement for use of the account number in the multitude of userid-type business processes at the same time having a very strong *confidentiality* erquirement for the same account number in its role as passoword/authentication. this had the downside that there was potentially a maximum of two PANs allocated for the same account during some transition period (where both legacy, conflicting use of an account number was required and the new x9.59 use of an account number requiring separate authentication). it was startling that some of the strongest foes of x9.59 claiming that there wasn't large enuf PAN space available to have a maximum of two PANs per account (during some transition periods) ... subsequently were strong backers of one-time-use PANs ... which might result in potentially hundreds of PANs being mapped to the same account. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]