Table of Contents - APTAStandards.com
Table of Contents - APTAStandards.com Table of Contents - APTAStandards.com
Document Issuer Title Comments Metropolitan ® TransLink Data and Transaction and data types for back office Transportation Messaging Format messaging between CID and the higher Commission (MTC) Specification tier Port Authority New Regional Interoperability RIS scope is defined to detail card, card to York/New Jersey Specification (RIS) Part 4 CID and agency Central Computer (ACC) ( PANY/NJ) to Regional Clearing House (RCH) specifications OCTOPUS Documentation Relevant to Back-office clearing and settlement the UTFS Effort messaging 1.2 APTA Efforts To Date As a preliminary activity to the development of WP4 interface specifications, the UTFS Financial Management Committee Systems Workpackage 4 developed the Interface Specification Functional Description document that describes the following interfaces in detail: • Regional System Interface • Operator System Interface • Operator to Operator Interface Additionally, the Functional Description document defines the functionality that must be present for each interface in order to be deemed “compliant” by the future APTA standards. The document also provides a framework to evaluate the required functionality by the following criteria: • Messages • Data structures • Commands 2.0 METHODOLOGY For this research effort Booz Allen employed a methodology that first included an identification of relevant smart card standards and specifications (transit and nontransit). The next step in the methodology was to apply screening criteria to each of the documents in order to determine their relevancy to the UTFS effort. The documents that fulfilled the project screening criteria became candidates for detailed analysis. The methodology is illustrated in Exhibit 2-1. Page 8
Identify S m art Card Indust ry S ta ndards & Sp ecif ica tions Exhibit 2-1 Selection Methodology Apply Project Screening Criteria Does it Meet all the Criteria? Yes Detailed An alysis (Section 3.0) (Section 4.0) Not Applicable to the UTFS Effort No Relevant but Unable to Obtain Permission (Exhibit 3-1) (Exhibit 3-2) Could Not Obtain – Can’t Ascertain Relevance (Exhibit 3-2) Booz Allen began this research effort by identifying a candidate pool of standards and specifications that address smart card or electronic payment transactions. We selected the documentation based on the following factors: • Our work on various smart card implementations in North America, Europe and Asia/Australia • Our relationships with vendors in the smart card community • Our knowledge of smart card or messaging specifications introduced in other industries (e.g. financial, electronic toll collection) that may have applicability to the UTFS effort In addition, APTA, through its work in UTFS Workpackages, identified several standards and specifications for analysis. 3.0 PROJECT SCREENING CRITERIA Two preliminary criteria were established to evaluate each standard and specification in order to identify those that qualified for further analysis. • Relevance of the standard or specification to the UTFS efforts - Tiers the standard or specification is targeted to match WP4 focus (see Exhibits 3.1-1 and 3.1-2) • Availability for use by APTA - Timeline for acquisition of the documentation - Willingness of the issuing agency to share documentation with APTA - Requirements for use (licensing fee or contractual agreements) The first criterion was applied to each of the standards or specifications; if the document failed, it was deemed not applicable to the UTFS effort. If the standard or specification passed the first criteria, the second was applied. If it failed the second criteria it fell into one of the categories in Exhibit 3-2. The disposition for each of the standards and specifications is documented in the discussion and exhibits of this section. Page 9
- 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: This report encompasse s the review
- 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 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
Identify S m art Card<br />
Indust ry S ta ndards &<br />
Sp ecif ica tions<br />
Exhibit 2-1 Selection Methodology<br />
Apply Project<br />
Screening Criteria<br />
Does it Meet<br />
all the<br />
Criteria?<br />
Yes<br />
Detailed An alysis<br />
(Section 3.0) (Section 4.0)<br />
Not Applicable to the<br />
UTFS Effort<br />
No<br />
Relevant but Unable to<br />
Obtain Permission<br />
(Exhibit 3-1) (Exhibit 3-2)<br />
Could Not Obtain –<br />
Can’t Ascertain<br />
Relevance<br />
(Exhibit 3-2)<br />
Booz Allen began this research effort by identifying a candidate pool <strong>of</strong> standards and<br />
specifications that address smart card or electronic payment transactions. We selected<br />
the documentation based on the following factors:<br />
• Our work on various smart card implementations in North America,<br />
Europe and<br />
Asia/Australia<br />
• Our relationships with vendors in the<br />
smart card <strong>com</strong>munity<br />
• Our knowledge <strong>of</strong> smart card or messaging specifications introduced in other<br />
industries (e.g. financial, electronic toll collection) that may have applicability<br />
to the<br />
UTFS<br />
effort<br />
In addition, APTA, through its work in UTFS Workpackages, identified several<br />
standards and specifications for analysis.<br />
3.0 PROJECT SCREENING CRITERIA Two preliminary criteria were established to evaluate<br />
each standard and specification in<br />
order to identify those that qualified for further analysis.<br />
• Relevance <strong>of</strong> the standard or specification to the UTFS efforts<br />
- Tiers the standard or specification<br />
is targeted to match WP4 focus (see<br />
Exhibits 3.1-1 and 3.1-2)<br />
• Availability for use by APTA<br />
- Timeline for acquisition <strong>of</strong> the documentation<br />
- Willingness <strong>of</strong> the issuing agency to share documentation with APTA<br />
- Requirements for use (licensing fee or contractual agreements)<br />
The<br />
first criterion was applied to each <strong>of</strong> the standards or specifications; if the document<br />
failed,<br />
it was deemed not applicable to the UTFS effort. If the standard or specification<br />
passed<br />
the first criteria, the second was applied. If it failed the second criteria it fell into<br />
one<br />
<strong>of</strong> the categories in Exhibit 3-2. The disposition for each <strong>of</strong> the standards and<br />
specifications is documented in the discussion and exhibits <strong>of</strong> this section.<br />
Page 9
Change language