EP4699264A1

EP4699264A1 - User authorized direct data streaming for vehicle data

Info

Publication number: EP4699264A1
Application number: EP24727859.1A
Authority: EP
Inventors: Thomas DMYTRYK; Silvio Brugada; Aaron KAHN; Theodore ZHANG; Robert Seth TERASHIMA
Original assignee: Tesla Inc
Current assignee: Tesla Inc
Priority date: 2023-04-21
Filing date: 2024-04-19
Publication date: 2026-02-25
Also published as: CN121175982A; KR20250168672A; WO2024220903A1

Abstract

One or more aspects of the present disclosure relate to the configuration and management of data communications associated with a vehicle. By way of illustrative example, aspects of the present application correspond to management of data communications to obtain data generated or collected by a vehicle (e.g., "vehicle data"), which can include, but is not limited to, logs of information previously collected or generated by sensor and processing components, current vehicle data, or third-party data collected by the vehicle, and the like. In another illustrative examples, aspects of the present application correspond to management of data communications to provide configuration data or executable code to a vehicle, such as diagnostic applications, repair applications, and the like.

Description

USER AUTHORIZED DIRECT DATA STREAMING FOR VEHICLE DATA CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims priority to U.S. Provisional Patent App. No. 63/497687 titled “USER AUTHORIZED DIRECT DATA STREAMING FOR VEHICLE DATA”, filed on April 21, 2023 and U.S. Provisional Patent App. No.63/498240 titled “USER AUTHORIZED DIRECT DATA STREAMING FOR VEHICLE DATA”, filed on April 25, 2023. Each of the above-recited applications is hereby incorporated herein by reference in its entirety. BACKGROUND [0002] Generally described, computing devices and communication networks can be used to exchange data and/or information. In a common application, a computing device can request content from another computing device via a communication network. For example, a user at a personal computing device can use a browser application to request a content page (e.g., a network page, a Web page, etc.) from a server computing device via the communication network (e.g., the Internet). In this example, the user computing device can be referred to as a client computing device and the server computing device can be referred to as a content provider. In another embodiment, the user computing device can collect or generate information and provide the collected information to a server computing device for further processing or analysis. [0003] Generally described, a variety of vehicles, such as electric vehicles, combustion engine vehicles, hybrid vehicles, etc., can be configured with various sensors and components to facilitate operation. In certain scenarios, a vehicle owner or vehicle user may designate a third-party to be provided with at least a portion of data generated or otherwise collected by a vehicle. Typically, the vehicle information is first provided to a content provider and subsequently provided by the content provider to the third-party. SUMMARY [0004] According to some embodiments, a system, method, and non-transitory computer storage media is described. Example actions may cause a processor or computer to respond to connection information from a third-party network, the connection information including a public fleet key, wherein the received public fleet key is used to authorize a vehicle to receive the public fleet key from a mobile device paired with the vehicle; analyze a vehicle transmission configuration to be transmitted to the vehicle, the vehicle transmission configuration including indications of types of vehicle data to be streamed to the third-party network, information describing how the vehicle is to connect to the third-party network, and a particular certificate authority authorized to validate the third-party network, wherein the vehicle transmission configuration is signed based on a private fleet key associated with the third-party network; and transmit the vehicle transmission configuration to the vehicle, wherein the vehicle identifies, based on the vehicle transmission configuration, one or more network locations at which to stream the vehicle data, wherein the vehicle validates the network locations using the particular certificate authority, and wherein the vehicle is configured to transmit the types of vehicle data to the third-party network. [0005] The actions may include one or more of actions that cause the processor or computers to provide, to the third-party network, a public schema identifying available types of vehicle data, wherein the vehicle transmission configuration indicates a subset of the available types of vehicle data. The vehicle stores the fleet public key based on receipt of the fleet public key from the mobile device, and wherein the vehicle validates the vehicle transmission configuration using the fleet public key. The mobile device is in wireless communication with the vehicle over a network or wherein the mobile device is in local wireless communication with the vehicle. A particular type of vehicle data is assigned an alias, and wherein the vehicle associates the particular type of vehicle data with the alias. The vehicle generates event data corresponding to the alias, and wherein the vehicle associates the event data with the particular type of vehicle data. Transmission occurs via an encrypted communication link between the third-party network and the vehicle. [0006] According to some embodiments, a system, method, and non-transitory computer storage media is described. Example actions may include receiving, via a mobile device paired with the vehicle, a fleet public key associated with a third-party network, wherein the vehicle is configured to generate event data associated with different types of vehicle data, and wherein the event data is generated based on use of sensors or based on operation of the vehicle by a user; analyzing a vehicle transmission configuration received from a management network associated with the vehicle, the vehicle transmission configuration including indications of particular types of vehicle data to be streamed to the third-party network, information describing how the vehicle is to connect to the third-party network, and a particular certificate authority authorized to validate the third-party network, wherein the vehicle transmission configuration is signed based on a private fleet key associated with the third-party network, and wherein the processor validates the vehicle transmission configuration based on the fleet public key; and transmitting the particular types of vehicle data to the third-party network, wherein the vehicle identifies, based on the vehicle transmission configuration, one or more network locations at which to stream the particular types of vehicle data, and wherein the vehicle validates the network locations using the particular certificate authority. BRIEF DESCRIPTION OF THE DRAWINGS [0007] This disclosure is described herein with reference to drawings of certain embodiments, which are intended to illustrate, but not to limit, the present disclosure. It is to be understood that the accompanying drawings, which are incorporated in and constitute a part of this specification, are for the purpose of illustrating concepts disclosed herein and may not be to scale. [0008] Figure 1 is a block diagram of an illustrative environment for providing vehicle data communication access in accordance with one or more aspects of the disclosed technology. [0009] Figure 2 is a block diagram of an environment that corresponds to vehicles in accordance with one or more aspects of the disclosed technology. [0010] Figure 3A is a block diagram of an illustrative architecture for implementing a processing component on a vehicle as described herein. [0011] Figure 3B is a block diagram of an illustrative architecture for implementing the third-party network as described herein. [0012] Figure 4A is block diagram illustrating an example of interactions between a vehicle, a third-party network, and a management network. [0013] Figure 4B is a block diagram illustrating another example of interactions between a vehicle, a third-party network, a paired mobile device, and a management network. [0014] Figure 5 is a flowchart of an example process for a vehicle authorization routine to begin streaming data to a third-party network. [0015] Figure 6 is a flowchart of an example process for a third-party authorization routine to begin streaming data associated with a vehicle. [0016] Figure 7 is a flowchart of an example process for an illustrative routine to register a vehicle to a fleet. DETAILED DESCRIPTION [0017] Generally described, one or more aspects of the present disclosure relate to the configuration and management of data communications associated with a vehicle. By way of illustrative example, aspects of the present application correspond to management of data communications to obtain data generated or collected by a vehicle (e.g., “vehicle data”). Example data may include current vehicle information (e.g., information collected or generated by sensor and processing components), logs of vehicle information, third-party data collected by the vehicle, and so on. In another illustrative example, aspects of the present application correspond to management of data communications to provide configuration data or executable code to a vehicle, such as diagnostic applications, repair applications, and the like. [0018] In accordance with an illustrative embodiment, one or more aspects of the present application relate to the management and accessibility of vehicle data communications provided to an authenticated and authorized third-party. Illustratively, a network service provider facilitates the interaction between the vehicle owner/user and the third-party accessing the respective vehicle data. The network service provider can facilitate an initial authorization for access to vehicle data, provide access to the vehicle data for authenticated and authorized users, and manage revocation of vehicle data access rights. [0019] In some embodiments, the information provided by the components can include processed information in which a controller, logic unit, processor, and the like has processed sensor information and generated additional information. For example, a vision system may use inputs from one or more camera sensors and provide outputs corresponding to identification of environmental conditions about a vehicle. In this example, the vision system may identify objects positioned proximate to the vehicle optionally along with signals informing actions of the objects. In some embodiments, additional sensor information may be obtained (e.g., ultrasound, radar, and so on). In some embodiments, a control component can use additional information obtained from, or otherwise associated with, positioning systems, calendaring systems, or time-based systems. In still a further example, historical information can be incorporated as a separate information source to the control component or be used to process at least some portion of the set of information sources, such as detected vehicle speed, external temperature measurements, and operational status of the windshield wiper, vision system (e.g., camera inputs), location systems (e.g., GPS systems), timing information, operational status of the radar components, etc. [0020] As previously described, traditional approaches to data communication management between a vehicle and a third-party require the vehicle data to first be sent to a centralized server, such as a content provider, where the vehicle data is stored. After vehicle data is stored on the centralized server, the centralized server determines which third-party the vehicle data is sent to. For example, under a traditional approach, vehicle data may be collected by a vehicle and provided to a content provider, such as a car manufacturer or other centralized server. The content provider may in turn provide the vehicle data to one or more third-parties. [0021] The traditional approaches to vehicle data management may require the content provider to dedicate resources, such as computing and workforce resources, into maintaining the data flow between vehicles and third-parties and storing large amounts of vehicle data. Additionally, the content provider may be required to dedicate resources to segregating, or otherwise isolating, vehicle data for each third-party, filtering vehicle data based on third-party preference, and controlling when vehicle data is collected and sent to third-parties. These requirements may also introduce additional latency between the time vehicle data is collected and when the third-party receives the data. Additionally, the vehicle owner/user may have little or no control over what vehicle data is collected and to which third- party the vehicle data is sent to. [0022] To address at least a portion of the above-identified inefficiencies, a management network can facilitate a direct, secure data connection between a vehicle and a third-party for the streaming of vehicle data to the third-party. The management network can provide services to initialize and maintain authentication information used to create the direct data connection between a vehicle and a third-party. While any direct, secure data connection may be used to stream data between the vehicle and the third-party, for illustrative purposes a mutually authenticated encrypted data stream, such as mutual transport layer security (“mTLS”), will be used in description. However, one skilled in the relevant art will appreciate that one or more aspects of the present application are not limited to utilization of mTLS protocols and that variations of mutual authenticated communication protocols or alternatives to mutual authenticate communication protocols may be implemented. [0023] As described herein, a mutually authenticated encrypted data stream, such as mTLS may require each party establishing a communication channel for data streaming to authenticate the identity of the other party. Illustratively, in accordance with a mTLS-based mutual authentication approach, two (or more) computing devices encrypt and decrypt data using unique computer instructions, referred to as public keys and private keys. When a public key is used to encrypt a portion of data, only the private key associated with the public key may be used to decrypt that portion of data. Illustratively, mTLS may use computer data files, referred to as certificates, to authenticate party identities. For purposes of authentication, a certificate may include information for authentication such as a public key, a statement of the entity that issued the certificate, referred to as a certificate authority, an expiration date of the certificate, and other information used for authentication. Illustratively, mTLS may require each party to present a certificate to the other prior to be authenticated before data transfer may begin. As will be described in greater detail, in some embodiments, the information included in certificates or with certificates can also include additional information used in the exchange of streaming data between two computing devices. [0024] Illustratively, the management network can provide services to facilitate the configuration of direct, secure communication channel, such as an mTLS-based connection, between a vehicle and a third-party destination. However, in accordance with aspects of the present application, the management network does not participate in the secure communication channel or otherwise is configured to receive data exchanged between the vehicle and the third- party destination. In some embodiments, the management network may function as a certificate authority and issue the certificates for a vehicle and a third-party used in establishing and configuring the mutually authenticated communication channel, namely, an mTLS connection. In some embodiments, the management network may control the certificate expiration. In other embodiments, the certificate issuance and expiration may be determined by another party such as a vehicle owner, a third-party, or other entity. [0025] Illustratively, by configuring a direct, mutually authenticated communication channel, such as an mTLS connection, third-parties may receive vehicle data directly from a vehicle without requiring the data to be received, processed, forwarded, or stored by the management system (or any specific computing device associated with the management system). This may allow one or more third-parties to directly obtain vehicle data such as one or more of GPS data, velocity data, fuel or battery state data, navigation data, self- driving information (e.g., activation of self-driving functionality, disengagements from self- driving, specific objects or signals determined by self-driving functionality), and the like. [0026] The data communications may also allow a third-party to diagnose vehicle performance, identify potential issues, facilitate the advanced ordering of parts, and the like. The data communications can also allow the third-party to cause the vehicle to execute executable code or configurations that facilitate diagnostics, repairs, updates, upgrades and the like. The configuration of the type of data transmitted to the third-party destination can be pre- configured on a vehicle or otherwise transmitted by the management service as part of the provisioning of the mutual authentication certificates. [0027] Illustratively, a vehicle owner may control one or more attributes of the data communication channels including duration of access, type of access, vehicle data restrictions and the like. Specifically, in accordance with aspects of the present application, once the mutually authenticated communication channel is established between the vehicle and one or more third-party destinations, user controls may be further implemented to control aspects of streaming data content, including, but not limited to, the initiation of streaming data, the continued streaming of data, the termination of streaming data, and the like. In some embodiments, the user controls may further be configured to require some form of physical proximity to a selected vehicle, such as by limiting controls to in-vehicle interfaces, short range wireless communication networks, verified mobile applications (e.g., scanned barcodes), and the like. As used herein, streaming data refers to information which is provided by a vehicle to a third-party, with the information being pushed by the vehicle (e.g., as a stream). In some embodiments, information may be requested by a third-party (e.g., a pull) from a vehicle. [0028] Although the various aspects will be described in accordance with illustrative embodiments and combination of features, one skilled in the relevant art will appreciate that the examples and combination of features are illustrative in nature and should not be construed as limiting. More specifically, aspects of the present application may be applicable with various types of vehicle data or vehicle processes. Further, while aspects of the present application may describe embodiments with respect to a singular vehicle, the present application may be applicable with multiple vehicles, such as a fleet of vehicles. However, one skilled in the relevant art will appreciate that the aspects of the present application are not necessarily limited to application to any particular type of vehicle data, data communications or illustrative interaction between third-parties, customer and a management network. Example Block Diagrams [0029] Figure 1 is a block diagram of an example system 100 for providing vehicle data communication access in accordance with one or more aspects of the disclosed technology. The system 100 can include a network 150, with the network 150 connecting a set of vehicles 110 (e.g., a fleet of vehicles), a management network 120, and one or more third- party networks 130. The components may correspond to software modules implemented or executed by one or more external computing devices, which may be separate stand-alone external computing devices. Accordingly, the components of the management network 120 should be considered as a logical representation of the service, not requiring any specific implementation on one or more external computing devices. [0030] The third-party network 130, as depicted in Figure 1, can be any server or computing device such as a desktop, laptop, personal computer, tablet computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA/mobile phone, mobile phone, smartphone, set-top box, voice command device, digital media player, and the like. The third- party network 130 may also be one or more computing devices connected together in a local area network (“LAN”), across a wide area network (“WAN”), or any technique used in connecting or tethering computer devices together. The third-party network 130 may execute an application (e.g., a browser, a stand-alone application, etc.) that allows a user to access interactive user interfaces, view images, analyses, aggregated data, and/or the like as described herein. By way of illustrative embodiment, the third-party network 130 corresponds to one or more computing device that are used to acquire and analyze vehicle data. As will be described, the third-party network 130 can request access to vehicle data as described herein. [0031] The network 150, as depicted in Figure 1, connects the vehicles 110 third- party network 130, and management network 120. The network 150 can connect any number of devices through a network service provider, or other connection method. In some embodiments, a network service provider implements network-based services and refers to a large, shared pool of network-accessible computing resources (such as compute, storage, or networking resources, applications, or services), which may be virtualized or bare-metal. The network service provider can provide on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adjust to the variable load. The concept of “cloud computing” or “network- based computing” can thus be considered as both the applications delivered as services over the network and the hardware and software in the network service provider that provide those services. [0032] The network 150 may include any combination of wired and/or wireless networks, such as one or more direct communication channels, local area network, wide area network, personal area network, and/or the Internet, for example. In some embodiments, communication between the vehicle 110 and the third-party network 130 may be performed via a short-range communication protocol, such as Bluetooth, Bluetooth low energy (“BLE”), and/or near field communications (“NFC”). Communication between the vehicle 110, the third-party network 130, and the management network 120 can occur via network 150, such as via one or more secured networks, such as a local area network that communicates securely via the Internet with the management network 120. The various communication protocols discussed herein are merely examples, and the present application is not limited thereto. [0033] Illustratively, the set of vehicles 110 correspond to one or more vehicles configured with data storage for storing data generated from electrical components in the vehicle 110. The data, for example, can include log data generated from sensors installed in the vehicle, any processed data related to the vehicle operation such as engine oil data, coolant temperature, mileage, oxygen, knocking information from various sensors, etc. The data can also include diagnosed data, automated driving (e.g., self-driving) related data, and so on. The data can also include driver or passenger interactions with a user interface within a vehicle (e.g., interactions with specific controls, activation of specific applications) or with specific vehicle controls within the vehicle (e.g., windows, powered seats, automated doors or trunks, air conditioning controls, music controls, and so on). In one embodiment, the data can be received from an external device. By way of illustration, the vehicles 110 can include computing devices that be considered to be integrated or form a part to the vehicle. In other embodiments, customers may also have additional computing devices, such as mobile devices, that will be considered to be associated with the vehicle, including mobile devices tethered to or in close proximity to a vehicle. For purposes of the present disclosure, a customer computing device will be generally interpreted in accordance with each of these embodiments, and variations thereof. [0034] Illustratively, the management network 120 can include a certificate managing service 116 that can provide functionality responsive to authenticating third-parties as applied to aspects of the present application. The management network 120 can include one or more data stores data associated with the vehicles 110 and the third-party networks 130. The certificate managing service 116 and data store 114 in Figure 1 are logical in nature and can be implemented in the management network 120 in a variety of manners. [0035] For purposes of illustration, Figure 2 is a block diagram of an environment that corresponds to vehicles 110 in accordance with one or more aspects of the disclosed technology. The environment includes a collection of local sensor inputs that can provide inputs for the operation of the vehicle or collection of information as described herein. The collection of local sensors can include one or more sensor or sensor-based systems included with a vehicle or otherwise accessible by a vehicle during operation. The local sensors or sensor systems may be integrated into the vehicle. Alternatively, the local sensors or sensor systems may be provided by interfaces associated with a vehicle, such as physical connections, wireless connections, or a combination thereof. [0036] In one aspect, the local sensors can form part of vision systems that provide inputs to the vehicle, such as detection of objects, attributes of detected objects (e.g., position, velocity, acceleration), presence of environment conditions (e.g., snow, rain, ice, fog, smoke, etc.), and the like. In some embodiments, vehicles 110 can rely on such vision systems for defined vehicle operational functions without assistance from or in place of other traditional detection systems. [0037] In yet another aspect, the local sensors can include one or more positioning systems that can obtain reference information from external sources that allow for various levels of accuracy in determining positioning information for a vehicle. For example, the positioning systems can include various hardware and software components for processing information from GPS sources, Wireless Local Area Networks (WLAN) access point information sources, Bluetooth information sources, radio-frequency identification (RFID) sources, and the like. In some embodiments, the positioning systems can obtain combinations of information from multiple sources. Illustratively, the positioning systems can obtain information from various input sources and determine positioning information for a vehicle, specifically elevation at a current location. In other embodiments, the positioning systems can also determine travel-related operational parameters, such as direction of travel, velocity, acceleration, and the like. The positioning system may be configured as part of a vehicle for multiple purposes including self-driving applications, enhanced driving or user-assisted navigation, and the like. Illustratively, the positioning systems can include processing components and data that facilitate the identification of various vehicle parameters or process information. [0038] In still another aspect, the local sensors can include one or more navigations system for identifying navigation related information. Illustratively, the navigation systems can obtain positioning information from positioning systems and identify characteristics or information about the identified location, such as elevation, road grade, etc. The navigation systems can also identify suggested or intended lane location in a multi-lane road based on directions that are being provided or anticipated for a vehicle user. Similar to the location systems, the navigation system may be configured as part of a vehicle for multiple purposes including self-driving applications, enhanced driving or user-assisted navigation, and the like. The navigation systems may be combined or integrated with positioning systems. Illustratively, the positioning systems can include processing components and data that facilitate the identification of various vehicle parameters or process information. [0039] The local resources further include one or more processing component(s) 112 that may be hosted on the vehicle or a computing device accessible by a vehicle (e.g., a mobile computing device). The processing component(s) 112 can illustratively access inputs from various local sensors or sensor systems and process the inputted data and store the processed data. For purposes of the present application, the processing component(s) 112 will be described with regard to one or more functions related to illustrative aspects. For example, processing component(s) 112 in vehicle 110 will collect and transmit the data set corresponding to the request from authorized technicians. [0040] The environment can further include various additional sensor components or sensing systems operable to provide information regarding various operational parameters for use in accordance with one or more of the operational states. The environment can further include one or more control components for processing outputs, such as the transmission of data through a communications output, generation of data in memory, the transmission of outputs to other processing components, and the like. [0041] With reference now to Figure 3A, an illustrative architecture for implementing a processing component on a vehicle 110 will be described. The processing component 112 may be part of components/systems that can provide functionality associated with processing and storing vehicle data and providing an access to the stored data for a technician by receiving the technician’s authorized information. [0042] The architecture of Figure 3A is illustrative in nature and should not be construed as requiring any specific hardware or software configuration for the processing component. The general architecture of the processing component 112 of a vehicle/customer device depicted in Figure 3A includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. As illustrated, the processing component includes a processing unit 302, a network interface 308, a computer readable medium drive 306, and an input/output device interface 304, all of which may communicate with one another by way of a communication bus. The components of the processing component may be physical hardware components that can include one or more circuitries and software models. [0043] The network interface 308 may provide connectivity (e.g., wireless or wired connectivity, such as cellular connectivity, Wi-Fi connectivity, Bluetooth, and so on) to one or more networks or computing systems, such as the network 150 of Figure 1. The processing unit 302 may thus receive information and instructions from other computing systems or services via a network. The processing unit 302 may also communicate to and from memory 310 and further provide output information via the input/output device interface. In some embodiments, the processing component 112 may include more (or fewer) components than those shown in Figure 3A. [0044] The memory 310 may include computer program instructions that the processing unit 302 executes in order to implement one or more embodiments. The memory 310 generally includes RAM, ROM, or other persistent or non-transitory memory. The memory 310 may store an operating system 312 that provides computer program instructions for use by the processing unit 302 in the general administration and operation of the processing component 112. The memory 310 may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 310 includes an authentication component 314. In some embodiments, the authentication component 314 requests authentication information, such as a third-party certificate or other authentication information, from the certificate managing service 116 or from the third-party network 130. In these embodiments, the authentication component 314 may receive the authentication information via the network 150. [0045] In some embodiments, a third-party will have authentication credentials, such as a certificate, that are provided to the third-party network 130 by the certificate managing service 116 that indicates an authentication of the third-party data streaming access the vehicle 110. In these embodiments, the authentication component 314 may receive a transmission configuration that includes authentication information, such as the public key information associated with the third-party, from the certificate managing service 116. In these embodiments, the third-party, by utilizing the third-party network 130, may provide the certificate or other semi-persistent information to the authentication component 314 via the network 150. [0046] After receiving the third-party’s certificate, the authentication component 314 may validate or confirm the third-party’s certificate. After validating the third-party’s certificate, the authentication component 314 may present a vehicle or fleet certificate to the third-party network 130. After presenting the vehicle or fleet certificate, the authentication component 314 may receive confirmation or other indication of acceptance from the third- party network 130 and provide the third-party’s authorized information to an interface component 316. [0047] The memory 310 further include the interface component 316. The interface component 316 can provide various interfaces to allow the authorized third-party access to the vehicle data, executable code or vehicle configurations that facilitate diagnostics or repair. In some embodiments, access to the vehicle data or data communications is set up as a set of common interfaces that do not require custom computing devices or hardware for the third-party. In some embodiments, the interfaces can correspond to vehicle network information that provides access to the values and status of sensors, components, and data collected by the sensors and components of the vehicles. In some embodiments, the sensors can include hardware and software components that can obtain, generate or process a variety of operational or environment information sources that are configured in the vehicle for various purposes. In some embodiments, the sensors can provide raw, collected data to the control component as well as other controls for different functionality. By way of illustration, the information provided to control component by the sensors, controller components, or other processing units can be associated with the operation of the vehicle, such as detected vehicle speed, external temperature measurements, and operational status of the windshield wiper, vision system (e.g., camera inputs), location systems (e.g., GPS systems), timing information, operational status of the components, etc. [0048] With reference now to Figure 3B, an illustrative architecture for implementing the third-party network 130 will be described. As previously described, the third-party network 130 may be part of components or systems that can provide functionality associated with a third-party to present the third-party’s authentication information and facilitate access to vehicle data. [0049] The architecture of Figure 3B is illustrative in nature and should not be construed as requiring any specific hardware or software configuration for the third-party network 130. The general architecture of the third-party network 130 depicted in Figure 3B includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. As illustrated, the third-party network 130 includes a processing unit 322, a network interface 328, a computer readable medium drive 326, and an input/output device interface 324, all of which may communicate with one another by way of a communication bus. The components of the third-party network 130 may be physical hardware components that can include one or more circuitries and software models. [0050] The network interface 328 may provide connectivity to one or more networks or computing systems, such as the network 150 of Figure 1. The third-party network 130 may thus receive information and instructions from other computing systems or services via a network. The third-party network 130 may also communicate to and from memory 330 and further provide output information via the input/output device interface 324. In some embodiments, the third-party network 130 may include more (or fewer) components than those shown in Figure 3B. [0051] The memory 330 may include computer program instructions that the processing unit 322 executes in order to implement one or more embodiments. The memory 330 generally includes RAM, ROM, or other persistent or non-transitory memory. The memory 330 may store an operating system 332 that provides computer program instructions for use by the processing unit 322 in the general administration and operation of the third-party network 130. [0052] The memory 330 may further include an interface software 334. In some embodiments, the interface software 334 provides various interfaces that can be provided to a third-party. For example, the interface software 334 may compile and present vehicle data received from one or more vehicles 110. In some embodiments, the interface software 334 facilitates the interaction between the third-party network 130 and the management network 120. For example, the third-party may use the interface software 334 to interact with the management network 120 to set up an account, create a fleet identification, register and receive a certificate, set a streaming configuration, renew an expired certificate, initiate a vehicle fleet registration, and the like. In some embodiments, the interface can be provided as an application programming interface (“API”) or may be responsive to network endpoints. [0053] The memory 330 may further include authentication software 336 for managing the third-party’s authentication process. In some embodiments, the third-party may have a certificate that is provided by the certificate managing service 116 and in turn can receive a vehicle or fleet certificate. In these embodiments, the authentication software 336 may use the certificate and the vehicle or fleet certificate to establish a direct data stream one or more vehicles 110. In one example, a third-party does not have access rights to connect with any vehicle until the third-party receives a certificate from the management network 120. In some embodiments, to request a certificate, the third-party submits a to the certificate managing service. A certificate request may include setting up an account with the management network 120 and providing information, such as financial or validating information. [0054] In some embodiments, a third-party does not have access to connect to a specific vehicle until the specific vehicle has been added to a fleet associated with the third- party. For example, the third-party may request that a vehicle be added to a fleet associated with the third-party. In another example, a vehicle owner or user may request that the vehicle be added to a fleet associated with the third-party. The transmission of a certificate request or a request that vehicle be added to a fleet can be facilitated through the interface software 334 such as an API or other interfaces. In some embodiments, the interface software 334 interacts with an API associated with the certificate managing service 116. [0055] In some embodiments, the authentication software 336 may interact with one or more vehicles 110 to facilitate a mutual authentication. In these embodiments, the authentication software may interact with the vehicles 110 to present a certificate indicating the third-party identity and authorization to receive vehicle data for the vehicles 110. The authentication software 336 may further interact with the vehicles 110 to receive and validate a vehicle or fleet certificate indicating a vehicle identity and completing the mutual authentication. Once the mutual authentication is complete, the authentication software 336 may enable the interface software 334 to stream data with the vehicles 110. Example Block Diagrams - Interactions [0056] Figures 4A-4B describes techniques by which, in some embodiments, three parties may authorize streaming data from vehicles to third-party networks. For example, the third-party network described in Figures 4A-4B may, in some embodiments, represent a third- party with a need, or want, for streaming data from vehicles. In this example, the third-party may not represent an owner of the vehicle. For example, the third-party may be an entity which rents temporary access to vehicles, may be a ride-sharing entity, and so on. As will be described, the third-party network may obtain streaming data directly from vehicles through interactions with a vehicle, a management network, and optionally a mobile device which is authorized to access, or otherwise provide information to, the vehicles. [0057] Figure 4A is block diagram illustrating an example of interactions between a vehicle, a third-party, and a management network. The overall high-level flow is illustrated as follows: At (1), the third-party configures a stream profile. The stream profile may include one or more identifiers used in selecting specific vehicles or vehicle types. For example, a third-party may use different vehicle types as part of a fleet they control or otherwise operate. The stream profile may additionally include users or user types or other information, generally referred to as a fleet identification. The stream profile may additionally include a configuration of the vehicle data to be collected, processed and transmitted. For example, specific types of vehicle data may be identified for collection (e.g., speed data, self-driving data, and so on as described herein). In some embodiments, the data may correspond to specific events such that the streaming data is event-based streaming. As an example, whenever certain events occur (e.g., on a vehicle) the vehicle may stream data based on the events. The stream profile may additionally include certificate information to be used to stream data to the third-party network, or other information used to configure or maintain authentication information. The stream profile may additionally identify a network location or locations at which the vehicle is to stream data. [0058] In some embodiments, configuring a stream profile enables a third-party to receive vehicle specific information, such as vehicle specific public and private keys, vehicle unique certificates, and other vehicle specific identifiers. In some embodiments, some or all of the vehicle specific information is stored on vehicle specific secure hardware, such as memory 310 of Figure 3A. In some embodiments, the third-party may be configuring an initial stream profile. In other embodiments, the third-party may be renewing or reconfiguring an existing stream profile. In some embodiments, the third-party may be renewing an expired configuration. In each or the above, and other embodiments, the information needed to configure the stream profile may be adapted to suite the embodiment. [0059] At (2), the stream configuration is signed with a fleet private key. In some embodiments, the stream configuration is signed by a computing device associated with the management network using a fleet private key (e.g., a fleet-scoped private key). The fleet private key may be maintained by the management network. In other embodiments, the stream configuration is signed by the third-party, a vehicle owner, or other person or entity with the fleet private key. In such embodiments, one or more fleet private keys may be delegated or consigned to individual third-parties. In some embodiments, the fleet private key is a private key specific to one or more vehicles configured in a fleet. In some embodiments, the requirements that a stream configuration is signed by the fleet private key ensures that a stream configuration can only be set or altered by a person or entity with authorization to do so. In some embodiments, the vehicle specific information is not transmitted to the third-party until the stream configuration is signed with a fleet private key. [0060] At (3), the management network sets a vehicle transmission configuration for transmission to a specific vehicle or fleet. A vehicle transmission configuration may include third-party certificate information. The vehicle transmission configuration may also include certificate authority information. The vehicle transmission configuration may also include a fleet certificate. The vehicle transmission configuration may also include fleet public and private keys. The vehicle transmission configuration may also include data streaming instructions configured to control which vehicle data is to be streamed at what frequency, and any other information needed to facilitate a direct, secure stream between the specific vehicle or fleet between a vehicle and a third-party. [0061] In some embodiments, the vehicle transmission configuration may include an initial set up. In this embodiment, the vehicle transmission configuration made trigger a user confirmation sequence. In some embodiments, a user confirmation sequence may require a vehicle owner or user to be physically present or proximate to the vehicle. For example, the vehicle may require a key input, a confirmation on a local vehicle console, a confirmation using a short-range communication protocol, such as Bluetooth low energy (“BLE”), near field communications (NFC”), and the like, or other similar confirmation techniques. In other embodiments, such as that of Figure 4B, a user confirmation sequence may use a phone or other user terminal that has been paired with the specific vehicle while in close physical proximity. Alternatively, as described below, the user confirmation may be initiated as part of the transmission of data subsequent to establishment of the mutually authenticated communication channel, or in combination. [0062] At (4), the vehicle (e.g., a processor included in the vehicle) validates the transmission configuration and extracts third-party certificate information. In some embodiments the vehicle validates the transmission configuration, in part, by validating a configuration signature with a known fleet certificate authority. For example, the vehicle may validate that the configuration signature is the management network, or other known certificate authority. [0063] In some embodiments the vehicle validates the transmission configuration, in part, by confirming that a fleet certificate primary public key included in the transmission configuration (e.g., used to sign the transmission configuration) matches a fleet public key stored on the secure hardware of the vehicle. For example, the vehicle may confirm that the fleet certificate primary public key matches a fleet public key stored on memory 310. An owner of the vehicle may have control over the presence or use of the fleet public key stored on the secure hardware of the vehicle. For example, an owner may hide the presence of the fleet public key, disable the fleet public key, or remove the fleet public key. In this example, the fleet public key may control the presence or use of the fleet public key by the use of a user confirmation sequence as discussed above. [0064] In some embodiments the vehicle validates the transmission configuration, in part, by validating the configuration signature with a fleet certificate public signing key. In some embodiments, extracting third-party certificate information includes, in part, extracting a third-party authority certificate from the transmission configuration. Ass described herein, the third-party authority certificate may identify a certificate authority which is authorized to validate a server or network location at which the vehicle is to provide streaming data. [0065] At (5), the vehicle and the third-party establish a mutually authenticated connection. For example, in some embodiments the vehicle begins establishing the mutually authenticated connection by initially connecting to the third-party network. The vehicle may connect to the third-party network using any of the features described with respect to network 150. In some embodiments, the connection to the third-party network may be a passive indication that the vehicle is available to stream data. In some embodiments, the connection to the third-party network may be an active request to stream data to the network. [0066] In some embodiments, the third-party network continues establishing the mutually authenticated connection by presenting a third-party certificate. In some embodiments the third-party certificate is a certificate used in mTLS encrypted data communication or other mutual authorization technique. In some embodiments, the third-party certificate is any authorization information used to initialize a direct, secure data stream. In some embodiments the certificate authority granting the third-party certificate is the management network. In some embodiments, the third-party network acted as the certificate authority. In some embodiments, the certificate authority was a party not shown. [0067] In some embodiments, the vehicle continues establishing the mutually authenticated connection by validating the third-party certificate. In some embodiments, the vehicle validates the third-party certificate, in part, by using the third-party authority certificate extracted from the transmission configuration. In some embodiments, the vehicle validates the third-party certificate, in part, by comparing the public key in the third-party certificate with a public key set in the vehicle transmission configuration. [0068] In some embodiments, the vehicle validates the third-party certificate, in part, by confirming the certificate authority that issued the third-party certificate matches the certificate authority of the fleet certificate. In some embodiments the vehicle validates the third-party certificate, in part, by confirming that the expiration date of the third-party certificate has not passed. In some embodiments the vehicle validates the third-party certificate, in party, by confirming that the third-party certificate is identical to the fleet certificate. In some embodiments, the vehicle validates the third-party certificate, in part, by using a unique device certificate and device key stored on the vehicle’s secure hardware. [0069] In some embodiments, the vehicle continues establishing the mutually authenticated connection by presenting a unique device certificate. In some embodiments the unique device certificate is a vehicle specific certificate. In some embodiments the unique device certificate is a certificate used in mTLS encrypted data communication or other mutual authorization technique. In some embodiments, the unique device certificate is any authorization information used to initialize a direct, secure data stream. In some embodiments the certificate authority granting the unique device certificate is the management network. In some embodiments, the third-party network acted as the certificate authority. In some embodiments, the certificate authority was a party not shown. In some embodiments, the unique device certificate is identical to the third-party certificate. In some embodiments, the unique device certificate is distinct from the third-party certificate. In some embodiments, the unique device certificate is stored on the vehicle’s secure hardware. In some embodiments, the unique device certificate is created and certified prior to receiving the vehicle transmission configuration. [0070] In some embodiments, the third-party network continues establishing the mutually authenticated connection by validating the unique device certificate. In some embodiments, the third-party validates the unique device certificate, in part, by comparing the public key in the unique device certificate with a public key received from the management network. In some embodiments, the third-party validates the unique device certificate, in part, by confirming the certificate authority that issued the unique device certificate matches the certificate authority of the management network. In some embodiments, the third-party validates the unique device certificate, in part, by confirming the certificate authority that issued the unique device certificate is the same certificate authority the signed the configuration using the fleet private key. In some embodiments, the third-party validates the unique device certificate, in part, by confirming the certificate authority that issued the unique device certificate matches the certificate authority of the third-party certificate. In some embodiments the third-party validates the unique device certificate, in part, by confirming that the expiration date of the unique device certificate has not passed. In some embodiments the third-party validates the fleet certificate, in party, by confirming that the unique device certificate is identical to the third-party certificate. [0071] In some embodiments, the third-party network continues establishing the mutually authenticated connection by granting streaming access to the vehicle. In some embodiments, the streaming access is one way, with only the vehicle able to transmit to or change data on the third-party network. In some embodiments, the streaming access is two way, with the third-party network able to transmit to or change data on the vehicle. [0072] At (6), the vehicle data is streamed to the third-party network. The vehicle data may be configured by the vehicle transmission configuration. For example, the vehicle transmission configuration may configure which vehicle data transmit and at what frequency to transmit the vehicle data. In some embodiments, the third-party network may stream data to the vehicle. For example, the third-party network may configure vehicle settings, update vehicle software, display messages on the vehicle dash, or the like. In some embodiments, the ability of a third-party network to stream data to a vehicle is established in the stream profile. In some embodiments, the vehicle data is streamed using a public and a private key, such as in a mTLS encrypted transmission control protocol (“TCP”) connection. In some embodiments the third-party public and private keys are identical to the fleet public and private keys. In some embodiments the third-party public and private keys are distinct from the fleet public and private keys. [0073] As described above, in some embodiments, the transmission of vehicle data may be conditional on a user confirmation sequence. In some embodiments, a user confirmation sequence may require a vehicle owner or user to be physically present or proximate to the vehicle. For example, the vehicle may require a key input, a confirmation on a local vehicle console, a confirmation using a short-range communication protocol, such as Bluetooth low energy (“BLE”), near field communications (NFC”), and the like, or other similar confirmation techniques. In other embodiments, a user confirmation sequence may use a phone or other user terminal that has been paired with the specific vehicle while in close physical proximity. [0074] Figure 4B is a block diagram illustrating another example of interactions between a vehicle, a third-party, and a management network. Figure 4B is similar to that of Figure 4A, and the description of Figure 4B is applicable to Figure 4A, however Figure 4B describes use of a mobile device paired to a vehicle (a paired mobile device). Pairing a mobile device, without being constrained by way of example, may refer to the mobile device being trusted by the vehicle. For example, a user account associated with the vehicle may be similarly associated with an application executing on the mobile device. As another example, the mobile device may have a known MAC address to the vehicle. As another example, the mobile device may have been previously paired with the vehicle via Bluetooth. As another example, the mobile device’s public key may be provided to the vehicle. The mobile device may be in wireless communication with the vehicle over a network (e.g., the Internet). The mobile device may also be in local wireless communication with the vehicle (e.g., via Bluetooth). [0075] At (1), the third-party network registers a fleet key with the management network. At (2) the third-party network provides a request to register the fleet key to the mobile device. For example, the mobile device may execute an application which is associated with the third-party network (e.g., is responsive to communications with the third-party network). The application may additionally be associated with the vehicle, for example access to the vehicle may be based on presence of the mobile device. [0076] The mobile device may register the fleet key (e.g., the above-described public key) with the vehicle (e.g., via a wireless connection). The mobile device may also provide a request to the management network to authorize the vehicle receiving the fleet key. The management network may, in some embodiments, determine whether to authorize the registration with the vehicle based on the fleet key received in step (1). For example, the management network may compare the fleet key in step (1) with the fleet key being registered with the vehicle. As another example, the management network may determine that the mobile device is associated with the vehicle (e.g., via a pairing, via a same user account). In some embodiments, the management network may optionally block the registration (e.g., provide information to the vehicle via a wireless connection, for example using a system or admin- level function) based on determining that the registration should not occur. [0077] At (3) the third-party network signs the transmission configuration with the fleet key. For example, the third-party network may sign the configuration using a private key associated with the fleet. Additional description regarding the configuration is included in (3) of Figure 4A above. At (4), the third-party network sets transmission configuration via the management network as described above. For example, the transmission configuration is provided to the management network to be provided to the vehicle. At (5) the vehicle validates the transmission configuration based on the paired fleet key. For example, the signed transmission configuration can be validated (e.g., validation to validly have come from the third-party network) based on the public key registered at step (2). [0078] At (6) a mutually authenticated connection is established between the third- party network and the vehicle. The transmission configuration may include information describing where the vehicle is to connect to provide streaming data (e.g., a server, a network location). The transmission configuration may additionally include information identifying a certificate authority, in some embodiments the only certificate authority, which is to be used to validate a server or network location associated with the third-party network. The transmission configuration may additionally inform how to establish a secure connection (e.g., mTLS). At (7) the vehicle streams data to the third-party network. [0079] As described above with respect to Figures 4A-4B, a third-party may select specific data from individual vehicles, or generally from a fleet of vehicles, they prefer to stream. For example, the streaming data may be provided to a backend (e.g., network location) which is accessible to the third-party. In some embodiments, a user interface may be accessible to the third-party (e.g., to a user associated with the third-party) which includes selectable options associated with specific vehicle data to stream. The user may then provide user input to select certain selectable options, and these selections may form part of the vehicle transmission configuration described herein. [0080] The vehicle may execute software which controls operation of the vehicle. For example, and as described above, the vehicle may execute software which enables self- driving functionality, control of air conditioning, and so on. The software may be updated over time, for example via over-the-air (OTA) updates. The software on the vehicle may aggregate different types of data, some of which may be selected for transmission as streaming data by the third-party network. The selectable options described above may, in some embodiments, be automatically populated based on the software executing on the vehicle. For example, the different selectable options may correspond to the different types of data (e.g., different types of events). The selectable options may also, in some embodiments, be obtained from a schema which is accessible to the third-party and includes options available for selection by the third-party. As may be appreciated, certain types of data may be private or experimental such that access to them should be restricted. [0081] For example, the vehicle software may generate statistics, or otherwise monitor events associated with, a new self-driving feature. It may be disadvantageous for the third-party to have access to data associated with the new self-driving feature, or be aware of it, prior to full release of the new feature. [0082] In some embodiments, aliasing may be used to restrict access to private or experimental features. For example, a vehicle, or fleet of vehicles, may receive an OTA update that adds a new feature (e.g., a new signal or streaming capability, such as a new event). The third-party may be restricted from viewing this new feature when selecting the data to stream. The new feature may be associated with an internal name, such as experimental feature A. The feature may, at a later time, be considered ready for full deployment. The server-side restriction, such as the third-party restriction, may be removed. Thus, the third-party may be able to select the new feature to form part of the streaming data described herein. The selection may be associated with a particular name, for example in a schema or user interface used by the third-party (e.g., ‘self-driving feature A’). Upon selection, the vehicle may use aliasing to associate the name – experimental feature A – with the particular name – self-driving feature A. Thus, when streaming the vehicle may provide the experimental feature A information or events as streaming data to the third-party (e.g., via an interface) with the streaming data may be provided as the self-driving feature A data. Example Flowcharts [0083] Figure 5 is a flowchart of an example process for a vehicle authorization routine to begin streaming data to a third-party network. The process may be performed, for example, by a vehicle (e.g., vehicle 110). One skilled in the relevant art will appreciate that the routines may be implemented by one or more computing devices implementing appropriate hardware and software executable codes and modules to provide the identified functionality. [0084] Beginning at block 502, the vehicle receives a vehicle transmission configuration. The vehicle transmission configuration may include some or all of the elements as described at (3) of Figure 4A. At block 504, the vehicle extracts the fleet certificate from the vehicle transmission configuration. The fleet certificate may include a fleet validation public key such as the fleet public key or the third-party public key as described in Figure 4A. At block 506, the vehicle validates the fleet certificate authority. At block 508, the vehicle validates the fleet certificate public key. At block 510, the vehicle validates the transmission configuration signature. At block 512, the vehicle extracts a third-party authority certificate. At block 514, the vehicle establishes a mutually authenticated connection with a third-party. The routines of Figure 5 may include some or all of the elements described in Figure 4A-4B. [0085] Figure 6 is a flowchart of an example process for a third-party authorization routine to begin streaming data associated with a vehicle. The process may be performed, for example, by a third-party (e.g., third-party 130). One skilled in the relevant art will appreciate that the routines may be implemented by one or more computing devices implementing appropriate hardware and software executable codes and modules to provide the identified functionality. [0086] Beginning at block 602, the third-party receives a vehicle connection. Block 602 may include some or all of the elements described at (5) of Figure 4A. At block 604, the third-party presents a certificate to the vehicle. Block 604 may include some or all of the elements described at (5) of Figure 4A. At block 606, the third-party received a device certificate from the vehicle. Block 606 may include some or all of the elements described at (5) of Figure 4A. At block 608, the third-party validates the device certificate. Block 608 may include some or all of the elements described at (5) of Figure 4A. At block 610, the third-party grants streaming access to the vehicle. Block 610 may include some or all of the elements described at (5) and (6) of Figure 4A. [0087] Figure 7 is a flowchart of an example process for an illustrative routine to register a vehicle to a fleet. The process may be performed, for example, by a vehicle (e.g., vehicle 110). As described herein, a fleet may be one or more vehicles associated with a single streaming profile. A streaming profile may include some or all of the elements described at (1) of Figure 4A. One skilled in the relevant art will appreciate that the routines may be implemented by one or more computing devices implementing appropriate hardware and software executable codes and modules to provide the identified functionality. [0088] Beginning at block 702, a vehicle receives a request to join a fleet. Such a request may be generated in a streaming profile configuration as described at (1) of Figure 4A. At block 704, the vehicle enters a registration state. In some embodiments, the registration state includes displaying or sending a message to a vehicle owner that the vehicle has been requested to join a fleet. In some embodiments, the message is displayed on a console of the vehicle. In some embodiments, the message is displayed on an application or user terminal associated with the vehicle owner. In some embodiments, the message is transmitted to the vehicle owner via a text transmission, SMS message, email, or the like. [0089] At block 706, the vehicle receives a registration confirmation. The registration confirmation may include some or all of the elements described at (3) of Figure 4A. At block 708, the vehicle sends a registration confirmation. In some embodiments, the registration confirmation is data indicating the vehicle has been added to a fleet. In some embodiments, the registration confirmation includes a message to the vehicle owner using one or more of the techniques described at block 704. In some embodiments, the registration confirmation includes data sent to a management network, such as management network 120. In some embodiments, the registration confirmation includes data sent to a third-party, such as third-party network 130. Other Embodiments [0090] All of the processes described herein may be embodied in, and fully automated, via software code modules executed by a computing system that includes one or more computers or processors. The code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device. Some or all the methods may be embodied in specialized computer hardware. [0091] Many other variations than those described herein will be apparent from this disclosure. For example, depending on the embodiment, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence or can be added, merged, or left out altogether (for example, not all described acts or events are necessary for the practice of the algorithms). Moreover, in certain embodiments, acts or events can be performed concurrently, for example, through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. In addition, different tasks or processes can be performed by different machines and/or computing systems that can function together. [0092] The various illustrative logical blocks, modules, and engines described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a processing unit or processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor may also include primarily analog components. For example, some or all of the signal processing algorithms described herein may be implemented in analog circuitry or mixed analog and digital circuitry. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few. [0093] Conditional language such as, among others, “can,” “could,” “might” or “may,” unless specifically stated otherwise, are understood within the context as used in general to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment. [0094] Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (for example, X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present. [0095] Any process descriptions, elements or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or elements in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown, or discussed, including substantially concurrently or in reverse order, depending on the functionality involved as would be understood by those skilled in the art. [0096] Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted to include one or more described items. Accordingly, phrases such as “a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C. [0097] It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure.

Claims

WHAT IS CLAIMED IS: 1. A system for providing vehicle data access, the system comprising one or more processors and non-transitory computer storage media storing instructions that when executed by the one or more processors, cause the one or more processors to: respond to connection information from a third-party network, the connection information including a public fleet key, wherein the received public fleet key is used to authorize a vehicle to receive the public fleet key from a mobile device paired with the vehicle; analyze a vehicle transmission configuration to be transmitted to the vehicle, the vehicle transmission configuration including indications of types of vehicle data to be streamed to the third-party network, information describing how the vehicle is to connect to the third-party network, and a particular certificate authority authorized to validate the third-party network, wherein the vehicle transmission configuration is signed based on a private fleet key associated with the third-party network; and transmit the vehicle transmission configuration to the vehicle, wherein the vehicle identifies, based on the vehicle transmission configuration, one or more network locations at which to stream the vehicle data, wherein the vehicle validates the network locations using the particular certificate authority, and wherein the vehicle is configured to transmit the types of vehicle data to the third-party network.

2. The system of claim 1, wherein the instructions further cause the one or more processors to: provide, to the third-party network, a public schema identifying available types of vehicle data, wherein the vehicle transmission configuration indicates a subset of the available types of vehicle data.

3. The system of claim 1, wherein the vehicle stores the fleet public key based on receipt of the fleet public key from the mobile device, and wherein the vehicle validates the vehicle transmission configuration using the fleet public key.

4. The system of claim 3, wherein the mobile device is in wireless communication with the vehicle over a network or wherein the mobile device is in local wireless communication with the vehicle.

5. The system of claim 1, wherein a particular type of vehicle data is assigned an alias, and wherein the vehicle associates the particular type of vehicle data with the alias.

6. The system of claim 5, wherein the vehicle generates event data corresponding to the alias, and wherein the vehicle associates the event data with the particular type of vehicle data.

7. The system of claim 1, wherein transmission occurs via an encrypted communication link between the third-party network and the vehicle.

8. A method implemented by a system of one or more processors, the method comprising: responding to connection information from a third-party network, the connection information including a public fleet key, wherein the received public fleet key is used to authorize a vehicle to receive the public fleet key from a mobile device paired with the vehicle; analyzing a vehicle transmission configuration to be transmitted to the vehicle, the vehicle transmission configuration including indications of types of vehicle data to be streamed to the third-party network, information describing how the vehicle is to connect to the third-party network, and a particular certificate authority authorized to validate the third-party network, wherein the vehicle transmission configuration is signed based on a private fleet key associated with the third-party network; and transmitting the vehicle transmission configuration to the vehicle, wherein the vehicle identifies, based on the vehicle transmission configuration, one or more network locations at which to stream the vehicle data, wherein the vehicle validates the network locations using the particular certificate authority, and wherein the vehicle is configured to transmit the types of vehicle data to the third-party network.

9. The method of claim 8, further comprising: providing, to the third-party network, a public schema identifying available types of vehicle data, wherein the vehicle transmission configuration indicates a subset of the available types of vehicle data.

10. The method of claim 8, wherein the vehicle stores the fleet public key based on receipt of the fleet public key from the mobile device, and wherein the vehicle validates the vehicle transmission configuration using the fleet public key.

11. The method of claim 10, wherein the mobile device is in wireless communication with the vehicle over a network or wherein the mobile device is in local wireless communication with the vehicle.

12. The method of claim 8, wherein a particular type of vehicle data is assigned an alias, and wherein the vehicle associates the particular type of vehicle data with the alias.

13. The method of claim 12, wherein the vehicle generates event data corresponding to the alias, and wherein the vehicle associates the event data with the particular type of vehicle data.

14. The method of claim 8, wherein transmission occurs via an encrypted communication link between the third-party network and the vehicle.

15. A non-transitory computer storage media storing instructions that when executed by a system of one or more computers, cause the one or more computers to: respond to connection information from a third-party network, the connection information including a public fleet key, wherein the received public fleet key is used to authorize a vehicle to receive the public fleet key from a mobile device paired with the vehicle; analyze a vehicle transmission configuration to be transmitted to the vehicle, the vehicle transmission configuration including indications of types of vehicle data to be streamed to the third-party network, information describing how the vehicle is to connect to the third-party network, and a particular certificate authority authorized to validate the third-party network, wherein the vehicle transmission configuration is signed based on a private fleet key associated with the third-party network; and transmit the vehicle transmission configuration to the vehicle, wherein the vehicle identifies, based on the vehicle transmission configuration, one or more network locations at which to stream the vehicle data, wherein the vehicle validates the network locations using the particular certificate authority, and wherein the vehicle is configured to transmit the types of vehicle data to the third-party network.

16. The computer storage media of claim 15, wherein the instructions further cause the one or more computers to: provide, to the third-party network, a public schema identifying available types of vehicle data, wherein the vehicle transmission configuration indicates a subset of the available types of vehicle data.

17. The computer storage media of claim 15, wherein the vehicle stores the fleet public key based on receipt of the fleet public key from the mobile device, and wherein the vehicle validates the vehicle transmission configuration using the fleet public key.

18. The computer storage media of claim 17, wherein the mobile device is in wireless communication with the vehicle over a network or wherein the mobile device is in local wireless communication with the vehicle.

19. The computer storage media of claim 15, wherein a particular type of vehicle data is assigned an alias, and wherein the vehicle associates the particular type of vehicle data with the alias.

20. The computer storage media of claim 19, wherein the vehicle generates event data corresponding to the alias, and wherein the vehicle associates the event data with the particular type of vehicle data.

21. The computer storage media of claim 15, wherein transmission occurs via an encrypted communication link between the third-party network and the vehicle.

22. The computer storage media of claim 15, wherein the third-party network is configured to validate the vehicle based on a vehicle certificate authority.

23. A method implemented by a processor included in a vehicle, the method comprising: receiving, via a mobile device paired with the vehicle, a fleet public key associated with a third-party network, wherein the vehicle is configured to generate event data associated with different types of vehicle data, and wherein the event data is generated based on use of sensors or based on operation of the vehicle by a user; analyzing a vehicle transmission configuration received from a management network associated with the vehicle, the vehicle transmission configuration including indications of particular types of vehicle data to be streamed to the third-party network, information describing how the vehicle is to connect to the third-party network, and a particular certificate authority authorized to validate the third-party network, wherein the vehicle transmission configuration is signed based on a private fleet key associated with the third-party network, and wherein the processor validates the vehicle transmission configuration based on the fleet public key; and transmitting the particular types of vehicle data to the third-party network, wherein the vehicle identifies, based on the vehicle transmission configuration, one or more network locations at which to stream the particular types of vehicle data, and wherein the vehicle validates the network locations using the particular certificate authority.