On Fri, 2003-12-19 at 12:40, Ernst Lippe wrote: > It is not really true that there are so few smartcards. Almost every > mobile phone contains one (the SIM module is a smartcard). > > Also the situation in Europe is quite different from the USA. > Electronic purses on smart cards are pretty common here, especially in > France and the Netherlands, where most adults have at least one. > > But it is true that there are only very few smart card enabled > applications. I have worked on several projects for multifunctional > use of these smart cards and almost all of them were complete failures.
one can claim that the SIM module isn't a smartcard as per the original design point .... it is a mobile phone that happens to leverage the smartcard manufactoring process. my assertion is that the original smartcard design point was as a portable computing infrastructure that didn't have portable input/output technology. a huge investment went into standards (so that these cards could be carried around and still interoperate with various input/output stations) and volume manufactoring faclities. Just because they are the same physical components doesn't mean that they are the same business. my observation has been that the stored-value smartcards were an economic trade-off .... supposedly because of either 1) extremely high telco fees and/or 2) availability problems with telco connectivity .... giving everybody smartcards and all merchants "offline" (aka smartcard) point-of-sale terminals ... was less expensive than an online paradigm. in the US .... with ubiquitous and inexpensive telco availability ... it was less expensive to go with the standard online POS terminals and stored-value using the traditional magstripe interface (aka it was difficult to justify the increased chip expense based on any possible savings in telco &/or online transaction costs). my contention in the AADS chip strawman scenario ... http://www.garlic.com/~lynn/index.html#aads that with aggresive focus on compelling business use of hardware token (regardless of form factor) as an authentication device, it should be possible to justify the hardware token just based on fraud mitigation. with reasonable assumption about online connectivity becoming universal and inexpensive .... it is difficult to see any business justification for anything other than fraud mitigation. If the only business justification is authentication (for fraud mitigation), it isn't necessary to have multi-function features supported in the hardware token. If there is no function/feature needed in a hardware token (other than authentication for an online environment), the the provisioning for hardware tokens (regardless of form factor) is significantly simplified ... aka KISS. The current provisioning convention for magstripe cards is there because the magstripe carries effectively shared-secrets for authentication ... which by simple security 101 rules says that there has to be a unique shared secret per security domain (and every financial institution is their own security domain). To some extent the provisioning of financial smartcards just continues to utilize the magstripe model. In addition, given offline transaction scenario and possible use of the card for non-authentication purposes, additional provisioning of the chip is required to load business rules so that its use is aligned with the financial institution issuing the card. The assertion then is that in the scenario where the hardware token is purely an authentication device, most of the additional provisioning is eliminated (and becomes superfluous). There is typically one additional argument used for institutional delivered hardware tokens (smartcards), even if there is no provisioning required ... which is that they tightly control the process so that the chip eventually delivered to the end-user can be assumed to meet some specified trust level. So a person shows up at the doorstep with their own hardware token and wants to use it as their authentication device (whether it is a financial institution for electronic financial transactions, an employer for door badge access, or a gov. agency) .... the institution will frequently respond something about "how can they trust the token?" So what might convince institutions to accept a consumer presented hardware token for authentication ... as opposed to mandating that the only hardware token that they will trust are the ones provided by the institution. -- Anne & Lynn Wheeler - http://www.garlic.com/~lynn/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]