Smartcard industry mainly complies with standards it has to follow
The smartcard industry *creates* the standards that it follows, so that's not really a good justification for a lack of a universal scheme to identify cards.
I wasn't clear: the industry that uses smartcards (and thus mainly GSM operators and banks) provides its own rules (standards) and this industry does not care about actual card "type" or who provide it (when used, not bought); in such context card providers are more concerned by compliance with the card issuers standards than by an inter-operable standard for "empty" cards (cards dedicated to developers rather than to these closed markets)
if you except an unique ID for all GSM, banking, ID (memory?) cards> you may indeed fail to find one since these standards are differents > (actually nearly all cards but GSM provide a CPLC string as per > EMV96 or VIS1.x.x)
A mechanism for identifying hardware as to vendor, type, model and providing a unique ID has been developed for many other computer technologies that are governed by standards that are developed by numerous technology companies, many of them competitors. Consider the following technologies: [...]
two constraints exist with smartcards:
- card providers are seldom seen: the end user product is branded by the card issuer or solution provider, not by the card provider, thus smartcard industry does not make specific effort to identify itself,
- smartcards are identified for a specific functionality (a credit/debit appl, ....) not for the card itself, and thus in most of the case there is no special needs to provide unique ID.
OOH do smartcard application developers actually want to rely on specific characteristics different from one card to another ? I guess we would prefer a full, bug-free implementation of JVC APIs that behave always the same, and a reliable applet management layer (OP is helpful so far, and yes we shouldn't accept wrong AID).
and allow manufacturers/issuers to use different CM AIDs? Why no set it in stone in a standard that specifically and unambiguously spells out what every card must do to identify itself?
again, I think "old mono-applicative-card" didn't need to identity themselves, they are supposed to be used in one context and provide one function;
also no ways were defined to enumerate generic services nor to use them - in this respect the CardService definition (as per OCF) was a valuable improvement; may be the next step will be RMI introduced in JVC 2.2 that will allow introspection (SUN forgot to define a "registry of services" but at least the language is there).
I'm afraid your point is definitively wrong. All GSM cards comply with 11.11 & 11.14, all banking cards comply with EMV certification - meaning aroud 99% of issued cards !...IMHO, the industry has reaped what it has sowed over the past twenty or so years by steadfastly refusing to work together and continuing to propogate proprietary solutions for no good reason.
I'm sorry, but I believe that my point is correct - there is no one single standard in the smartcard industry that all cards follow in the area of identification and serial number/unique ID extraction.
I didn't say you was wrong, I just said it wasn't the key point: smartcards do not use some proprietary solutions for their fun, they just provide what is asked, and nobody asks for an unique _card_ id.
the comparison sounds strange !! a GSM card is as different than a banking one than a video card is different than sound card, PC industry had defined its own standards to (of course recognize these cards and) use them for a specific function; smartcards behaves the same: they behave as expected when plugged in the dedicated device.
does your VGA card runs well in a hi-fi systems ?
You miss my point completely - my example of PCI cards is that *all* PCI cards will identify themselves using the same mechanism. They all provide vendor/model/ID and resource requirements information. I can write one piece of software that will query any PCI card produced and get basic information on the card.
no, I've got your point !! all PCI cards will identify themselves to _one_ specific system (says "PCI bus" as per "PCI specification...") it's the same for scrd: each type of card identify itself to the device it is built for; today a PC is a device for which they aren't built for !..
Who defined ISO 7816? Was it handed down from the sky by some cosmic entity or by space aliens from the Planet X?
ok, I was unfair ,-) and you're right to think that when smartcard industry meets itself, it only agrees on the very minimal stuff.
I know, I'm probably preaching to the chior, but I have very little patience when I hear the industry complaining about how smartcards have not been as embraced by the general public for general computing applications.I think smartcard industry does not complain about that, it's a 1-3% market!!
Yes, that may very well be, but it could be a much larger market if the industry was willing to come up with reasonable, rigid and non-proprietary standards.
market will grow with standardized functions but which ? are you sure application providers only expect an unique ID (or things like that) ? of course it can be very time consuming to discover a card just with chosen APDU but who works like that ? I guess that developers who build smartcard based solutions expect standardized smartcard platforms (and thanks to SUN/JavaCard) as well as reliable middlewares (thanks to OCF); assuming this point it can be up to developers to define their unique data useful for their needs (OP allows ATR historical bytes definition for instance).
The main reasons that prevent cards to be used in public is more: leak of readers, why M$ does not list smartcard reader as a required device?
Is Microsoft the only opeating system vendor in the world?
no, SUN OS is a great one ,-) and iPlanet successes to integrate several smartcards from different providers...
OOH, M$ defines a (de facto) standard for the PC industry and all PC manufacturing follow these rules to build some "wintel compliant" computers, so if M$ lists reader as a common device, it will be on the box; also we were dealing with mass consuming and (it's a non-sense but) M$ is quite present on this market.
How about the fact that I can't go down to my local computer store and buy a ten-pack of Schlumberger smartcards today, and buy a ten pack of Oberthur smartcards tommorrow, and have exactly the same code work on both sets of cards?
yes, strange context: such request is legitimate and can be fulfilled (using JVC platforms), but you're right it will be very hard (not possible at all?) to buy these 10 packs !!
I think it's because the industry is more interested in selling ten million cards to a government tansportation agency than selling ten cards to a million small time developers. Hey, that's a business decision that I don't agree with, but I am not a card manufacturer or issuer, so I can only have an opinion on the matter.
also agree with you, it's a business decision and it prevent deployment of tailored applications on small basis; but may be card providers did invest money in JVC because VISA & GSM operators was pushing it, I'm also waiting for a change in their business models.
cheers, Sylvain.
---
Visit the OpenCard web site at http://www.opencard.org/ for more information on OpenCard---binaries, source code, documents. This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe ! in the body.
