Table of Contents - APTAStandards.com
Table of Contents - APTAStandards.com Table of Contents - APTAStandards.com
Though the majority of the messages and related data elements have been designed for financial transaction interchange, they share some commonalities with public transit electronic fare payment transactions. 4.1.2 Applicability to UTFS Effort ISO/IEC 8583 lacks transit industry specific data elements and message types that need to be defined by APTA. The addition of this new information requires their submission to ISO/IEC, the international standards body that controls and maintains the changes to the standard. The timeline for an effort such as this is largely unknown, but estimated to be lengthy. For all the benefits offered, this standard may serve as a model for UTFS WP4 efforts. Of all the standards and specifications analyzed, ISO/IEC 8583 is the most established and widely implemented standard throughout the world. Financial data exchange of all magnetic stripe based credit card transactions follows this standard. Following the advancements in the card technologies, ISO/IEC 8583 has been updated to accommodate mostly contact based smart card transactions. Its financial industry focus led to the presence of a variety of clearing and settlement transactions exchanged between entities. Though it is mostly used for on-line real time “request-response” type transactions, the standard provides details for batch and file transfer mechanisms. 4.1.3 Common Message Structure ISO/IEC 8583 provides a common message structure, which defines three main sections for each message as illustrated in Exhibit 4.1-1. Exhibit 4.1-1 Common Message Structure Message Type Message Bitmap(s) Data Elements Message type consists of two elements, a version number and a message type identifier. The version number is allocated to indicate the version of the ISO/IEC 8583 standard followed by the interchange. The message type identifier is a three digit numeric field identifying the following: • Message class • Message function • Transaction originator Message class identifies whether it is a financial, administrative, or network management type of a message. Message function specifies if it is a request, response, notification or advice. The transaction originator digit identifies the originator of the message (e.g., issuer or acquirer). Page 14
Although there is no “one-to-one” relationship between UTFS defined message types and ISO/IEC 8583 defined message classes, this standard provides a flexible model, or foundation to further define transit industry related data elements in its body. The second element in the message structure defines whether it contains one or two bitmaps. A “1” in the bitmap indicates the presence of the corresponding data element in the message. Each bitmap has 64 bits, thus two bitmaps can provide the total of 128 data elements, as defined by the standard. The first (primary) bitmap is mandatory and represents the most frequently used data elements. The presence of the secondary bitmap is signified by a “1” in bit 01 of the primary bitmap. Bitmaps provide the application providers with the flexibility of choosing among a greater pool of data elements for varying industry segments, however, they tend to add extra overhead to the transaction speeds, especially in real-time data processing environments. The effects of this overhead may not be as significant for backend, processing environments such as clearing and settlement or reporting that are not as time sensitive as card to reader transactions. Messages are constructed using the message bit map as an index of present data elements. There are three types of data elements: • Primitive data element • Constructed data element • Composite data element Primitive data elements represent a single piece of information, whereas the constructed data element consists of a fixed number of sub-elements, all of which must be present. Composite data element consists of a large number of sub-elements. Most of these sub- elements fall into industry related categories such as auto rental data, or airline data. In order to define these categories, the concept of a “dataset” has been introduced. All the sub elements in a composite data element are divided into a certain number of datasets, each of which relates to an industry and contain a dataset identifier. The structure of a dataset is based on the message structure explained in this standard. There is also a provision for identifying sub-elements using the TLV data encoding method as an alternative to using a second level bitmap. Each composite data element can therefore contain a variable number of different datasets and can include both TLV and bitmap formats as illustrated in Exhibit 4.1-2. Page 15
- Page 1 and 2: SMART CARD STANDARDS AND SPECIFICAT
- Page 3 and 4: 4.4.7 Security Requirements........
- Page 5 and 6: Document History Revision Reason Fo
- Page 7 and 8: Acronym List UTFS Universal Transit
- Page 9 and 10: technology to achieve interoperabil
- Page 11 and 12: This report encompasse s the review
- Page 13 and 14: Identify S m art Card Indust ry S t
- Page 15 and 16: The standards and specifications th
- Page 17: These standards and specifications
- Page 21 and 22: 4.1.4.2 Card Management Data The st
- Page 23 and 24: with ISO/IEC 7816-6, there is no re
- Page 25 and 26: these messages constitutes a file.
- Page 27 and 28: Phone interviews and/or email corre
- Page 29 and 30: The ITSO message body consists of i
- Page 31 and 32: Exhibit 4.2-2 Product Types Type Co
- Page 33 and 34: Capability Values or RFU Product Pr
- Page 35 and 36: opted to contract these services ou
- Page 37 and 38: e given careful consideration for a
- Page 39 and 40: - Transaction date and time - Trans
- Page 41 and 42: cardholder related data as in the c
- Page 43 and 44: CLIENT Exhibit 4.3-9 OFX Security S
- Page 45 and 46: may well be eliminated if, and when
- Page 47 and 48: Exhibit 4.4-4 Condition Dialogue St
- Page 49 and 50: 4.4.7 Security Requirements The Mes
- Page 51 and 52: Application Retailer Product Retail
- Page 53 and 54: Exhibit 4.6-1 CID Edge Interface Me
- Page 55 and 56: 4.6.8 Timing and Routing The CID Ed
- Page 57 and 58: 4.7.4.1 Transaction Data The “Far
- Page 59 and 60: 4.7.4.3 System and Device Data The
- Page 61 and 62: Following the authentication proces
- Page 63 and 64: Data” transaction messages propos
- Page 65 and 66: Field Name Description reading the
- Page 67 and 68: 4.8-7 Product Transactions Usage Me
Although there is no “one-to-one” relationship between UTFS defined<br />
message types<br />
and<br />
ISO/IEC 8583 defined message classes, this standard provides a flexible model, or<br />
foundation<br />
to further define transit industry related data elements in its body.<br />
The<br />
second element in the message structure defines whether it contains one or two<br />
bitmaps.<br />
A “1” in the bitmap indicates the presence <strong>of</strong> the corresponding data element<br />
in the message. Each bitmap has 64 bits, thus two bitmaps can provide the total <strong>of</strong> 128<br />
data<br />
elements, as defined by the standard. The first (primary) bitmap is mandatory and<br />
represents<br />
the most frequently used data elements. The presence <strong>of</strong> the secondary<br />
bitmap is signified by a “1” in bit 01 <strong>of</strong> the primary bitmap.<br />
Bitmaps provide the application providers with the flexibility <strong>of</strong> choosing among a<br />
greater pool <strong>of</strong> data elements for varying industry segments, however, they tend to<br />
add<br />
extra<br />
overhead to the transaction speeds, especially in real-time data processing<br />
environments. The effects <strong>of</strong> this overhead may not be as significant for backend,<br />
processing environments such as clearing and settlement or reporting that are not as<br />
time sensitive as card to reader transactions.<br />
Messages are constructed using the message bit map as an index <strong>of</strong> present data<br />
elements. There are three types <strong>of</strong> data elements:<br />
• Primitive data element<br />
• Constructed data element<br />
• Composite data element<br />
Primitive data elements represent a single piece <strong>of</strong> information, whereas the constructed<br />
data element consists <strong>of</strong> a fixed number <strong>of</strong> sub-elements, all <strong>of</strong> which must be present.<br />
Composite data element consists <strong>of</strong> a large number <strong>of</strong> sub-elements. Most <strong>of</strong> these sub-<br />
elements fall into industry related categories such as auto rental data, or airline data. In<br />
order to define these categories, the concept <strong>of</strong> a “dataset” has been introduced. All<br />
the<br />
sub elements in<br />
a <strong>com</strong>posite data element are divided into a certain number <strong>of</strong> datasets,<br />
each<br />
<strong>of</strong> which relates to an industry and contain a dataset identifier. The structure <strong>of</strong> a<br />
dataset is based on the message structure explained in this standard. There is also a<br />
provision<br />
for identifying sub-elements using the TLV data encoding method as an<br />
alternative to using a second level bitmap. Each <strong>com</strong>posite data element can therefore<br />
contain a variable number <strong>of</strong> different datasets and can include both TLV and bitmap<br />
formats as illustrated in Exhibit 4.1-2.<br />
Page 15