I appreciate that you took the time to send such good detailed comments. We will take
some into account for the Charter (high level paper) and we will put some for
follow-up during the next phase (working requirements).
For your information, we are planning to issue the first draft Charter for your
comments after the coming week-end.
Again thank you and best regards,
Philippe Lefebvre
=======================================================================
* * * Philippe J. Lefebvre
* * European Commission
* * Directorate-General Information Society
* * New methods of work and electronic commerce
* * * - Business Applications -
Office: 105 Avenue des Nerviens - N105 5/08, B-1040 Brussels
Tel: +32-2 296 8681 (Secretary) +32-2 299 1709 (Direct, voice mail outside office
hours)
Fax: +32-2 296 8387 - Email: [EMAIL PROTECTED]
=======================================================================
> 31/3/00
>
> In an OCF message, I read yesterday that introducing a card with a
> different ATR requires a routine in OCF to be rewritten - Card Factory, if
> I remember correctly. If this is true as written, it is a fundamental
> misunderstanding of the function of the ATR and of the way in which the
> terminal should process it.
>
> The idea of the ATR and of the associated (but incomplete) PPS procedure
> defined in ISO is to allow a card and terminal to adjust so that they can
> communicate in the optimum manner. Therefore ATR processing is, in
> principle, independent from application processing or application
> selection. In practice, we know that many card schemes have been developed
> in a manner which means they are critically dependent either on the card's
> ATR always being constant, or on the ATR supplying information vital to the
> APPLICATION, or on the ATR offering only a very restricted subset of the
> possibilities defined in ISO 7816. Mondex, for example, sought to make it
> possible in the early trial days for an extremely cheap but also fast
> operating money value balance reader to be manufactured - they did this by
> reporting the card balance and currency type in the historical bytes of the
> ATR (as I noted yesterday in a response to another post).
>
> In an ideal world, it might appear that the original policy of the ISO
> Working Group was that every terminal would always be capable of
> understanding and accepting all possible ATR parameter byte values. Later
> they understood that this was not a realistic scenario, and introduced the
> PPS procedure for the terminal to negotiate with the card - except that
> they have never fully developed that procedure.
>
> With the present ISO documents, it seems that a terminal that cannot accept
> the ATR from the card, and cannot use the rudimentary PPS procedure to
> solve the problem, must reject the card.
>
> Then matters moved in two directions:
>
> 1. You must also remember that a card is not required by ISO to send the
> same ATR every time. EMV turned this to their advantage when developing a
> means for global interoperability: they defined a procedure under which the
> terminal looks at the ATR, and then, if it decides it cannot do what the
> card demands, it sends a warm reset to the card (drop the reset line for a
> short time without removing card clock or power). At the end of the warm
> reset, the card MUST then send one of two possible global interoperability
> ATRs. In these ATRs, EMV mandates that the card must announce that it is
> prepared to operate with parameter values very close to those used during
> the ATR, and it announces either that it wants the T=0 comms protocol to be
> used or that it wants the T=1 protocol (EMV version - except that the
> terminal can't work that out) to be used. The terminal must then accept
> this ATR and behave accordingly. Note that ISO has done no work on terminal
> standards, and thus this EMV methodology is currently a private arrangement
> for the EMV community - it needs to be brought into ISO, but there is no
> effort available to do this sort of commonsense and very necessary work.
>
> 2. PC/SC decided to ignore the problems of incomplete implementations of
> ATR processing in the terminal, and just instruct the terminal developer to
> ignore ATR parameters and parameter values that it does not implement. So
> the terminal developer is told to carry on and hope that the card will
> work....
>
> The onus is therefore on the terminal developer to ensure that the project
> has a clear and complete specification for the ATR formats and parameter
> values and historical bytes structures that the 'terminal' must accept and
> process. The onus is therefore on library and device driver designers (such
> as OCF) to make the library and device drivers transparent to the incoming
> ATR, allowing the host system application developer to process it in a
> special ATR processing module - there's a secondary problem here, of
> course, because the card reader/writer may not be able to cope with some
> ATR parameters and parameter values, so the ATR processing module needs to
> have access to a reader/writer properties table which is loaded with the
> reader/writer device driver and/or obtained from the reader/writer. But
> there are no standards for reader/writers, and so the whole mess keeps on
> going round and round and round....
>
>
> Now we have the eEurope Initiative under way, with a Smart Card Summit in
> 10 days time, and a Smart Card Charter being drafted as I write this.
> Looking through the summary of comments received by the EC team working on
> this, the same old theme is there: complete failure by many practitioners
> in the field to understand that the interoperability problems of smart
> cards go right down to the bedrock. THE ONLY AGREEMENT ON CONTACT CARDS
> WITHIN THE INDUSTRY IS THAT THEY ARE ID-1 SIZE AND SHAPE (and even there we
> have tolerancing problems because a whole range of different materials are
> now used to make cards).
>
> So what should we do?
>
> First, accept that the voluntary methodology of ISO has not worked in this
> technology field.
>
> Second, accept that the split of responsibilities between ISO and CEN, in
> which ISO tackles the global matters and thus all the low level technology
> items, has to be modified. There are checks and balances in the standards
> system in order to correct imbalance between standards and the needs of the
> real world, and we should use them to develop, within Europe,
> interoperability specifications for contact cards and for contactless
> cards, and then submit these specs to ISO for global standardisation.
>
> Third, set (in the eEurope work) a target that all card terminals for use
> by the public must be acceptable to all card schemes. This means that all
> the individual scheme specifications must surrender their private
> specifications right up to application selection level, and there must be a
> quality assessment scheme for the terminal products and for
> multi-application card platforms.
>
> A last note: I'm not including security schemes in the scope of this note,
> because the need to create a public authentication and identification
> infrastructure has at long last been understood - because, if the security
> scheme rules are not satisfied, a card application will not work. However,
> I am aware that others who post to OCF have run up against the problem of
> not being able to make the security schemes operate without writing their
> own software, and I would urge the OCF movers and shakers to get involved
> in the European work in this area.
>
>
> Peter Tomlinson
> Iosis, Bristol, UK.
>
> Please reply to office email: [EMAIL PROTECTED]
>
---
> 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.
