Table of Contents - APTAStandards.com
Table of Contents - APTAStandards.com Table of Contents - APTAStandards.com
ACQUIRER 4.1.9 Usability Exhibit 4.1-7 Batch Transfer Process 804 814 240 240 250 804 814 N times BATCH ISSUER ISO 8583 is a standard developed in ISO Technical Committee #68, which is represented by the Accredited Standards Committee X9, Inc., also referred to as ASC X9, in the US. Due to the organizational structure of ISO, APTA can pursue its adoption efforts by becoming a member of X9. The following fee schedule is based on the membership level and effective the fiscal year of September 1 – August 31: Category A – Board Membership and Full Privileges $8,000 Category B - Voting Privileges $4,750 Category C - Limited Voting $2,500 Category D – Non Voting $1,150 Category E -- Workgroup Only $ 400 Membership applications are usually processed in 24-48 hours. There is no cost involved in obtaining (or adapting to transit) the standard for membership categories A, B and C. However, the members can only distribute the standard within their own organization. Members can request changes to the standard and the length of the change process depends upon urgency of the change. Typically, the review and approval process takes somewhere between three months to a year, based on the type of changes to the standard, which are reviewed every 5-6 years. The use of the standard by non-members is subject to royalties, which are based on the amount of information extracted from the standard. The process of using the standard for non-members involves a written request identifying the parts of the standard intended for use. Page 22
Phone interviews and/or email correspondence were used to obtain this information, and it is accurate as of July 2004. However, if APTA is interested in using any parts of the standard, formal negotiations are necessary. 4.2 Integrated Transport Smartcard Organization (ITSO) 4.2.1 Description of the Specification The International Ticketing Smart Card Organization (ITSO) was founded in 1998 as collaboration between various UK Passenger Transport Authorities addressing the lack of suitable standards for interoperable smart card ticketing. ITSO was formed to build and maintain a specification for secure end-to-end interoperable ticketing transactions, utilizing relevant ISO/IEC and emerging European Committee for Standardization (CE N ) standards. The ITSO set of specifications is advisory and not binding. They aim to provide a platform and the toolbox for the provision of interoperable contactless smart card public transport ticketing and related services in the UK. The specification is divided into ten parts to cover the various entities involved in a typical fare payment system: • Part 0 – Concept and Content • Part 1 – General Reference • Part 2 – Customer Media Data and Customer Media Architecture • Part 3 – Terminals • Part 4 – Host Operator or Processing System (HOPS) • Part 5 – Customer Media Data Record Definitions • Part 6 – Message Data • Part 7 – ITSO Security Subsystem • Part 8 – ITSO Specific SAM Module (ISAM) Detailed Operation • Part 9 – Communications • Part 10 – Customer Media Definitions The emphasis of this analysis is on the Parts 4, 5 and 6 due to the scope of this project and the objectives of the WP4. The back office messages are designed to allow flexibility for adopting the specification for either peer-to-peer, or central system clearing and settlement operations. ITSO has deliberately opted to minimize data storage space requirements in order to allow organizations the most flexibility. This is especially critical where the data storage space is at a premium, such as in a bus driver controller module. To achieve this, data fields mainly have fixed sequences and lengths, freeing them from the requirements of a TLV type of encoding such as the one defined in ANS.1 specification. However, the specification still allows the use of TLV coding in number of ways at several levels when desired. Page 23
- 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 and 18: These standards and specifications
- Page 19 and 20: Although there is no “one-to-one
- 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: these messages constitutes a file.
- 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
- Page 69 and 70: 4.8.4.5 Peer-to-Peer Clearing and S
- Page 71 and 72: standard does not mandate the compl
- Page 73 and 74: Item Number Exhibit 4.9-2 Part 1 Fi
- Page 75 and 76: 4.9.4.2 PICC Scheme Control Message
Phone<br />
interviews and/or email correspondence were used to obtain this information,<br />
and<br />
it is accurate as <strong>of</strong> July 2004. However, if APTA is interested in using any parts <strong>of</strong><br />
the standard, formal negotiations are necessary.<br />
4.2 Integrated Transport Smartcard Organization (ITSO)<br />
4.2.1 Description <strong>of</strong> the Specification<br />
The<br />
International Ticketing Smart Card Organization (ITSO) was founded in 1998 as<br />
collaboration between various UK Passenger Transport Authorities<br />
addressing the lack<br />
<strong>of</strong><br />
suitable standards for interoperable smart card ticketing. ITSO was formed to build<br />
and maintain a specification for secure end-to-end interoperable ticketing transactions,<br />
utilizing relevant ISO/IEC and emerging<br />
European Committee for Standardization<br />
(CE N ) standards.<br />
The ITSO set <strong>of</strong> specifications is advisory and not<br />
binding. They aim to provide a<br />
platform and the toolbox for the provision <strong>of</strong> interoperable contactless smart card<br />
public<br />
transport ticketing and related services in the UK. The specification is divided<br />
into ten parts to cover the various entities involved<br />
in a typical fare payment system:<br />
• Part 0 – Concept and Content<br />
• Part 1 – General Reference<br />
• Part 2 – Customer Media Data and Customer Media Architecture<br />
• Part 3 – Terminals<br />
• Part 4 – Host Operator<br />
or Processing System (HOPS)<br />
• Part 5 – Customer Media Data<br />
Record Definitions<br />
• Part 6 – Message Data<br />
• Part 7 – ITSO Security Subsystem<br />
• Part 8 – ITSO Specific SAM Module (ISAM) Detailed Operation<br />
• Part 9 – Communications<br />
• Part 10 – Customer Media Definitions<br />
The emphasis <strong>of</strong> this analysis is on the Parts 4, 5 and 6 due to the scope <strong>of</strong> this project<br />
and the objectives <strong>of</strong> the WP4. The back <strong>of</strong>fice messages are designed to allow<br />
flexibility<br />
for adopting the specification for either peer-to-peer, or central system<br />
clearing and settlement operations.<br />
ITSO has deliberately opted to minimize data storage space requirements in order to<br />
allow organizations the most flexibility. This is especially critical where the data<br />
storage space is at a premium, such as in a bus driver controller module. To achieve<br />
this, data fields<br />
mainly have fixed sequences and lengths, freeing them from the<br />
requirements<br />
<strong>of</strong> a TLV type <strong>of</strong> encoding such as the one defined in ANS.1 specification.<br />
However, the specification still allows the use <strong>of</strong> TLV coding in number <strong>of</strong> ways at<br />
several levels when desired.<br />
Page 23