Andreas Schwier wrote in reply to Dave's posting (and my responses are embedded
in the text below):
> I fully agree with your statements, but it's not that terrible. I've been
> working in the industry for 14 years now and as a former member of the German
> standardisation body (NI17.4) I've been involved in the work that gave us
> ISO7816-3,4 and 5.
>
> Industry standards are always a tradeoff. They usually reflect the interest of
> companies that send people to these standardisation groups. It's
> quite expensive to do this kind of work, so it does not surprise that
> companies only invest that money, if they see some benefit (which is surely not
> interoperability).
Interoperabiliy is now a mandatory requirement for the public sector in
Europe, and the eEurope Initiative aims, with its Smart Card Charter, to
bring about interoperability in transactions between the citizen and
business. The user-centric goals are one contact reader slot spec or
standard to take all the cards that the citizen may wish to use in
transactions with government, banks, and business, and for all single
and multi-app cards issued for this purpose to be always accepted in
that slot. On top of this, there is a competition requirement: the public
sector must not be tied into single supplier relationships in this area.
Please look at the UK Framework for Smart Cards in Government on
the www.iagchampions.gov.uk web site - there is a similar push for a
common PKI infrastructure introduced in another document on that
web site. eEurope covers the same topics: cards, terminals, PKI
infrastructure.
I was yesterday at a meeting to discuss the UK specifications for
public transport ticketing. On the bus, the card interface has to be
contactless. At other times (e.g. purchasing the ticket over the
internet), the card interface can be contact. Over the next month, some
of us hope to study the drafts of 14443 up to part 3 (parts 2 and 3 have
just been completed, ready for the FDIS stage) in order to assess
whether they are good enough to build interoperable systems for both
microprocessor cards and Mifare cards.
>
> The other problem with standards, is that they only contain the results of very
> long disussions that were held in these groups. Reading the standard
> does not tell you why things are done in a certain way. You only see in a very
> compressed document, what everyone finally agreed on.
And the reasons should be documented and published, because they
would help designers to understand the often impenetrable text of the
standard.
There is another problem with standards: patents (but that is a long
story, and someone else has explained part of it).
>
> Now other people take these standards and try to implement them. And because
> developers don't really like reading standards and because they don't have the
> background information, things gets out of hand. A good example is the chaining
> mechanism in T=1. Soon after the first drafts of T=1 were written, people
> started implementing T=1, but they left out chaining and claimed that it is
> optional. If you look at the standard it's clearly not and you see that T=1
> without chaining doesn't make any sense.
>
> Standards take very long to develop and it would not work, if companies did not
> try to implement proprietary system, just to find the best solution for a
> standard. But because of this, standard often need to embrace even these poor
> first time shots, because they suddenly got successfull in the marketplace and
> defined the common standard (I can think of better ways to exchange documents
> than in Word format, but it's there and won't go away soon).
There is no excuse for standards developers not doing a professional
job, i.e. getting the standard right. The problem is basically finance.
Many companies and countries want the standard, and they want it to
be correct and complete, but they will not finance the work - so the
developers are frequently not allowed to do the job properly.
An ISO editor tells me that ISO has moved to pdf format, and we still
have problems, as was evident at the UK contactless technical panel
recently when we were comparing documents that we had each
porinted off.
>
>
> PC/SC is a good global specification to start with. I guess the combination of
> PC/SC with the CT-API / CT-BCS approach in M.U.S.C.L.E will work quite well. I
> don't see companies writing terminal drivers for OCF, and IMHO OCF will always
> be used as a layer on top of PC/SC.
When you look at the low levels of PC/SC (electrical, data comms,
ATR processing), and providing that you have knowledge of both
ISO 7816 and EMV, you quickly realise that PC/SC is a mess down
there. Its is a muddled mixture of ISO and EMV, and it says that, if the
reader can't cope with the ATR that the card sends, the reader should
carry on and hope that soemthing works.
That is not a professional way to do things. I jave asked PC/SC (and
Microsoft) to so
