Automotive WG f2f Meeting in Sapporo

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

<yuwei_> rrsagents, make mintutes

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/

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

<ted> Use Cases

<ted> 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" ]]

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

<ted> [policy slide]

<ted> junichi: my basic policy for this tf is that we make the car more convient, not increase risk and not leak private information

<ted> ... 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

<ted> ... 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]

<ted> junichi: these two models are based on discussion with genivi

<ted> ... webview vs browser

<ted> ... runtime as a component (webview) allows more for an app market of singed packages

<scribe> scribenick: kaz

<ted> ... in the runtime as the platform (browser) the browser vendor defines web app interactions, in the webview os maintainer. genivi prefers the webview model

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

- DRAFT -

Automotive WG f2f Meeting in Sapporo - Day 1

26 Oct 2015

Attendees

Contents