<ted> [agenda review]

Introductions

<ted> scribenick: ted

Shinjiro Urata, Access

Junichi Hashimoto, KDDI

Tatsuhiko Hirabayashi, KDDI

Kazuyuki Ashimura, W3C

Adam Abramski, Intel

Paul Boyes, OpenCar

Yingying Chen, W3C

Qing An, Alibaba

Kevin Gavigan, JLR

Adam Crofts, JLR

Peter Winzell, Mitsubishi

Ted Guild, W3C

Wonsuk Lee, ETRI

Daisuke Ajitomi, Toshiba

Hidenobu Ito, Fujitsu

@@3_second_row_names

Agenda

Adam: review spec process, timeline check, what needs to be done
... if it is interesting to the group give a summary of the BG meeting and presentation Paul, Ted and I made at Genivi AMM session
... implementations and testing (both required by the specs)
... Generic Sensor API with Tobie Langel
... Security, possibly engage with some WoT folks this or tomorrow afternoon

<kaz> Toru_Kawaguchi(Panasonic), Mikio_Sasaki(Mitsubishi_Electric), Jet_Villegas(Mozilla), Hiroto_Inoshita(Keio_Univ.), J_Alan_Bird(W3C)

Adam: tomorrow morning is pretty busy with breakout session starting with Web Payments in room 206 (2nd floor)
... after we will liaise with Geolocation back in this room
... both sessions have detailed agenda [on screen and in email archives]
... after lunch meeting with TV Control API CG who is working with us on Media Tuner API (BG activity) and avoid duplicating work

Specifications Update

Paul: we have had a flurry of activity, reviewing and resolving issues
... although there are still some outstanding issues it is quieting down
... we need to move on our timeline toward REC
... we are required to have at least two implementations to advance in W3C specification status

<kaz> ted: explains how to use the W3C Github repository, and ask if we could remove the master branch and use the gh-pages branch for spec publication

-> https://lists.w3.org/Archives/Public/public-automotive/2015Oct/0003.html Proposal to switch to gh-pages branch for Echidna

RESOLUTION: editors and chairs agree to accept proposal to switch to gh-pages for automated publishing

Paul asks JLR about implementation status

Adam and Kevin will get confirmation from Paul Wheller before sharing

Paul: about the infamous issue 32, in spite of the back and form I believe the current status is to stay as is due to existing [partial] implementations

Wonsuk: we left it for now but wanted to discuss with Tobie and GeoLocation WG to get their advice which we can do this week as part of our breakout sessions
... we can also defer until a later stage in the recommendation process (as it tends to get more attention and review then)

Paul: there are a few outstanding issues

Adam: one is contingent on issue 32 refactoring

https://github.com/w3c/automotive/issues/56

action ted to close issue 56 as out of scope/not relevant to our WG based on conversations/understanding from JLR and Volvo at Genivi

<trackbot> Created ACTION-10 - Close issue 56 as out of scope/not relevant to our wg based on conversations/understanding from jlr and volvo at genivi [on Ted Guild - due 2015-11-02].

[based on JLR RVI proposal and Gunnar explanation of where in the stack offline/wakeup interactions will take place - outside of web runtime]

Adam: one of the reference implementations we hope to get is from Genivi in their stack. Paul, Ted and I are working with them to get commitment and timeline

Paul: it might be helpful to explain what Genivi is to some in the room

Adam: Genivi is comprised of 180 or so organizations, OEM, tier 1, silicon etc

<hira> http://www.linuxplumbersconf.org/2014/ocw/sessions/2559

Adam: they are working together on creating a code stack, much of which is open source, on many aspects of connected vehicle

http://genivi.org

Adam: they have been coordinating with W3C extensively and overlap of members between the different consortia
... we have been colocating our business group meetings with their all member meeting and did so last week in Seoul

Wonsuk: who is leading that implementation? I see a mix of different companies and outside contributors

Paul: from the OEM perspective they want a common stack to be able to integrate with a number of prospective tier ones
... they have common components (eg definition on interacting with linux bluez - bluetooth)
... they define abstract interfaces and reference implementations of those interfaces

Ted: their stack is designed so you can supply alternate implementations of the different blocks in the stack

Paul: they did not want to get into the Web level HMI so are bringing their ideas in that area to W3C

<kaz> GENIVI Compliant page

Paul: to benefit from wider web perspective and other W3C working groups
... Auto Grade Linux (part of the Linux Foundation) is doing similar to Genivi
... Gunnar from Volvo is the architect for Genivi and gave us their perspective on security approach

<kaz> Automotive Grade Linux

PeterW: is there anyone leading their reference implementation of the W3C Vehicle specs?

Paul: we are working on that with them and they're aware

Adam: the expert group (their version of WG) of theirs that makes the most sense on creating a reference implementation is their network group

Ted: @@harman, qnx, discussion with p-robin, jlr?. more the merrier, need to get more details on status and timeline

PeterW: QT too (in their web runtime)

Adam: Access may be providing us an update too

Jet: Mozilla is interested in providing a runtime for automotive
... where should we get going in that effort? AGL, Genivi, W3C?

Paul: all of the above
... you'll want to look at the other browser vendors effort like crosswalk. we see many doing this in chromium at present

Adam: there is a QT + WebKit browser proof of concept from Pelagicore in the Genivi Network group that you should also look into

Paul: again maybe Access as another browser vendor might want to speak up

<kaz> GENIVI Proof-Of-Concept

Shintaro: developing a browser based on WebKit but not using Qt

DaveR: we have some similar work in W3C Widgets that this is similar to that might be worth looking at further
... in the automotive context speed is really critical for UI interactions

Kevin: it varies based on the data but absolutely

DaveR: a non-native implementation would be slower

Paul: auto industry is looking at html5 from my perspective is to leverage web technologies, draw from large pool of web developers, own their ui

Kevin: there are limits to native as well. we want a rich user experience that web allows

DaveR: I am reminded of native vs web apps on phones

Kevin: there are some very big differences and challenges in those two platforms (auto and smartphones)

Paul: some of this data is coming through with some lag eg 20ms
... not all of the data is useful either

Kevin: optimizing startup time is a bigger issue than performance of web platform

<kaz> [ break ]

Testing

Adam: anyone care to start us off?

Kaz: it is required with Proposed Rec
... there are two options, one to use the test framework created by html5 group
... i believe there will be a breakout session for testing browsers in tvs on wednesday

Ted suggests a couple volunteers join this session, take notes to send to group mailing list and report on a subsequent call

Peter Winzell volunteers

<kaz> breakout session ideas

Qing_An: I intend to setup a breakout session on Wednesday as well on LBS to try to get more people involved in our activity there

scribe: I am also looking forward to summary of this topic from BG meeting last week and our liaison session with GeoLocation tomorrow

Adam: are the times set for this session

<kaz> kaz notes there are several sessions on testing in general, and would suggest we attend

Kaz: it is an "unconference" model so no set times until it starts

<wonsuk> GitHub Repos for test suites for Web Platform specifications—including WHATWG, W3C and others: https://github.com/w3c/web-platform-tests

<kaz> TV testing session

<wonsuk> Geolocation API Test Suite: http://dev.w3.org/geo/api/test-suite/

<kaz> implementation report

Genivi All Members Meeting and Business Group F2F in Seoul

Adam: we talked about presentation we made to session track at Genivi AMM. LBS+voice, Security, Genivi multi-user
... the presentation Paul, Ted and I made went well and was well attended (will send slides to ml)
... Ted gave overview of W3C and draw comparisons to Genivi model. I covered BG activity and ambitions, Paul WG spec work and Junichi's Security Talk
... I am going to be promoting our W3C standards work on Genivi Projects site with Jeremiah Foster to increase awareness of our activity
... there was discussion of various efforts like SmartDevice for integration of devices and head unit better

Ted: believe I mentioned during that session on this topic how that should coordinate with W3C Device API WG

Paul: another thing that came up was specification versus working software. that is one of the areas of contention between AGL and Genivi
... also how there are many different competing standards bodies in this space. For security there is a consortium of European auto makers
... Toyota attended that meeting and is going to use SDL
... time to implementation is very important for AGL people. OEM want things that work now and don't want to wait on standards even though their time to market usually spans a few years

PeterW: re smartlink is anyone looking at android out?

<yingying> http://projects.genivi.org/smartdevicelink/home

[Dave Singer leaves]

Adam: we would like apple or google to get involved

PeterW: would like to have a common api to android out and apple carplay

Adam: are they going to have access to CAN?

Paul: not unless they work with the OEMs

Kevin: issue is how to do so in a safe controlled way

<Kev_G> Jaguar In Control Apps: https://www.jaguar.com/jaguar-range/f-type/features-options/in-control-apps.html

Media Tuner

Adam: iHeart and Pandora aren't present but progressing. Paul or I will try to get more people from BG involved and we'll meet with TV Controller API CG later

<Paul> http://www.w3.org/community/autowebplatform/wiki/Main_Page/MediaTunerTaskForce

Adam: also we want to get more activity around LBS this week and potentially start a draft spec in BG like we did with the vehicle signal spec to later hand over to the WG
... I see Alibaba and PSA leading that but obviously welcome others interested
... Philippe Colliot(PSA) started looking over Qing An's use cases
... and have a native implementation to potentially map onto

Qing An: for LBS should we do this in BG or WG?

Adam: BG for now

Ted: Harman is in the BG, not very active at present but has been active in Genivi LBS. I found some people there to follow up with by email to see if we can engage them

<yingying> http://projects.genivi.org/ivi-navigation/

Ted: also from my notes on Genivi LBS I see Continental (also a BG participant but not very active in BG lately) as another to reach out too
... Volvo and Tomtom would be good to reach out to
... and in general if there are engineer for this (lbs) or other topics you know at other organizations who you feel would be beneficial in advancing this spec work, please introduce them to the chairs, Kaz or I

TU Automotive in Tokyo

Kaz: I attended TU Automotive in Tokyo last week
... main topics included telematics and autonomous driving
... several W3C member companies were present
... I spoke with a number of people from Alibaba, Harman, Continential, Visteon etc
... trying to re-engage some of them as they were more active before

<Kev_G> http://www.forbes.com/2008/02/28/oldest-work-clock-oped-time08-cx_po_0229salisbury.html

Ann: what does TU stand for?

Kaz: telematics update

Adam: they do many events

Paul: they just had Telematics West (competing for attendees to this and Genivi)

Adam: they cover many of the topics we do but at higher and business levels

<kaz> TU Automotive

Ann: I'm here not from Boeing perspective but on my own. I am wondering if this activity should be broader to some of the many other types of vehicles

Paul: you tried to ask me that question last year

Kevin: very different uses, needs, data and driver states with eg construction equipment
... but certainly things to learn from aerospace

Paul: there are some companies working in a very different part of the stack than we are sending large amounts of telematics data to manufacturer cloud space

Kevin: @@k

Paul: IVI reminds me of the screens in the back of the plane seat, information and entertainment

Ted: although this group is very focused on Web runtime and HMI level we discussed other W3C group work EXI in particular that is being used and useful to automotive, military

Paul: aerospace...

Ann: yes we contributed some use cases to that

Ted: but to your point we would like to have some people from this group get involved with other transportation industries in finding common needs/use cases for EXI and other big data telematics
... there is also a Big Data Europe - transportation Community Group who unfortunately is not at TPAC

Paul: I reached out to their chair Simon

Ann on autonomous vehicles of different types interacting in the future

Kevin: we are starting to see this in certain controlled environments, tests for less controlled environments
... the less controlled environments in complex environments are going to need much more training (learning system) and scenarios to reach to
... there may be some tough (life and death) decisions these systems will need to face

DaveR: need for lots of alarms and ability to shout look out/communicate to specific at risk entities
... there are scenarios where vehicle does not have enough visibility of eg a cyclist

Ann: that is similar to the factory scenario we touched on earlier, interested to hear from more countries and what they are seeing regionally

Qing An: we are starting to see more v2x work

Shintaro: we will be giving a demo during breaks and lunch

[lunch break until 2pm]

<kaz> scribenick: kaz

<paul> https://w3c.github.io/sensors/

<paul> https://w3c.github.io/sensors/

Generic Sensor API

tobie: working on Generic Sensor API

-> https://w3c.github.io/sensors/ Generic Sensor API draft

tobie: explains the draft
... use cases have come up
... e.g., augmented reality
... need for higher interface
... event lister for sensors
... lastly extensibility section
... consistency across specs
... for different types of sensors

adam: we wanted to have that kind of capability for multiple vendors

tobie: would go into the detail
... low-level sensors and high-level sensors
... high-level sensor is interesting
... e.g., high-level sensor exposes high-level device orientation
... go down for example 3
... on geolocation sensor
... the sensor listens to geolocation changes

let sensor = new GeolocationSensor({ accuracy: "high" });

sensor.onchange = function(event) {
  var coords = [event.data.latitude, event.data.longitude];
  updateMap(null, coords, event.data.accuracy);
};

sensor.onerror = function(error) {
  updateMap(error);
};

tobie: other examples
... geolocating the user

GeolocationSensor.requestData({ accuracy: "high" })
  .then(reading => { displayCoords(reading.coords); })
  .catch(err => console.log(err));

tobie: EXAMPLE 5: tire pressure sensor

DirectTirePressureSensor.requestData({ position: "rear", side: "left" })
  .then(reading => { display(reading.pressure); })

  .catch(err => console.log(err));

tobie: a lot of features at risks
... e.g., 4.1 Enumerating Sensors
... access to lower level
... this is the FPWD
... next, some specific purpose
... and "6. Security and privacy"
... "7. Extensivility"
... ProximitySensor
... example WebIDL at https://w3c.github.io/sensors/#example-webidl
... would love to hear if there are problems

kevin: hacking?

ted: professor from KIST
... sensors for vehicles, medical devices
... need to define scope of values, etc.
... trust by verify

tobie: exposing sensors on mobile devices is the current use cases
... doesn't mean it would not a problem

kevin: driving system need to verify the values

<ted> [they are able to impersonate sensors and spoof data and do things like point laser pointers, send ultra-sonic frequencies etc to give existing sensors erroneous data]

<ted> [need to have both hardware level encryption and data sampling to ensure your verified devices are not being tampered with]

[ that was part of the discussion during the BG meeting as well, I think ]

Dave: recognize this is very high-level

<ted> DaveR: to ted's point the fcc said the biggest threat to wot is data manipulation

Dave: the interface is just like as KNX
... might be an issue for Web API
... another issue is permission for APIs

tobie: open issue on that
... permission for API is to check if the user can access sensors
... when create a sensor instance, how that ask the users
... getting permission is possible
... you can wait until permission is obtained
... ideally would have permissions for specific sensors

DaveR: dictionary to describe that
... the current API doesn't seem to be scalable
... types, ranges, etc.

tobie: this work is work done to be a hook for sensors
... agree the fact permission is complicated
... e.g., what if we have 50 sensors and would access 25 of them
... permissions API checks the origin
... not for requesting

junichi: class of sensors?

tobie: wouldn't make sense for all use cases though would make sense for some of them
... possible to have sub class of sensors
... using the URL

junichi: you have to define all kinds of sensors if you use this approach
... how to handle new sensors?

adam: using the extensibility?

tobie: the goal here is easy extensibility
... you could have a class of sensors
... e.g., you could create a remote server-based sensor

paul: we don't care about where the data came from
... good to read this spec in detail
... looks similar to what we've done
... similar to what our company do for telematics

tobie: a lot work for Node.js
... node bot
... a framework called Jonny 5
... a very logical way for JS to access the data
... how to access different kind of sensors
... one thing still struggling is
... some of the sensors return data periodically
... some of them just return data at some time

paul: subscribe the data for that purpose?

kevin: grouping of sensors
... guide way for the interface?
... what if you have 40 sensors

tobie: could have a sensor hub
... this draft specifies high-level specification
... e.g., not a GPS but a gelocation sensor

kevin: issues with interaction?
... need to decide/authorize if we get the data

tobie: the OS is in charge of the security
... not the API itself
... not cared by the current draft
... JS doesn't really give you a method to guarantee trust

kevin: what about using some token?

tobie: could use https connection for secure connection with sensors

<ted> Extending vehicle data spec

tobie: one use case in mind
... GPIO kind of sensors
... JS file to test the sensors on devices
... expose sensors on the device
... the question is how can we make those devices discoverable
... difficult problem
... difficult to fingerprint the devices
... across origins

<ted> ted: our main interest in generic sensors api is ability for a given manufacturer extend our spec and provide a more robust vehicle object based on sensors available to them. the oem may want to have their sensor vendors (or a middleware component) expose through this generic sensor api. it would make for easy intergration

tobie: discovery API is challenging

ted: we discussed before that device discovery explores
... related to not only auto but wot

tobie: thinking about layers of sensors

<ted> [dap, now das (device and sensor), is putting on hold device discovery and want to seek use cases from auto, wot and others. sensor api is somewhat of a prerequisite]

ted: there are people extremely interested in device discovery
... discussion tomorrow and Wednesday

tobie: ad-hoc meeting tomorrow afternoon

paul: is that the breakout session?

tobie: no, another one

-> https://www.w3.org/wiki/TPAC/2015/ad-hoc-meetings#Generic_Sensor_API ad-hoc meeting on generic sensor api

tobie: 3-6pm@room 201
... and a breakout session on Wednesday

(time/room to be decided on Wednesday)

<paul> https://www.w3.org/wiki/TPAC/2015/ad-hoc-meetings#Generic_Sensor_API

tobie: APIs not tied to implementations
... communicate with sensors very easily
... questions?

(no questions)

[ 10-min break till 15:20 ]

Automotive Security and Privacy TF report

<Adam_Abramski> Hashimoto-san presenting Automotive Security and Privacy TF

<scribe> scribenick: ted

Use Cases

Security Summary at BG meeting last week

<ted> [[mission:

<ted> Provide envisioned incident studies.

<ted> Clarify requirements of web technologies based on the above studies.

<ted> Propose technical description to be added as specifications of "Vehicle Information Access API" and "Vehicle Data" ]]

junichi: procedures steps (3) need to be iterated repeatedly: list use cases, review in detail identifying attacks vectors, derive requirements

<ted> [policy slide]

junichi: my basic policy for this tf is that we make the car more convient, not increase risk and not leak private information
... we met with genivi last week to find common interests and area for collaboration. while genivi is mentioned in this slide this would be a useful exercise with similar organizations, oems and tier ones
... we should also think about inter-application interaction

<ted> [target model slide]

<ted> [basic model of stack - web apps, runtime, os and native app layers...]

<ted> [model comparison]

junichi: these two models are based on discussion with genivi
... webview vs browser
... runtime as a component (webview) allows more for an app market of singed packages
... in the runtime as the platform (browser) the browser vendor defines web app interactions, in the webview os maintainer. genivi prefers the webview model

<scribe> scribenick: kaz

junichi: should start discussion on the (possible) vehicle api v2
... would separate the step for it

kevin: tx
... need for validated app store using some specific server?
... potentially

ted: we have a runtime evaluated
... for trusted open market
... much more free
... interaction with web apps
... more rigid structure

kevin: but in practice, difficult to have this model
... some interaction with OEMs

ted: you don't have to investigate it

DaveR: OS level security, e.g., Android

<ted> ted: you can do both. have the more open with limited, less sensitive information available and inter-web-app interactions to be free take place. a second web runtime can have the more structured and secure interactions with more sensitive data

kevin: if you control everything using the model on the left side

<ted> [advantage to doing both is you can have a more open marketplace that you would still review but not assume as much risk]

jet: would be useful for more consistent user experience?
... policy for entire system or not

kevin: even the right side approach might not be enough for use distraction in some cases

DaveR: using the right-side model, could have some robustness

kevin: good point

paul: could be another way
... you can flip Apps and Browser

kevin: possibly a mixture

peter: would be a native app

DaveR: they could also use virtualization - (run on separate virtual machines)

junichi: personally prefer left approach
... Firefox OS is something like this
... many OEMs don't seem to use the the left model currently
... so would suggest we start with the right model

wonsuk: the right side shows a hybrid application?

junichi: right

wonsuk: all the apps are packaged
... install and use it
... that is a native app-like style
... but HTML5 apps could be just a URI
... the app accesses some service on the Web
... in case of the right side, you only think about packaged apps
... which include all the resources inside the package?

junichi: at least the exec code should be inside
... content data could be from outside, though

wonsuk: both web apps and hybrid apps get actual content from the web

junichi: however, regarding the lifecycle model
... OEMs check the apps before releasing them

DaveR: there is a challenge
... you can only say something about the app
... there is a malicious part

kevin: you can check where from the data provided

DaveR: this model assume calling some server and verify the data
... the right model has access restriction

kevin: you could have multiple browsers to use multiple processes
... in practice limited access would be useful

DaveR: on your (=Junichi) slide, you mentioned attack vectors & type of threat

<paul> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=1828778399&fvid=190768047

(some discussion of privacy issues)

jet: more interesting to use the Web technology for more than rendering
... behavior of scaling is different

kevin: you might need visit the server beforehand
... and declare I'd use Facebook

<paul> http://www.autosec.org/publications.html

kaz: mentions EME work which is originally developed to protect content right

DaveR: that is related to local-side threat

junichi: would move forward

kaz: so do we want to think about the both models?

hira: we should clarify the pros and cons of the both models

kevin: JRL implement both the models
... and use a secure channel
... don't think we need to dismiss one of them

adamC: agree

kevin: the point is how secure the Web sandbox is
... authenticate the user, authenticate the vehicle
... in practice, the left-side model may be more secure
... but the both models must be secure

sakamoto: which layer is the target?
... the user app can access the vehicle ECU?
... web view also uses HTTP connection
... so there is no difference from the viewpoint of web connection

kevin: it's not for a safety critical system
... we don't need to make a choice between the two models

ted: you (junichi) are right, architecture choices like this doesn't belong in the spec. we might want to produce best practices and guidelines outlining the differences and possible desire to have both

kevin: having two interfaces, w3c-based standard interface and proprietary interface
... would be easier to test if we have w3c-based standard interface

junichi: have another idea different from these
... having a node server who handles all the requests

wonsuk: think it's already implemented based on existing standards
... web apps can request for geolocation server

junichi: we can define an actual URL for that purpose
... for a vehicle information server
... not sure if we should handle that model here, though
... in the both cases, the blue boxes have interface

sakamoto: vehicle APIs are used by the Apps and access the Base OS?

hira: the web view part need to have all the APIs in the right model

ted: do you have any more slides?

junichi: yes

ted: you've identified issues and next steps for the security&privacy tf

junichi: would summarize the TF's work so far
... categorized all the 60 use cases

(protection against intrusion and attack)

junichi: explains the legend
... green circle: feasible and scope of the current spec
... yellow triangle: beyond our scope
... red arrows: future scope of need further discussion
... we have less use cases for this category

('set' API)

junichi: not positive for 'set' APIs
... not recommended but have to understand the need

DaveR: safety lock, window, etc.?

ted: we don't have clear separation of which of these we will even be interacting with. jlr+genivi rvi for example will not go through web runtime but their own protocol and not boot the whole ivi when the car is off.

paul: everywhere HMI type of user interaction exists

junichi: a use case asking the runtime to allow only one feature at once

(API accessibility)

junichi: requires more discussion
... certification is impossible from my viewpoint
... introducing OS support would be feasible
... automaker provides API via https instead of direct APIs
... remote access should need future discussion for the spec

(Communication)

junichi: secure/trusted communication between devices
... secure access to outside storages

(User's rights for their personal data)

<ted> -> @@link_slides Junichi's latest version of slides

junichi: "Do Not Track" feature
... Generalization of data for protection of privacy
... Emergency cases
... Monitoring
... we have 'GetHistory' capability within the current spec

ted: IVI is not available after crash
... maybe we could have some secondary responses in that kind of difficult cases

<ted> [for a secondary response. there was agreement there may be plausible use cases when the ivi is still running it can be an actor in such a situation]

(some more discussion on emergency cases)

paul: would be good to identify what is IVI and what is not
... you has to have personal information

<Karen> [Dutch firefighter reference to Bart van Leeuwen, Netage]

paul: is it part of this API?

ted: it doesn't apply to the API itself

paul: nice to have a criteria

ted: which security concern is related to which level?
... OS level, wrapper level, etc.

kevin: should share the concern on security with other groups as well

<paul> https://www.w3.org/WoT/IG/wiki/Security,_Privacy_and_Resilience

kevin: security and responsibility
... if security should be handled by OS level
... we don't need to think about that for the Web layer

ted: we had useful discussions
... there threats on the OS level and the browser level
... would be better to best practice or guideline document

(Multi Drivers/Passengers/Users)

junichi: for mobile phones, there is only one user
... so we don't have to the possibility of multi users
... but there is a possibility for cars to have multiple drivers
... user identification, environment switch, payment

wonsuk: generally we should synchronize on how to handle devices
... APIs to handle various devices
... DeviceAPIs WG has done battery API and vibration API
... but we don't have a security model for the generic web
... API to read data and write data
... a bit curious about our having both get and set within a spec
... we might want to try get APIs first
... and then set APIs next
... should start with a safer APIs

ted: would have a middle layer?
... it's out of scope of our API but we can use the OS level mechanism as well

<ted> [the critical high concern will need to be handled at os level, basically not an option in web runtime]

wonsuk: even OS level APIs have security issues
... OS handles physical devices

junichi: we've discussed models for packaged web applications
... can we reconsider packaged web apps?
... not sure what we can do without other group's support

wonsuk: need to make something as the first step
... and then think about the next step

<ted> [medium will be permitted by the more trusted webview model. low (read only) permitted for intra-webapp processes. we can define these basic levels and how to structure acls in web runtime]

wonsuk: W3C has experience of huge specs, e.g., HTML5

kaz: are you thinking about some possible mapping between the web layer and the native layer?

paul: we have to have a roadmap

wonsuk: we got the draft spec from the BG
... for the current spec, we could just think which part should be the v1 spec

ted: we can have some different tiers
... including a read-only/no-set layer
... HVAC should belong to a OK-to-access layer

kevin: if a user can't be allowed to access some data
... need to repeat to access the data?

ted: for our spec, come up with access control
... next step should be gathering best practices
... web-based IVI opens up issues on security&privacy

kaz: when we think about best practices, maybe we should think about which part of the model is responsible to which part of the issues

kevin: what if different implementations handle different errors?
... every OEM uses proprietary error codes

paul: we need a breakout to discuss what to do

(checking people's availability)

paul: tomorrow would be better
... might be helpful if people could write down their ideas by email, etc.
... and have a breakout meeting tomorrow
... send to the public list?

ted: yes

paul: ok
... what you want for the current spec from the security viewpoint
... and expected roadmap
... everyone is encouraged to send your ideas to the public-automotive list

<ted> mailto:public-automotive@w3.org

paul: should wrap-up now
... tomorrow we'll have joint meetings with Web Payments (9am@206), Geolocation (10am@108), Web&TV (current plan 1pm@mid hall b), WoT (2pm@108), Generic Sensor (3pm@201)

DaveR: there is the security group within W3C
... breakout on Wednesday

-> https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Web_Authentication_and_Security Breakout proposal

paul: good discussion today

<ted> Liaison minutes with Web Payments

<ted> [Introductions]

Liaise with Geolocation Group

Introductions

<inserted> scribenick: kaz

(round table; circulating the sign-up sheet)

Overview of Vehicle Information Spec

paul: Adam Crofts will give the summary

(starting the webex terminal)

adamC: two specs: Vehicle information access API and Data API
... startin with the Vehicle spec

-> http://rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html vehicle information access api

giri: question on in-car location information

adamC: front, middle, center and layers
... shoes the "7. zone Interface"

kevin: top and bottom are the basic two layers

tobie: sounds reasonable

kevin: cameras could be located front or rear

tobie: had same discussion for generic sensor api

adamC: shows section 11 and 12
... VehicleConfigurationInterface Interface
... can specify time span to get data
... shows "EXAMPLE 3" right above "14. Data Availability"
... and "14. Data Availability"
... check if each data is available

giri: what is the expectation for this API?

adamC: HTML5 sends data from car to user, and communication with outside service

paul: data coming all time from the car

giri: application get the data via one-shot api?

adamC: maybe 10ms example was a bad example :)

paul: don't have previous any use cases on how to get data using this spec
... would see high-level business use cases

giri: others from Qualcomm are involved in Genivi

paul: a business group has been created
... worked with Genivi, Webinos, QNX, etc.
... concept of extensibility considered

adam: we have same problems as the generic api guys

adamC: shows "16. Use Cases"
... and come back to "EXAMPLE 1" right above "2. Conformance"

var vehicle = navigator.vehicle;

vehicle.vehicleSpeed.get().then(function (vehicleSpeed) {
  console.log("Vehicle speed: " + vehicleSpeed.speed);
},
function (error) {
  console.log("There was an error");
});

var vehicleSpeedSub = vehicle.vehicleSpeed.subscribe(function (vehicleSpeed) {
  console.log("Vehicle speed changed to: " + vehicleSpeed.speed);
  vehicle.vehicleSpeed.unsubscribe(vehicleSpeedSub);
});

var zone = new Zone;

var zones = vehicle.climateControl.zones;

for (var i = 0, zone; zone = zones[i]; i++) {
  if (i.equals(zone.driver)) {
    var value = {};
    value["acStatus"] = true;
    vehicle.climateControl.set(value, zone.driver).then(function () {
      console.log("Successfully set acStatus");
    },
    function (error) {
      console.log("There was an error");
    });
  }
}

adamC: walkthrough the example
... "4. Security and privacy considerations"

giri: vehicle environments don't necessarily expose all the data
... should mention that

adamC: OEMs make decision

giri: this is Navigator.Vehicle
... could be exposed using some client-server model

paul: conceived based on the discussions with Genivi, etc.
... various vehicle networks
... running within a car is an assumption

giri: the spec is written
... but you could have a client-server model
... e.g., HTTP connection

paul: still don't know how the runtime gets the data
... how auto makers would use this spec?
... extending the web runtime is the key discussion, e.g., within Genivi
... typically using WebSocket
... would love to hear opinions

kevin: could choose how to apply this, e.g., inter-vehicle model
... whatever technology would make sense
... secure access to vehicle internal data

tobie: distinction between different kind of servers?
... locking and unfor locking, etc.

kevin: identification and authentication for vehicles
... on whose behalf the APIs work
... complex safety issues
... if we are sitting in the vehicle and use the API
... you can safely use the capability
... but not so if you use it remotely using a mobile
... because of safety

giri: every single query is accessible from outside?

adam: no
... optional

paul: similar to generic sensors

tobie: across different implementations

giri: fingerprinting?
... what's available within a vehicle
... to identify who is using

paul: if you can get a license number

tobie: not to expose (more than) enough information is problematic
... would cause big privacy issues

kevin: have to be careful, e.g., to anonymize the data
... minimizing your footprint

giri: we minimize user data
... need to see if the data is really needed

paul: is this useful?

tobie: user should be aware
... the user browse web pages
... when/how the data should be exposed?

kevin: we're launching some opensource project, @@@

tobie: this is more like a web-based OS than a web browser

kevin: in order to protect customer's security/privacy
... there are apps we control
... completely different from browsers which user themselves use

tobie: not read the spec itself yet
... but think it should mention what the expected security model is

adam: valuable feedback
... don't want the spec to say "this is the box you need to use"

tobie: the Web has a distributed model
... so should mention the expected security model

giri: agree

peter: HTML5 apps are real third-party apps

tobie: but should be something automakers can trust

peter: probably you need some limitation

tobie: if your security model is clear, that's fine
... there could be a possibility of using regular Web for 20% of the system

adam: moving forward

adamC: data spec

-> http://rawgit.com/w3c/automotive/master/vehicle_data/data_spec.html data spec

adamC: "6. Running Status Interface"

giri: relathionship with DeviceOrientation
... assumption to get data from mobile devices?

paul: this is vehicle information
... but communication with GPS, etc.
... Hirabayashi-san had some discussion with you, Geolocation WG
... communication to get data
... deadreckoning module use communication?

giri: we're not sure how to get the position object

paul: for geolocation information we'd use geolocation api
... have discussion on location-based services
... people might want to choose which data should be exposed

giri: maybe we should cooperate with the Generic Sensor APIs guys

kevin: we just think about apis for vehicle
... vehicle could consume apis for mobile
... there is trust issues, though
... in an easiest case, you might want to use a mobile as a sensor

adamC: "6. Running Status Interface"
... "6.2 Vehicle Speed"

giri: just saw a different case of battery status by DAP

-> http://rawgit.com/w3c/automotive/master/vehicle_data/data_spec.html#batterystatus-interface batterystatus

tobie: very car-specific environment
... who do you expect as the developers?
... car people or web people?

adam: what we should expose is the key

tobie: think there is duplicate stuff with other web specs
... may be a nightmare to have multiple similar specs...

adam: we do have interest in collaboration
... we've been working on a set of APIs which is interesting to OEMs

tobie: I'm just pointing out the fact there are some duplicates

giri: the battery api by DAP doesn't fit this purpose

paul: we need some domain-specific knowledge for automotive purposes

kevin: driving cars safely
... who is driving the car
... might have higher level of drive instructions for ADAS cars
... how involved the driver is

peter: difference between the driver's seat and the rear seat

kevin: this data definition is a right set

paul: during the joint meeting with the payment group
... discussion on not tying to some specific vendor

tobie: just wondering what is the target developer for this api

paul: agree doesn't make sense to reinvent specs
... have been discussion with OEMS and tier1s within the BG

tobie: similar questions on TV discussion

kaz: right, so we should see what's happening within the TV world, e.g., we could join the breakout session on TV browser testing tomorrow

kevin: careful discussion on security

paul: some automakers use HTML5 for their IVI systems
... using high-level abstraction

kevin: there are 70 signals
... but can't expose half of them
... don't have the signals yet
... there is a lot of work for mapping
... security as well
... the other issue is what "vehicle speed" means
... could use GPS information

tobie: generic sensor discussion has similar issues

paul: how much data is exposed depends on each automaker

kaz: tobie, you're not denying this spec itself, but would suggest we work with related groups even harder?

tobie: right
... clarifying the expected security model as well

kevin: it would be helpful to hear some concrete description on security framework
... would be difficult to cover whole the vehicle security
... that's a challenge
... need to implement secure vehicle
... would get some particular security scenario

giri: @@g

tobie: is it sufficiently low-level solution?

paul: would take a homework to look into battery, geolocation, sensor specs

tobie: geolocation could be rewritten using the generic sensor api
... you have a more specific case
... there could be two different kind of data for speed, e.g., car-based speed and GPS-based speed
... if you show up for the generic sensor ad-hoc meeting (3pm-)
... would talk about what generic sensor is like

junichi: technically low-level approach works
... but users don't know how GPS works
... how to identify that kind of different need

tobie: how the detail is handled should be decided by the implementers

junichi: generic sensor api doesn't handle high-level security like user's preference
... by using generic sensor api, maybe users can turn on/off devices
... but the user may have specific preference for security

tobie: generic api doesn't handle permission based on user's preference
... the user agent decides that

junichi: OEMs and/or implementers should handle that?

tobie: yes

junichi: in that case, users need to understand the mechanism?

tobie: no
... application implementers and/or OEMs handle privacy issues

IVI Navigation - W3C Use Cases and Genivi APIs

-> http://wiki.projects.genivi.org/index.php/IVI_NavigationW3CUseCasesAndGENIVIAPIs wiki page

qing_an: walkthroughs

giri: you don't need to add specific apis to handle maps

qing_an: there are media tuner capabilities as well
... POI (point of interest)
... there is no generic api for this purpose

giri: if you don't expose data to outside (different from usual web apps)
... this would make sense
... for example, I have relationship with a map server
... but that depend on broadband connection with the server
... if the assumption is automotive uses may be ok
... but for generic web use, it's not allowed

paul: there is Genivi's position

giri: there was some discussion on geocoding
... but it didn't go into the standard

paul: this automotive group has several map guys

giri: for automotive services, an OEM might want to use one specific map

kefin: could use different map services

giri: the developer don't have to know about the detail
... that's the case for geolocation api as well

adam: developers can develop apps regardless of which map system is used

tobie: ok. you should do this within this automotive group

giri: now understood it makes sense

qing_an: if anybody is interested in this work, please join

adam: it would be great if we could somebody from Qualcomm

paul: mentions who are participating now

giri: can I get address features those already handled by the geolocation api?

qing_an: ok
... there is "Geocoding" features as well
... and "System Interface"
... TTS capability

giri: should refer to touch event api

kaz: and speech API for TTS

paul: we met speech api guys in Santa Clara before

qing_an: anything missing?

giri: we're defining geofencing within the Geolocation WG
... usually associated with POI
... bound here could be tied with geofence
... the draft is FPWD status
... would suggest see that

qing_an: would talk about the detail during the ad-hoc session later
... and breakouts tomorrow

Geolocation WG update

giri: thought sent slides to you

<gmandyam> Geolocation API Style presentation: https://www.w3.org/2008/geolocation/wiki/images/b/b0/TPAC-2015-Geolocation-API-Style.pdf

<inserted> giri: Geolocation API

giri: first device API by W3C
... asynchronicity required
... interoperability has been an issue
... DeviceOrientation
... almost called "gyro"
... longstanding issue on absolute orientation vs relative orientation
... Geofencing
... newest spec
... based on service workers
... data minimization was incorporated into breach events
... Some things to consider
... enumerate all the security/privacy requirements
... carefully consider API definition that calls for specific hardware implementation requirements
... similar to Web&TV as well
... defining APIs for new objects

all: thanks!

Summary of TV at W3C

<inserted> scribenick: ted

kaz: the web & tv ig has spun off tv controller api cg
... we met with chairs and team contact of the former over lunch since the latter are no longer here

<scribe> scribenick: ted

-> https://drive.google.com/open?id=1nYs8_xMktQCynLEOYRjLFxatFuQkamrvfpQ3sAMC10s TV Control API CG update

kaz: there is currently a draft spec coming out of the cg. they drafted a note since it doesn't have the weight of a spec from a wg

adam: looking at the time line it looks like we might be late to add further contributions

kaz: they are planning on future versions of this spec and form a wg

Web of Things

Joerg: we started this activity because of all the interest around internet of things
... there have been studies about how much can be gained, homes, offices, transportation, cities
... there are many technical standards for the lower levels of IoT but there was a gap for the upper layer
... our vision is basically to build web applications across these things
... we came up with general ways to describe these things
... basic metadata. we came up with an interaction model = what kinds of properties, actions and events
... of course you also need to describe what the data payload is
... we thought of a scripting api and protocol mapping
... in various interactions things act as either clients or servers
... in auto case we want to treat vehicle as another thing
... when we say "web thing" it is the online representation of a physical device

[wot building blocks, slide 5]

Joerg: we can come up with three kinds of apis. server, client and physical apis
... physical layer can be wifi, bluetooth etc
... things are meant to interact with one another or the web
... besides scripting and protocol we have a task force on discovering things
... when they come into proximity allow them to discover what is availabe from other iot platforms

[6 categories

-finding around me - nfc, uribeacon

-finding things on my network, mdns, multicast coap

-searching in directories (when network is too large or distributed) core resource directory, xmpp iot discovery

-searching via p2p

-accessing thing metadata (core link format, hateoas)

-semantic based discover - mostly research at present

]

Joerg: not sure how much of this is relevant since cars are already predefined but you also do bring in external devices

[WoT BB - Security & Privacy]

Joerg: security and privacy requirements derived from use cases collected
... we compiled a landscape list of s&p means

<yingying> https://www.w3.org/WoT/IG/wiki/Security%26Privacy_Requirements

[work on technical landscape]

Joerg: discuss domains, set of atomic use cases. doing a landscape study, we are looking at multitude of IoT being developed
... for mapping and scripting api you are abstracted away from the specific protocols
... we are looking for a very basic common denominator for thing description
... we are interested in what sort of apis you have into vehicles
... we have 4 implementations already trying to understand this space

Kaz: we would like stronger collaboration on privacy and security

Joerg: if we can join forces there that would be good from our side as well
... we would be interested in your use cases in this area as well

Junichi: any concrete use cases on this servient diagram?

Johannes: a script option might take data off the web (eg weather) and device act on it
... we want to abstract the api from the protocol as it is not always a web protocol
... for your application you are staying high level

<kaz> WoT APIs&Protocols TF (working on protocol mapping)

Junichi: for a car navigation system in ivi would the one on the left make sense?
... we only allow predefined applications in one model and others that they can pull things down from the web

Johannes: you could restrict to what an application programmer can use. it can only be enforced by a well defined api

<inserted> Junichi: which part is a web runtime?

Johannes: we do not say the type of runtime, it is not necessarily a web runtime as that restricts it to js

Junichi: in a single device you only have one of these modes [on wot servient slide]

Johannes: there is nothing that prohibits you from having several scripts

Dave: script can represent multiple things too at once

Kevin: this is very general given breadth of things being represented
... are there areas like authentication that you are focusing on in more detail?

Dave: yes we have a task force

Joerg: it is restricted to requirements you have a resources available
... we started with generic view and now looking at specific actors
... we want to make this concrete with specific examples
... so far we have done this for simple thing description, protocol mappings and we are going further with security and privacy and scripting model

Kevin: knowing what a thing is a member of like a physical house would be useful

Johannes: we are landscaping what is the market and where it will fit

Kevin: how do you know if the thing is what it claims to be?

Dave: we are looking at establishing credentials

Joerg: majority of the time you do not have access to a given thing so that ties into authorization management

Dave: part of this is through provisioning. how do you configure it and its security properties

Kevin: when you want to tie your car into your home entertainment system, you want to see your internet of things by useful identifiers

Joerg: that is part of the discovery
... is this part of what you see as about the infotainment in the car

Paul: depends on who you talk to. what we are primarily working on is a data access api for the underlying vehicle
... it is mostly as an IVI on head unit but could be used other ways

Joerg: are you triggering longer running actions or merely a browser getting and setting values

Kevin: parts of the car can be web things
... you might want your fridge to let you know you are running low on milk when you are on your way home

Joerg: besides these kind of getting and setting are you getting into automation

Kevin: yeah it could be anything
... one set of use cases coming at us is for assisted driving
... we need to give trust to adas control module in a car and similarly there needs to be levels of trust between devices

Johannes: we require self contained messages so they are not hijackable. they can be signed and encrypted and not rely on a hidden state

Kevin: I would appreciate references to that

Joerg: we might be interested in looking at automotive as an experimental use case

Paul: most relevant here to wot is v2v and v2x

Junichi: we have several use cases but none addressing running a server from the ivi

[Kevin presents slides]

Kevin: what this use case is talking about as it might pertain to wot in driver assist, it needs to trust the information that is coming from other devices

[slide 7]

Kevin: the adas control in this model needs to trust sensors and it isn't receiving spoofed information
... in convoy mode you need to get information from vehicle up front about eg braking incidents

[slide 8]

[slide 9]

Kevin: you can share information of various sorts with vehicles in proximity

[slide 10] (some wot use cases)

[slide 11] access control

Dave: one challenge is trying to code something across varied versions. regarding resilience we intend to discuss further in the IG what would be predictable behavior and data

Joerg: we can take away one or more of your use cases to draw it out further

Kevin: your notion in wot of atomic is interesting, all events happen or none happen - rollback

[Adam giving tour of spec]

<kaz> Vehicle Data spec

<kaz> [ break ]

<kaz> scribenick: kaz

Security breakout

paul: three messages on the list

Junichi: would keep momentum
... so would publish the updated draft on schedule

-> https://www.w3.org/auto/wg/wiki/Main_Page#Publication_Schedule publication schedule

<Paul> From Hashimot-San regarding security next steps:

<Paul> * We may have to omit 'set-api' from V1 * V1 spec should rely on OS security framework instead of on-going web solutions because we cannot control these schedule. * Security & privacy consideration doesn't have to be in spec but should be anywhere, e.g., as a BG/WG note. This will be required in the review process.

-> https://lists.w3.org/Archives/Public/public-automotive/2015Oct/0032.html Junichi's message

Junichi: some guideline is needed

paul: agree

Junichi: how to keep the momentum is my point

ted: some work in place now
... and wait for, e.g., next year, to try more?
... for v2, we deal with major security update

adam: keep the current v1 spec asis?

paul: we hear some considerations
... it's something like that we believe the current API is fine

(discussion on error codes, etc.)

-> http://rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html#vehicleinterfaceerror-interface Error Interface

-> https://lists.w3.org/Archives/Public/public-automotive/2015Oct/0043.html Kevin's message

-> https://lists.w3.org/Archives/Public/public-automotive/2015Oct/0034.html Ted's proposal

ted: proposals on possible next steps for security and privacy
... we can do high-level protection
... "Access Control Mechanism"
... "Best Plactices for Web Runtime in IVI"
... what is "Web Runtime"
... review various use cases and attack vectors
... "Entity preference profile"
... define personal, payment, vehicle information, etc.
... like credit card number
... first one and second one for safety
... third one for user profile

-> https://lists.w3.org/Archives/Public/public-automotive/2015Oct/0039.html Kevin's message in response to Ted's message

<inserted> scribenick: ted

[Proxy piece could include:

-sanctioned site list and protect against usual uri games

-check certificates

-strip javascript

-content type check (make sure we are getting back what we're expecting)

-data integrity check - logic to see if received information is in with expected range, for more sensitive information

- others]

<inserted> scribenick: kaz

adam: this is access control for web runtime

<ted> http://www.w3.org/TR/runtime

adam: "Runtime and Security Model for Web Applications" by SysApps WG

Junichi: this approach is huge and am not sure if this could be applied soon

kaz: please note this draft is a WG Note because the work is stopped

adam: this is application level access control
... this needs to be implemented by runtimes
... you have something like this as the basis of the discussion

wonsuk: unfortunately, this spec doesn't really our security expectation
... there was a security expert who stepped down in the end
... we can't make progress without having a security expert

adam: this covers some of our requirements, doesn't it?

wonsuk: basic input for this document was made by Google
... based on their experience on Chrome OS
... the concept of "runtime" was that applications are packaged
... after our starting service worker, service worker-based approach would be more appropriate
... we can't necessarily use links appropriately using packaged apps
... for web apps we can simply share the links
... everybody can use the web app at once

adam: not sure that is an appropriate use case for car apps...

wonsuk: we learned that using hosted web apps is lighter approach than packaged apps
... we can choose either way (online or packaged)
... firefox os, chrome os, tizen, etc., are going to that direction
... this runtime security approach is also a basic mechanism regarding manifest, though
... defines a basic mechanism for tizen, etc.

kevin: what is the benefit?

adam: the guys from the security team have expertise

junichi: there are two things here
... manifest and CSP (content security policy)
... maybe we can utilize the idea included in this draft

wonsuk: manifest spec is going now

-> http://www.w3.org/TR/CSP/ CSP

<wonsuk> manifest format spec: http://www.w3.org/TR/appmanifest/

paul: how could we get adapted?
... you want to layout all the issues
... getting security consideration as a section
... but what should be done for the concrete security description?
... we've been going around and around
... what would be a discrete action item?
... Kevin set an issue on GitHub

junichi: would handle access control

paul: error, access control, set, ...

ted: woT is doing some stuff

paul: entity preference?

ted: besides data coming from CAN-bus
... personal data like location, address, etc.
... out of scope of the vehicle spec, though

paul: we need to slice (the action items)

wonsuk: for the horizontal security model
... the Web Application Security WG is working
... Junichi and the Security TF should investigate their work

<wonsuk> specifications from web apps sec: http://www.w3.org/TR/#tr_Security_for_Web_Applications

kaz: Natasha from GSMA gave some talk on their work last night during the Developer Meetup

wonsuk: we should investigate their work first and then add security portions to our spec
... one of the big ways is that Web vendors would like to use only HTTPS
... that is a good sign
... basically we need to know what is done
... and what kind of security issues

junichi: it depends on what we can do with this spec

wonsuk: even if we omit the 'set' api, there might be some issues

junichi: currently, history and accident information are the keys

wonsuk: need to see when/what information could be exposed

paul: error, access control, set, threat model, OS security
... person id, entity
... sensitive data element

hira: these items require further investigation for v2

paul: we need some text for v1 as well

hira: how about handling emergency exception with DNT?
... we have to talk with the privacy group or DNT group?

paul: what do we need with DNT?

hira: this issue will be covered by v2 or v1?

paul: we should see
... could mention every user don't want to be tracked

junichi: as for web security specs
... it refers to many specs
... working by myself is difficult
... would work with Kevin

kevin: ok

junichi: would work for credential and permission as well

-> http://www.w3.org/TR/#tr_Security_for_Web_Applications Security for Web Applications

MMI introduction

-> https://www.w3.org/wiki/MMI/Use_Cases MMI Use Cases

-> http://www.w3.org/2013/10/mmi-charter.html#mmi-ecosystem MMI Charter

-> http://www.w3.org/TR/emma20/#s4.1.10 EMMA 2.0 geolocation example

-> mailto:www-multimodal@w3.org MMI public list

<kaz_> [ taking group photos ]

<kaz_> [ meeting adjourned ]