Skip to toolbar

Community & Business Groups

Automotive and Web Platform Business Group

The mission of the Automotive and Web Platform Business Group is to act as an incubator of ideas for standardization for connected vehicles. 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 in order to bring them through the W3C Recommendation Process. The Auto Working Group has since changed to service specifications to expose signals in a broader range of environments, HTML5, Qt and headless applications in any programming language running on vehicle head units.

Currently we have task forces on:
  • Privacy and Security
  • Media tuning
  • Location Based Services
  • Web Payments
  • Merging VW submission with Auto WG spec (RSI)

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

final reports / licensing info

date name commitments
Vehicle Information API Licensing commitments
Vehicle Data Interfaces Licensing commitments

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

Publish Reports

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:

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 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:

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:

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.

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:

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:

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-04-25 the Automotive and Web Platform Business Group published the first draft of the following specification:

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.