US: TOMP - Secure Wireless Internet (ITS)

Description:

This solution is used within the U.S.. It combines standards associated with US: TOMP with those for I-M: Secure Wireless Internet (ITS). The US: TOMP standards include upper-layer standards required to share information among transport operators. The I-M: Secure Wireless Internet (ITS) standards include lower-layer standards that support secure communications between two entities, either or both of which may be mobile devices, but they must be stationary or only moving within wireless range of a single wireless access point (e.g., a parked car). Security is based on X.509 or IEEE 1609.2 certificates. A non-mobile (if any) endpoint may connect to the service provider using any Internet connection method.

Comm Profile: I-M: Secure Wireless Internet (ITS)

Level	Doc #	Standard	Description
Access		Wireless Internet Alternatives (NA)	A set of alternative standards that supports any technology that allows a mobile device (e.g., a vehicle) to connect to the Internet (or an intranet) while stationary or moving within a limited area. For example, this would include both Wi-Fi and cellular technologies among others. NOTE: Use of the WAVE Subnet should be coupled with use of IEEE 1609.3 at the TransNet Layer.
Mgmt		Bundle: SNMPv3 MIB	A bundle of standards (RFCs) that groups the common management information bases (MIBs) used to manage IP networks at the transport layer and below using SNMPv3.
Security		Secure Session Alternatives	A set of alternative standards that identifies standards that are used to establish and maintain secure Internet sessions. If an information exchange does not require encryption, the (D)TLS session can negotiate NULL encryption. NOTE: If TCP is selected in the TransNet Layer, one of the TLS alternatives must be selected from this alternative set; if UDP is selected in the TransNet Layer, one of the DTLS alternatives must be selected from this alternative set.
TransNet		Internet Transport Alternatives	A set of alternative standards that identifies the two major options for the transport layer for mainstream IP-based deployments.
TransNet		IP Alternatives	A set of alternative standards that allows for the selection of IPv4 or IPv6.

Data Profile: US: TOMP

Level	Doc #	Standard	Description
Facilities	IETF RFC 7159	IETF RFC 7159 JSON	The JavaScript Object Notation (JSON), a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.
Facilities	IETF RFC 9110	IETF RFC 9110 HTTP Semantics	The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.
Facilities	IETF RFC 9112	IETF RFC 9112 HTTP/1.1	The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.
ITS Application Entity	TOMP-API	Transport Operator Mobility-as-a-Service Provider	The TOMP working group aims to develop and sustain an internationally governed interoperable open standard for technical communication between Transport Operators and MaaS Providers, by means of definition, improvement, alignment and dissemination.

Readiness Description:

One significant or possibly a couple minor issues. For existing deployments, the chosen solution likely has identified security or management issues not addressed by the communications solution. Deployers should consider additional security measures, such as communications link and physical security as part of these solutions. They should also review the management issues to see if they are relevant to their deployment and would require mitigation. For new deployments, the deployment efforts should consider a path to addressing these issues as a part of their design activities. The solution does not by itself provide a fully secure implementation without additional work.