ID "theft" -- so what?

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com