1、Mrz 1999 DIN Extensions for Financial Services (XFS) interface specification - Part 4: Identification Card Device - Class Interface - Programmers Reference CWA 13449-4 Englische Fassung CWA 13449-4 : 1998 ICs 35.200; 35.240.1 5 Erweiterungen fr die Schnittstellenspezifikation fr Finanzdienstleistung
2、en (XFS) - Teil 4: Schnittstelle fr die Gerteklacce Identifikationskarten - Referenz fr den Entwickler Nationales Vorwort Dieses CEN Workshop Agreement CWA 13449-4, das vom CEN/ISSS Workshop on XFS (Erweiterungen fr Finanzdienstleistungen) erarbeitet wurde, wird ausschlielich in englischer Sprache z
3、ur Verfgung gestellt. CEN Workshop Agreements werden im Rahmen eines Konsortiums entwickelt. Sie unterscheiden sich von Europischen Normen dadurch, da sie grundstzlich kein ffentliches Einspruchsverfahren durchlaufen und da auch keine nationale Meinungsbildung stattfindet. Im Gegensatz zu Europische
4、n Normen, die den Konsens aller interessierten Kreise darstellen, haben CEN Workshop Agreements lediglich die Zustimmung der unmittelbar beteiligten Mitglieder des Konsortiums gefunden. Fr den Inhalt sind ausschlielich die Mitglieder des Konsortiums verantwortlich (siehe ergnzende Hinweise im CWA-Vo
5、rwort). Weder das CEN-Zentralsekretariat, noch die CEN-Mitglieder haben den Inhalt auf eventuelle Fehler oder Widersprche zu Normen und Rechtsvorschriften geprft. Fortsetzung 26 Seiten CWA Q Beuth Verlag GmbH, 1999 Jede Ait der Vervielfltigung, auch auszugsweise, Ref. Nr. DIN CWA 13449-4 : 19994 nur
6、 mit Genehmigung des Beuth Verlages gestattet. Alleinverkauf durch Beuth Verlag GrnbH, 10772 Berlin R W DIN C WA Preisgr. 02-04 CWA 13449-4 WORKSHOP AGREEMENT December 1998 ICs 35.200;35.240.15 English version Extensions for Financial Services (XFS) interface specification - Part 4: Identification C
7、ard Device Class Interface - Programmers Interface This CEN Workshop Agreement has been drafted and approved by a Workshop of representatives of interested parties, the constitution of which is indicated in the foreword of this Workshop Agreement. The formal process followed by the Workshop in the d
8、evelopment of this Workshop Agreement has been endorsed by the National Members of CEN but neither the National Members of CEN nor the CEN Central Secretariat can be held accountable for the technical content of this CEN Workshop Agreement or possible conflicts with standards or legislation. This CE
9、N Workshop Agreement can in no way be held as being an official standard developed by CEN and its Members. This CEN Workshop Agreement is publicly available as a reference document from the CEN Members National Standard Bodies. CEN Members are the National Standards Bodies of Austria, Belgium, Czech
10、 Republic, Denmark, Finland, France, Germany, Greece, Iceland. Ireland, Italy, Luxembourg, Netherlands, Noway, Portugal, Spain, Sweden, Switzerland and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMITE EUROPEEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG Central Secretariat: rue de S
11、tassart, 36 8-1050 Brussels O 1998 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. CWA 13449-411 998 E Page 2 CWA 13449-4:1998 Contents Foreword 3 O . Introduction . 4 . 1 XFS Service-Specific Programming 5 2 . Identification Card Rea
12、ders and Writers . 5 3 . Info Commands . 6 3.1 WFS-INF-IDC-STATUS . 6 3.2 WFS-INF-IDC-CAPABILITIES 8 3.3 WFS-INF-IDC-FORM-LIST 9 3.4 WFS-INF-IDC-QUERY-FORM . 10 4 . Execute Commands 11 4.1 WFS-CMD-IDC-READ-TRACK 11 4.2 WFS-CMD-IDC-WRITETRACK 12 4.3 WFS-CMD-IDC-EJECT-CARD . 13 4.4 WFS-CMD-IDC-RETAIN-
13、CARD . 14 4.5 WFS-CMD-IDC-RESET-COUNT 14 4.6 WFS-CMD-IDC-SETKEY 15 4.7 WFS-CMD-IDC-READ-RAW-DATA 15 4.8 WFS-CMD-IDC-WRITE-RAW-DATA 17 4.9 WFS-CMD-IDC-CHIP-IO 18 5 . Events 19 5.1 WFS-EXEE-IDC-INVALIDTRACKDATA . 19 5.2 WFS-EXEE-IDC-MEDIAINSERTED . 19 5.3 WFSSRVE-IDC-MEDIAREMOVED . 19 5.4 WFS-EXEE-IDC
14、-INVALIDMEDIA . 20 5.5 WFS-SRVE-IDC-CARDACTION . 20 5.6 WFS-USRE-IDC-RETAINBINTHRESHOLD . 20 6 . Form Description . 20 7 . C-Header file 22 Page 3 CW A 1 3449-4: 1 998 Foreword This CWA is revision 2.0 of the XFS interface specification. Release 2.0 extends the scope of the XFS interface specificati
15、on to include both the self service/ATM environment as well as the branch environment. The new specification now fully supports cameras, deposit units, identification cards, PIN pads, sensors and indicator units, text terminals, cash dispenser modules and a wide variety of printing mechanisms. This
16、specification was originally developed by the Banking Solutions Vendor Council (BSVC), and is endorsed by the CENASSS Workshop on XFS. This Workshop gathers both suppliers (among others the BSVC members) as well as banks and other financial service companies. A list of companies participating in thi
17、s Workshop and in support of this CWA is available from the CENASSS Secretariat. The specification is continuously reviewed and commented in the CENASSS Workshop on XFS. It is therefore expected that an update of the specification will be published in due time as a CWA, superseding this revision 2.0
18、0. This CWA is supplemented by a set of release notes, which are available from the CENASSS Secretariat (an on-line version of these release notes is available from http:/www.cenorm.be/isss/WorkshopB(FS/release-notes.htm). Page 4 CWA 13449-41998 In addition to these Programmers Reference specificati
19、ons, the reader of this CWA is also referred to a complementary document, called Release Notes. The Release Notes contain clarifications and explanations on the CWA specifications, which are not requiring functional changes. The current version of the Release Notes is available from the CENASSS Secr
20、etariat (contact issscenorm.be or download from http:/www.cenorm.behsssl WorkshopKFSIrelease-notes.htm). The information in this document originally contributed by members of the Banking Solutions Vendor Council and endorsed by the CENASSS Workshop on XFS, represents the Workshops current views on l
21、 the issues discussed as of the date of publication. It is furnished for informational purposes only and is subject to change without notice. CENASSS makes no warranty, express or implied, with respect to this document. O. Introduction This is part 4 of the muiti-part CWA 13449, describing Release 2
22、.0 of the XFS interface specification. The full CWA 13449 “Extensions for Financial Services (XFS) interface specificatiodconsists of the following parts: Part 1: Application Programming Interface (API) - Service Provider Interface (SPI); Programmers Reference Part 2: Service Classes Definition; Pro
23、grammers Reference Part 3: Printer Device Class Interface - Programmers Reference Part 4: Identification Card Device Class Interface - Programmers Reference Part 5: Cash Dispenser Device Class Interface - Programmers Reference Part 6: PIN Keypad Device Class Interface - Programmers Reference Part 7:
24、 Check Readeriscanner Device Class Interface - Programmers Reference Part 8: Depository Device Class Interface - Programmers Reference Part 9: Text Terminal Unit Device Class Interface - Programmers Reference Part 10: Sensors and Indicators Unit Device Class Interface - Programmers Reference Part 11
25、: Vendor Dependent Mode Device Class Interface - Programmers Reference Part 12: Camera Device Class Interface - Programmers Reference The XFS specifications are now further developed in the CENASSS Workshop on XFS. CENJISSS Workshops are open to all interested parties offering to contribute. Parties
26、 interested in participating should contact the CENASSS Secretariat (issscenorm.be). A Software Development Kit (SDK) which supplies the components and tools to allow the implementation of compliant applications and services is available from Microsoftl. To the extent that date processing occurs, al
27、l XFS Workshop participants agree that the XFS specifications are Year 2000 compliant. Revision History: 1.0 May 24,1993 Initial release of API and SPI specification 1.11 February 3,1995 2.00 November 11,1996 Updated release encompassing self-service environment. Separation of specification into sep
28、arate documents for APUSPI and service class definitions, with updates WOSAKFS Release 2.00 as originally developed by the BSVC, has been formally accepted as a CEN Workshop Agreement by the CENASSS XFS Workshop and the name WOSA/XFS has been changed into XFS. In spite of the name change, certain oc
29、currencies of WOSAKFS however still appear in the documentation, for compatibility reasons October 6,1998 I Microsoft is a registered trademark, and Windows and Windows NT are trademarks of Microsoft Corporation Page 5 CWA 13449-41998 1. XFS Service-Specific Programming The service classes are defin
30、ed by their service-specific commands and the associated data structures, error codes, messages, etc. These commands are used to request functions that are specific to one or more classes of service providers, but not all of them, and therefore are not included in the common API for basic or adminis
31、tration functions. When a service-specific command is common among two or more classes of service providers, the syntax of the command is as similar as possible across all services, since a major objective of the Extensions for Financial Services specification is to standardize command codes and str
32、uctures for the broadest variety of services. For example, using the WFSExecute function, the commands to read data from various services are as similar as possible to each other in their syntax and data structures. In general, the specific command set for a service class is defined as the union of
33、the specific capabilities likely to be provided by the developers of the services of that class; thus any particular device will normally support only a subset of the defined command set. There are three cases in which a service provider may receive a service-specific command that it does not suppor
34、t: o The requested capability is defined for the class of service providers by the XFS specification, the particular vendor implementation of that service does not support it, and the unsupported capability is not considered to be fundamental to the service. In this case, the service provider return
35、s a successful completion, but does no operation. An example would be a request from an application to turn on a control indicator on a passbook printer; the service provider recognizes the command, but since the passbook printer it is managing does not include that indicator, the service provider d
36、oes no operation and returns a successful completion to the application. The requested capability is defined for the class of service providers by the XFS specification, the particular vendor implementation of that service does not support it, and the unsupported capability is considered to be funda
37、mental to the service. In this case, a WFS-ERR-UNSUFP-COMMAND error is returned to the calling application. An example would be a request from an application to a cash dispenser to dispense coins; the service provider recognizes the command but, since the cash dispenser it is managing dispenses only
38、 notes, returns this error. The requested capability is not defined for the class of service providers by the XFS specification. In this case, a WFSERR-INVALIDCOMMAND error is returned to the calling application. o o This design allows implementation of applications that can be used with a range of
39、services that provide differing subsets of the functionalities that are defined for their service class. Applications may use the WFSGetInfo and WFSAsyncGetInfo commands to inquire about the capabilities of the service they are about to use, and modify their behavior accordingly, or they may me func
40、tions and then deal with WFSERR-UNSUPP-COMMAND error returns to make decisions as to how to use the service. 2. Identification Card Readers and Writers This section describes the functions provided by a generic identification card readedwriter service (IDC). These descriptions include definitions of
41、 the service-specific commands that can be issued, using the WFSAsyncExecute, WFSExecute, WFSGetInfo and WFSAsyncGetInfo functions. This service allows for the operation of the following categories of units: o motor driven card readedwriter o 0 dip reader 0 contactless chip card readers The followin
42、g trackskhips and the corresponding international standards are taken into account in this document: pull through card reader (writing facilities only partially included) Track 1 IS0 781 1 Track 2 IS0 781 1 Page 6 CWA 13449-41998 Track 3 Chip (contacted) IS0 781 6 Chip (contactless) IS0 10536. IS0 7
43、811 / IS0 4909 National standards like Transac for France or Watermark for Sweden are not considered, but can be easily included via the forms mechanism (see Section 6, Form Definition). In addition to the pure reading of the tracks mentioned above, security boxes can be used via this service to che
44、ck the data of writable tracks for manipulation. These boxes (such as CIM or MM) are sensor-equipped devices that are able to check some other information on the card and compare it with the track data. 3. Info Commands 3.1 WFS-INF-IDC-STATUS Description Input Param Output Param This command reports
45、 the full range of information available, including the information that is provided either by the service provider or, if present, by any of the security modules. In addition to that, the number of cards retained is transmitted for motor driven card readedwriter (for devices of the other categories
46、 this number is always set to zero). None. LPWFSIDCSTATUS IpStatus; typedef struct wfs-idc-status ( WORD fwDevice; WORD fwMedia; WORD fwRetainBin; WORD fwsecurity; USHORT uscards ; LPSTR IpszExtra; WFSIDCSTATUS, * LPWFSIDCSTATUS; fiDevice Specifies the state of the ID card device as one of the follo
47、wing flags: Value Meaning WFS-IDC-DEVONLINE The device is present, powered on and online (i.e., operational, not busy processing a request and not in an error state). The device is present and powered on, but offline (not operational-e.g., an operator has switched it offline). The device is present
48、but powered off. The device is present and is busy processing an Execute request. There is no device connected. The device is present but a person is preventing proper device operation. The application should suspend the device operation or remove the device from service until the service provider g
49、enerates a device state change event indicating the condition of the device has changed e.g.the error is removed (WFS-IDC-DEVONLINE) or a permanent error condition has occurred (WFS-IDC-DEVHWERROR). The device is present but inoperable due to a hardware fault that prevents it from being used. WFS-IDC-DEVOFFLINE WFS-IDC-DEVPOWEROFF WFS-IDC-DEVBUSY WFS-IDC-DEVNODEVICE WFS-IDC-DEVUSERERROR WFS-IDC-DEVHWERROR Page 7 CWA 13449-41998 fiMedia Specifies the state of the ID card unit as one of the following flags: Value Meaning WFS-IDC-MEDIAPRESENT
