National Academy of Sciences | 150 Year Anniversary

Questions? Call 800-624-6242

| Items in cart [0]

The National Academies Press

Rights & Permissions

topleft topright

TCRP Report 115: Smartcard Interoperability Issues for the Transit Industry (2007)
Transit Cooperative Research Program (TCRP)

Citation Manager

Transportation Research Board. "6.3 Identification of Stakeholders and Their Roles and Responsibilities." TCRP Report 115: Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press, 2007.

Please select a format:

BibTeX EndNote RefMan


Page
76
bottomleft bottomright
Page
76
Front Matter (R1-R9)
Summary (1-2)
Chapter 1 - Introduction (3-3)
1.2 Elements of Fare Payment Interoperability (4-4)
1.3 Interoperability Across Regions (5-5)
1.4 Interoperability Beyond Transit (6-6)
1.5.1 Acceptance of Contactless Bank Cards (7-8)
1.5.3 Multiple Payment-Enabled Devices (9-9)
1.6 Hypothetical Examples - Interoperability Between WMATA and TransLink (10-10)
1.6.1 Information to Be Exchanged for Payment (11-12)
1.6.3 Process for Determining the Net-Settlement Position (13-13)
2.1 Management and Organizational Issues (14-14)
2.1.1 Establishing a Governing Body or Project Sponsor (15-16)
2.1.2 Identifying and Mitigating Operational Differences (17-17)
2.1.3 Establishing a Framework for Program Funding (18-18)
2.1.4 Creating a Rollout Schedule (19-19)
2.1.5 Developing a Contracting Strategy (20-21)
2.2.2 Funds Pool Management (22-22)
2.2.3 Financial Exposure and Risk Associated with Advanced Features (23-23)
2.3.2 New Processes (24-24)
2.4 Equipment Design Issues (25-25)
2.5.2 Supplier Behavior (26-26)
2.5.3 Supplier Compliance with Available Standards (27-27)
Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs (28-28)
3.1.1 SmarTrip (29-33)
3.1.2 TransLink (34-34)
3.1.3 Chicago Card (35-35)
3.1.4 Central Puget Sound Regional Fare Coordination (RFC) Project (36-36)
3.1.5 Go-To Card (37-37)
3.1.6 Orlando Regional Alliance for Next Generation Electronic Payment System (ORANGES) (38-38)
3.1.7 Go Ventura (39-39)
3.1.8 Transit Access Pass (TAP) (40-40)
3.1.9 Compass (41-41)
3.1.10 Octopus (42-42)
3.1.11 EZ-Link (43-43)
3.1.12 Oyster (44-44)
3.2.1 Commonalities and Differences (45-46)
3.2.2 Current Trends and New Developments (47-47)
3.4.2 SmarTrip (48-48)
3.5 Summary (49-50)
4.1 Industry Interoperability Analysis (51-51)
4.2.1 Physical Layer (52-56)
4.2.2 Data Layer (57-59)
4.2.3 Application Layer (60-60)
4.2.4 Security Layer (61-66)
4.3 Gap Analysis (67-68)
5.1 Development of Conceptual Fare Payment System Architecture (69-69)
5.2 Identification of the Data Types (70-70)
5.3.2 Operation Data Flows (71-73)
6.1 Scope of the Data-Management Policy (74-74)
6.2.1 Data Location (75-75)
6.3 Identification of Stakeholders and Their Roles and Responsibilities (76-76)
6.4 Other RequirementsPrivacy (77-77)
6.5 Current Trends (78-78)
7.1 Use of Standard API in Proof of Concept (79-82)
7.2 Development of AFC Simulator (83-84)
7.3 Demonstration (85-85)
7.4 Conclusion (86-86)
Chapter 8 - Conclusions (87-91)
Appendix A - Set of Functionality for a Standard API (92-99)
Abbreviations used without definitions in TRB publications (100-100)

Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 76
76 Smartcard Interoperability Issues for the Transit Industry may be dynamically loaded onto cards in a secure manner after they have been issued to cus- tomers,) no such system is commercially available at a marketable price. Until systems permitting the dynamic loading of applications are further developed and tested, adding an application to an existing smartcard system will only be possible with the manufacture and issuance of new cards. 6.2.2 Data Ownership and Access Rights Substantial value is associated with data related to customer characteristics. The data referred to in this discussion include all types generated and collected in operating the fare payment system--both related to customers (transit riders) and the agency. Any contract for a smartcard fare payment system must define the following clearly: · Rights and Responsibilities--Associated with data generated through processing transactions; with the process of issuing, loading, and reloading transit-only cards; and with whether or not the transit application resides on a card with other applications. · Data Management--Assurance that any card-holder or card-activity data and financial and operational data from an agency are held securely so that they can be accessed by and released to only those authorized. · Confidentiality and Privacy Issues-Associated with personal (card holder) data created during fare payment system operations; data that can be linked to an individual card holder at any time are to be considered confidential and should not be released in any manner without card holder consent. For an agency-owned system, data ownership follows existing rules and regulations as they apply to public agencies. Some data, such as capital and operating expenditures, are subject to the Freedom of Information Act. However, personal data generated during fare payment systems operations should be excluded and only released in the most compelling circumstances to the proper authorities. For example, in the Hong Kong program, most cards issued are anonymous-- approximately 10 percent are personalized (registered). If customers are not reasonably confi- dent that privacy is protected they will be unlikely to accept this new form of fare media. When a smartcard fare payment system is bank-sponsored, consortium-owned data ownership ultimately becomes a cost issue. Data ownership is an intangible benefit for which quantifying a value to a particular organization is difficult. The value of the data depends on how the data will be used by the capturing entity. In the most aggressive scenario, such data may be sold outright to an organization interested in targeting customers riding transit or using a specific transit mode. Regardless of the ownership model, data ownership has to be defined before entering a con- tractual relationship. However, data ownership requirements cannot be finalized until a fare pay- ment system concept is complete. The fare payment systems concept defines what data are generated and where in the system. During fare-systems operations, the fare payment system may generate temporary files, which a contractor may argue are proprietary and are an integral func- tion of the application software. A contractor may argue that the agency has no right to the files. Therefore, data ownership becomes a subject of negotiation once fare payment system services and equipment requirements have been finalized. 6.3 Identification of Stakeholders and Their Roles and Responsibilities As the smartcard program progresses and the system design is established, the location of the data at the different tiers in the architecture becomes evident. The stakeholder will vary depend- ing on the location of the data and how and where it is generated. Each stakeholder that needs to