sporadic problem is confusing authentication and identification. there are
various gov. requirements that may require identification as part of
account establishment but that shouldn't translate into requirement for
identification for every transaction related to such account. transactions
(like payments) have requirements where authentication should be sufficient
w/o involving identification and all the privacy problems that creates.
note that many of the existing payment cards are subject to transaction
skimming and subsequently using the information to create counterfeit
cards.... even the EMV "yes cards" that have been cited in various press on
the other side of the atlantic pond.
there can be a number of issues with using a single hardware token for both
payment and non-payment purposes with detrimental information leagage
between the two domains. primarily the problems involve when the design of
the infrastructure involves static data (of the kind that is subject to
skimming with the possibility of later using the skimmed information for
subsequent fraudulent purposes). However, it is possible to design an
infrastructure that doesn't involve the kind of static information that can
be subject to skimming and fraudulent use.
One such solution is to design an infrastructure around secure
authentication as a business process .... regardless of the type of
business process (payment, non-payment, etc). An addition objective might
be to avoid shared-secrets (where elementary security principles require
unique shared-secret for every distinct security domain). A shared-secret
could be PINs, passowords, or even physical keys (aka you typically don't
have a house key also being used for entry to an employer's business
location) ... aka a single, shared-secret based device that was used in
multiple different security domains is subject to possibility of
information leakage that could be used by one domain to compromise a
different domain.
misc. past posts discussing confusing authentication and identification
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and
Identiification?
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing
Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing
Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing
Authentication and Identification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process,
payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process,
payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process,
payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#4 Confusing business process,
payment, authentication and identification
http://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has
conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative
view
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of
postings
[EMAIL PROTECTED] on 3/15/2004 1:39 am wrote:
Lynn,
You are right but the financial institutions now try to leverage
their position as trusted third parties for things outside of
their payment territory. It is hard to see that e-governments
can be realized without a generic ID without huge costs
and user inconvenience. As I have said numerous times
before in this list:
ID <> Payments
But I would also like to mention my addendum
ID >> Payments
That is, a functional ID can in an on-line world replace the need
for most other resources as you by using an ID towards resource
providers "can be whatever you need to be, or have what you
need to have".
To combine ID and Payment cards though opens a can of worms.
If the consumer uses the same PIN for all functions a rogue relying
party app can technically perform advanced "phishing" in the
background while you are paying. Most people don't like
multiple PIN-codes. I'm one :-)
Anders
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
