Automotive and Transportation Business Group (original) (raw)

The mission of the Automotive and Transportation Group was to act as an incubator of ideas for standardization for connected vehicles and the broader transportation data space. It had produced some early draft specifications for making vehicle signals available in a browser runtime as a first class object. Those specifications were the basis for launching the W3C Automotive Working Group (which closed on 22 February 2024).

Fuller description of the scope is in the charter.

Group's public email, repo and wiki activity over time

Final reports / licensing info

Date	Name	Commitments
2022-02-08	VSSo: Vehicle Signal Specification Ontology	Licensing commitments
2022-02-08	VSSo Core: Vehicle Signal Specification Core Ontology	Licensing commitments
2014-05-14	Vehicle Data Interfaces	Licensing commitments
2014-05-14	Vehicle Information API	Licensing commitments

W3C automotive big data task force

W3C’s Automotive activity is comprised of a Business Group and Working Group. The Business Group acts as an incubator for exploring areas of potential standardization and the Working Group is rigidly chartered for delivering specific standards.

The primary goal for this work is to create a rich on-board application ecosystem that can exist across manufacturers. By defining services we make it possible for applications to be in HTML5, Qt, Java (Android) or essentially any programming platform. Participants include auto manufacturers, tier ones, tech companies, solution providers, researchers, telematics services providers and fleet managers. Perspectives from a diverse set of stakeholders better ensures the resulting solutions address their myriad of needs.

Presently the W3C Automotive Working Group is finalizing the Vehicle Information Service Specification (VISS) and progressing on the Member Submission made by the Volkswagen Group, Volkswagen Infotainment Web Interface (ViWi). ViWi is being referred as RESTful Service Interface (RSI) within the W3C Auto group which is examining how to converge the two approaches.

VISS has reached Candidate Recommendation (CR) in the W3C standards process. At this point the specification is expected to be mature and in order to leave CR must have an accompanying test suite to ensure interoperability and implementation reports demonstrating feasibility. We have a test suite and several implementation reports with expressed intention from at least two auto manufacturers of putting it into production vehicles. In addition to implementations being done by OEM and Tier 1s, there is an IoT proof of concept done by ETRI and Samsung for OCF.

ViWi is in production vehicles with the plan of being rolled out across VW Groups’ brands. With multiple brands each with a different architecture, VW Group is a microcosm of the auto industry. They want to be able to create applications that run across all their brands and for a common application platform to exist for the industry as a whole so as to be able to attract content providers to create applications. In addition to vehicle signals, ViWi also has modules using the same paradigm for media library and services, mixer and content delivery network (CDN). Using the same approach a researcher has presented a draft for rudimentary navigation/location based services capabilities and we are talking with stakeholders to develop a more robust solution. Other candidate modules are under discussion.

In addition to being able to create applications with these standards interacting with the operator and passengers, there are multiple use cases these specifications enable that require no human interaction including notably data sampling and edge computing. This is garnering interest from OEMs, fleet managers, telematics service providers, regulators and others.

In May 2018 we launched a task force to look at the broader automotive big data picture. The goal of this task force is to identify the various needs, how W3C VISS/RSI and other standards from W3C and elsewhere fit in, perform a gap analysis and work on solutions for the remaining components.

Previously we had been in communication and received a presentation from some participants (Daimler and PSA) of the Extended Vehicle and Neutral Server effort at ISO. We have been in more communication with the organizers of Neutral Vehicle project that aims to take that work further, producing open source proof of concept systems. We are also coordinating with Sensoris and seek to at least work on a data mapping between the two approaches.

There will be other potential collaborations including but not limited to W3C WebAppSec and WebAuthN Working Groups, W3C Privacy Interest Group, a proposed cybersecurity research group at MIT where W3C is headquartered, nearby US DOT Volpe, Genivi and AutoISAC.

There have only been a few task force teleconferences so far, first call was a review of potential focus areas. Several, such as data transmission leveraging W3C EXI, were deemed out of scope at least for the time being. The topics being taken up initially are ontology work undertaken by a researcher at EURECOM/Institut
Telecom in collaboration with BMW, capturing consent based on models being developed by Caruso and Fraunhofer, and data contracts based on direction from Geotab.

The ontology work is being applied to the data model used by VISS. This metadata enables better data management, governance, analytics and for both developers and AI to disseminate information.

Demonstrable and enforceable user consent of information is paramount to sound privacy protection when sharing information with designated third parties and required by law in the EU (GDPR compliance).

Data contracts are necessary because otherwise data can be meaningless without knowing how it was collected. For instance sampling speed at one minute intervals can miss rapid acceleration and hard breaking events. A data contract is necessary to convey the methodologies used to handle peaks, troughs, event listeners and the like when sampling data.

More areas have been identified for further exploration. Participants are presenting solutions to these problems and will be making proposals for potential standards. Interested parties are encouraged to get involved in the W3C Automotive WebPlatfom Business Group.

Can the Web help make automotive payments more secure?

The Automotive Web Payments Task Force is exploring whether the emerging Web Payment API (called “Payment Request”) can be used in automotive use cases to improve the user experience and reduce financial fraud.

Fraud is rampant in fueling. My personal observations are mostly US-centric but have had similar experiences internationally. As gas prices increased dramatically in the US in 2008, so did theft of fuel. Incidents of people filling up their cars and driving away without paying were widely reported. As a result it is rare now to see places that will let you fuel up before paying, trust in the consumer is gone. You now have to pay at the pump with a debit or credit card or go inside and prepay before fueling.

Perhaps as a result, theft of payment credentials has also increased. Card skimmers are devices placed externally over a credit/debit card magnetic reader or hidden inside it that capture credit card information to relay or be later collected by an attacker. They are unfortunately becoming commonplace on ATM machines and gas station pumps.

The upshot: unattended devices in the physical world can be difficult to adequately protect from tampering.

Basic, widely used locks are not secure but merely a mild deterrent. They are easily overcome with “bump keys” (internet search shows how trivial this is), lock picking (more instructional videos online plus learning locks and pick sets are cheap) and spare copies of keys can be made or acquired. Cars have long moved on from simple keys to more complex mechanical locks that make it more difficult to copy keys. They also embed RFID as essentially a second factor authentication on the physical key. These more advanced keys are greatly improved over the more common ones but not without security flaws as researchers are finding ways to overcome the various protection schemes. The locks protecting gas station pumps are of the simpler variety and to facilitate maintenance sometimes commonly keyed, a single key can unlock multiple pumps sometimes even across different stations.

Last summer my eldest daughter had her credit card number stolen. Her bank informed her it was most likely from a card skimmer at a gas station. I was already aware of this phenomenon and only use ATMs at banks since they have security cameras and better overall monitoring practices. Based on her experience I became more diligent about looking for the tamper stickers that indicate a pump might have been opened to insert a skimmer. These are cheap stickers anyone can purchase. A casual observer unfamiliar with the specific sticker used by a given station will not know whether it was affixed by the attendant or an attacker. On a road trip to Upstate New York last Fall my own credit card was stolen by a skimmer. The tamper sticker at the gas station I believe was responsible seemed incredibly cheap and at the time wondered if an attacker might have placed it themselves. A physical card with magnetic stripe was manufactured and used a couple days later at a grocery store in Long Island, NY. The theives’ use of the card within the same state, in the ordinary scenario of buying groceries, was an attempt to make the transaction seem innocuous to the credit card company’s fraud algorithm.

Having a credit card stolen is not a pleasant experience. Fortunately I was not liable for the fraudulent charges but I did have to go and update all the places that card was used for automated payments. A couple weeks ago I was fueling up near the interstate closest to home, a gas station I frequent and I noticed there was no sticker after I swiped my card. I saw all the other pumps at the station had a sticker present and thought I was going to have to repeat the exercise. To spare other customers I went into the service station to speak with the clerk. She informed me they simply ran out of stickers and they check for skimmers every morning. The problem is that rampant.

We are now hearing about gas station pumps being hacked, installing malicious programs to cheat consumers out of gas. Trust in the physical card systems and pumps is gone.

Credit card companies assess the probability of fraud on every single transaction within seconds based on elaborate algorithms and various data points including past purchasing behavior before approving a transaction. Credit cards in the US only recently became equipped with chips which, although suffering from various flaws being discovered, are a marked improvement over magnetic strips. Deployment has been slow and they are generally not seen in US fueling stations but are present in Europe and other parts of the world. In other countries it is also common to require a pin as another authentication factor in addition to the chipped card to complete a transaction. That practice is not in use in the US but due to fuel fraud, card holders are prompted to enter their postal zipcode as a pin when purchasing gas. Since the magnetic strip contains the cardholder’s name in plain text an attacker can look for local addresses matching that name online relatively easily, depending on how common the name is, and obtain the not-so-secret pin (zipcode).

Basic multi-factor authentication is based on something you have and something you know. Magnetic strips are easy to copy and for an attacker to have and a zipcode is knowable to cardholder and the internet.

We also hear regularly about website compromises and the amount of credit card and other personal data that gets stolen, trust in the merchant is eroding. Online consumers often abandon shopping carts, hesitant to trust another site with their credit card. W3C’s Web Payments API can mitigate risk by enabling a streamlined user experience without requiring the merchant to store payment credentials, and by facilitating the use of more secure payment methods (such as tokenization and with strong authentication). Tokenization involves the use of dynamic data to avoid replay attacks; it has been designed to work with existing credit card processing systems, using the same data points. What is most interesting is that given the complexity of changing out payment processing systems, they instead adapt to conform within existing methodologies and data structure. We can overload values with pertinent information coming from the vehicle.

As mentioned fraud detection algorithms are data driven based on past purchasing behavior, including last known geographic location of the cardholder, and the transaction itself. Information about the vehicle including its identification number (VIN), its fuel level and other stateful information, fuel capacity and location are available through the service APIs being worked on in the W3C Automotive standards activity and could be communicated to the payment provider along with the merchant information via the W3C Payments Request API. When paymentItem is “gasoline” and shippingType is “pickup” then the payment provider can look at shippingAddress for that station’s Point of Interest (POI) address to see if it aligns with the merchant information before approving the transaction.

The same and more concerns apply to EV charging.

We do not have all the answers yet, join the discussion and be part of the solution.

Deprecating earlier WebIDL based Automotive specifications

The W3C Automotive Webplatform Business Group worked on a pair of WebIDL specifications for exposing vehicle signals as a first class object within a browser runtime. They were published as final reports in December of 2014 to be handed over to a newly chartered W3C Automotive Working Group to bring them through the W3C standards process. Based on feedback from various other groups at W3C, including the Technical Architecture Group, and how the Auto industry is split between HTML5 and Qt for developing applications for head units we switched to a service approach (VISS) in July of 2016. A service also allows for headless applications that do not need to operate in HTML5 or Qt, example being data collection for fleet management.

In December of 2016 The VW Group joined W3C and submitted their similar approach (ViWi) for consideration. As prototypes were underway and we wanted to further our understanding of issues from implementation experiences the group resolved to continue VISS work and formed a task force for converging the two approaches for next version specification (RSI). The group intends to complete VISS and recharter for RSI end of 2017 or early 2018 and publish First Public Working Drafts (FPWD). RSI has modules for other services that will be made available, media services, media libraries, CDN, notifications with more planned Location Based Services (LBS).

REST Services Interface Task Force

The REST Services Interface (RSI – formerly VIWI) Task Force has been meeting regularly. We would like to see more participation especially in implementing the specification to prove it out. Please check out the RSI Task Force Wiki. We are in the process of scheduling regular meetings.

Here is quick summary of RSI:

Volkswagen submitted RSI to the W3C, in December of 2016, as it is in-line with the HTML5 and “services” direction the Automotive Working Group and Automotive and Web Platform is pursuing. The following domains were part of the initial submission:

[Protocol](http://Volkswagen Infotainment Web Interface protocol definition)
Car
Content Deliver Network (CDN)
Media
Media Library
Mixer

The RSI work is focused on guidelines and rules for designing REST APIs that are extended with a WebSocket subscribe mechanism for delivering high frequency data, avoiding polling. The [Protocol](http://Volkswagen Infotainment Web Interface protocol definition) specification describes the main REST/WebSocket model with the Domain specifications defining domain specific information models.

An open reference server implementation and framework can be found here and may be used for implementations. Ideally code will be committed back to this repository.

The Task Force plans on focusing on Media and Location Based Services (LBS) domains to start with academic papers for LBS in the works.

Please join us by reaching out to the group, following the group, following the GitHub repositories, and following us on Twitter #w3cauto.

Recent Face to Face in Birmingham, UK

The Automotive and Web Business Group and the Automotive Working Group held a face to face meeting in Birmingham UK in conjunction with GENIVI on May 10 – 11.

The group liaised with Web Payments and discussed potential usage in Automotive. There will be continued liaison between the two groups.

Also, the Volkswagen submitted REST Services Interface (RSI – formerly VIWI) was discussed in detail. The RSI Task Force will continue to meet regularly

Minutes are here:

October 23, 2015 – Business Group F2F at GENIVI AMM In Seoul

We will be having a face to face meeting on October 23, 2015 in Seoul Korea in conjunction with the GENIVI All Member Meeting. If you plan on attending please register for the meeting here:

https://www.w3.org/2002/09/wbs/61259/20151023_BG_F2F_SEOUL/

Hotel information and GENIVI registration can be found here:

http://genivi.org/amm-2015-october

I hope to see you there!

Call for Final Specification Commitments for Vehicle Data Interfaces

On 2014-12-04 The Automotive and Web Platform Business Group published the following specification:

Vehicle Data Interfaces.

This is a call for Final Specification Commitments. To provide greater patent protection for this specification, participants in the Automotive and Web Platform Business Group are now invited make commitments under the W3C Community Final Specification Agreement by completing the commitment form. Current commitments are listed on the Web. There is no deadline for making commitments.

If you have any questions, please contact the group on their public list: public-autowebplatform@w3.org. Learn more about the Automotive and Web Platform Business Group.

Call for Final Specification Commitments for Vehicle Information API

On 2014-12-04 The Automotive and Web Platform Business Group published the following specification:

Vehicle Information API.

If you have any questions, please contact the group on their public list: public-autowebplatform@w3.org. Learn more about the Automotive and Web Platform Business Group.

First Draft of Vehicle Data Interfaces published by Automotive and Web Platform Business Group

On 2014-05-14 the Automotive and Web Platform Business Group published the first draft of the following specification:

Vehicle Data Interfaces.

Participants contribute material to this specification under the W3C Community Contributor License Agreement (CLA).

If you have any questions, please contact the group on their public list: public-autowebplatform@w3.org. Learn more about the Automotive and Web Platform Business Group.

First Draft of Vehicle Information API published by Automotive and Web Platform Business Group

On 2014-05-14 the Automotive and Web Platform Business Group published the first draft of the following specification:

Vehicle Information API.

Participants contribute material to this specification under the W3C Community Contributor License Agreement (CLA).

If you have any questions, please contact the group on their public list: public-autowebplatform@w3.org. Learn more about the Automotive and Web Platform Business Group.