Table of Contents - APTAStandards.com
Table of Contents - APTAStandards.com Table of Contents - APTAStandards.com
4.5.4.5 Peer to Peer Clearing & Settlement IFM does not specify peer-to-peer clearing and settlement in its current form. 4.5.5 Data Elements IFM does not specify data elements in its current form. 4.5.6 Message Sequences IFM does not specify message sequences in its current form. 4.5.7 Security Requirements IFM does not specify security requirements in its current form. 4.5.8 Timing & Routing IFM does not specify timing and routing in its current form. 4.5.9 Usability IFM is not usable by APTA in its current form. 4.6 Cubic Transportation System (CTS) CID EDGE INTERFACES 4.6.1 Description of the Specification This document is based on CTS's suggestions for future RIS based “CID to Back End” System protocols and not meant to represent any of Cubic's existing implementations. Data elements defined by the Edge Interfaces are based on RIS Part 03 v1.1 data formats and still subject to change by APTA UTFS WG1. 4.6.2 Applicability to UTFS Effort CID Edge Interfaces defined messages are directly applicable to the WP4’s efforts since messages have been based on transit industry related smart card data. However, this specification lacks real life implementation. The document’s compliance with the UTFS Workpackage 1 defined card data structure would simplify the additional work necessary by WP4. 4.6.3 Common Message Structure CID Edge Interfaces’ message structure consists of a header followed by individual sub- groups and a MAC. The description and structure of the header is illustrated in Exhibit 4.6-1. Page 48
Exhibit 4.6-1 CID Edge Interface Message Header Structure Sequence Name Data Type Range Description 1 Header [..] 1.1 Transtype 1.2 date-time DATETIM E 1.3 Normalorenhanced 1.4 Transstatus UBYTE 0=Reserved 1=PICC Initialized 2=PICC Issued 3=PICC Negative Listed/Disabled 4=Value Product Add/Deduct 5=Pass Product Load 6= Pass Product Remove 7=Product/ s Validation/Use UBYTE 0 - Normal Transaction 1 - Data Enhancement Transaction UBYTE 0=Normal 1=Not confirmed by PICC Type of Transaction: 1-Transmitted on PICC Initialization 2-Transmitted on PICC Issue 3-Transmitted on PICC Negative Listing 4-Transmitted on Value add, deduct, or Autoload/Auto-unload 5-Transmitted on Product Load or Autoload 6-Transmitted on Product un-load or Auto-unload 7-Transmitted on Product/s [Pass &/or SV/Purse] Validations & Uses Device’s Date and Time of this transaction. Seconds since Jan 1 1970 Indicates a Data Enhancement transaction. This contains the transmission of the PICC’s previous Transaction Details Status of the transaction. This field can be used to identify whether the write to the card was confirmed or not. Optional - not available for an Enhancement Transaction The body of a message consists of a series of sub-groups. Each sub-group contains individual data elements with similar functional characteristics such as the CID Details and the Location Details as listed in Appendix C. 4.6.4 Message Types CID Edge Interfaces currently defines the following six message types that can serve a model for device to backend data exchange: • PiccUse • PiccPurseLoad • PiccPassLoad • PiccInitialize • PiccNegativeList • PiccAutoLoadUnloadList Page 49 as
- 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 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: Application Retailer Product Retail
- 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
- Page 77 and 78: • Registration • Negative List
- Page 79 and 80: 5.0 FINDINGS This section presents
- Page 81 and 82: Exhibit 5-2 illustrates the relevan
- Page 83 and 84: Required. This set of specification
- Page 85 and 86: Project/Specification/Standard Spon
- Page 87 and 88: APPENDIX B COMPLETED CRITERIA FORMS
- Page 89 and 90: ISO/IEC 8583 Criteria Transaction D
- Page 91 and 92: TRANSLINK ® Criteria Transaction D
- Page 93 and 94: RIS PART 4 Criteria Transaction Dat
- Page 95 and 96: ITSO DATA ELEMENTS Message Type Dat
- Page 97 and 98: ITSO DATA ELEMENTS Message Type Dat
- Page 99 and 100: ITSO DATA ELEMENTS Message Type Dat
- Page 101 and 102: Amount Net Reconciliation Receiving
4.5.4.5 Peer to Peer Clearing & Settlement<br />
IFM does not specify peer-to-peer clearing and settlement in its current form.<br />
4.5.5 Data Elements<br />
IFM does not specify data elements in its current form.<br />
4.5.6 Message Sequences<br />
IFM<br />
does not specify message sequences in its current form.<br />
4.5.7 Security Requirements<br />
IFM<br />
does not specify security requirements in its current form.<br />
4.5.8 Timing & Routing<br />
IFM<br />
does not specify timing and routing in its current form.<br />
4.5.9 Usability<br />
IFM is not usable<br />
by APTA in its current form.<br />
4.6 Cubic Transportation System (CTS) CID EDGE<br />
INTERFACES<br />
4.6.1 Description <strong>of</strong> the Specification<br />
This document is based on CTS's suggestions for future RIS based “CID to Back End”<br />
System<br />
protocols and not meant to represent any <strong>of</strong> Cubic's existing implementations.<br />
Data elements defined by the Edge Interfaces are based on RIS Part 03 v1.1 data formats<br />
and still subject to change by APTA UTFS WG1.<br />
4.6.2 Applicability to UTFS Effort<br />
CID<br />
Edge Interfaces defined messages are directly applicable to the WP4’s efforts<br />
since messages have been based on transit industry related smart<br />
card data. However,<br />
this<br />
specification lacks real life implementation. The document’s <strong>com</strong>pliance with the<br />
UTFS Workpackage 1 defined card data structure would simplify the additional work<br />
necessary<br />
by WP4.<br />
4.6.3 Common Message Structure<br />
CID Edge Interfaces’ message structure consists <strong>of</strong> a header followed by individual sub-<br />
groups<br />
and a MAC. The description and structure <strong>of</strong> the header is illustrated in Exhibit<br />
4.6-1.<br />
Page 48
Change language