<inserted> scribenick: ted

[EXI vs gzipped BSON, CBOR]

scribe: still smaller across the board
... EXI is not compression
... when people share data they use a standard api to produce xml or json and might compress before sending to other system
... EXI writes an EXI binary stream instead of XML
... it does not require XML
... but it can fit underneath an xml library

[slide listing the multitude of XML definitions - eg RDF, SVG...]

[all the XML based implementations]

scribe: XML aware applications tend to produce a representation of the XML (SAX or DOM) and not the XML itself
... you can develop and test in pure XML and then switch to EXI after
... adoption wise: we are in 400k automobiles in the U.S. and expanding
... it is being used for smart energy (appliances and power meters)
... it is being used for digital radios used by emergency responders
... gaming industry
... IoT, W3C, V2G (vehicle to grid for electric vehicles), US DOD and intelligence communities have adopted it

[list of better known customers]

scribe: banking and finance
... VW Car-Net uses it
... this is used in fighter aircraft for both internal communication on the bus and external
... it is being flight tested in F22 and F35

dave: how long has the spec been around?

john: 2011 for the first edition recommendation. it second edition Rec in 2014

<kaz_> EXI first edition

junichi: how about error detection?

<kaz_> EXI second edition

john: that is in a different layer of the stack as is encryption and security

dan: you mentioned how much more efficient Agile Delta's system is, how does that compare to others?

john: ours was the reference implementation
... not a fair comparison since we had several years head start
... i would say 16-30x faster and maybe 2-6x smaller

dave: are there many implementations?

paul lists 4 from w3c site

john: cisco, arch, seimens. some private implementations

dave: i'm not seeing python libraries for example

john: it is not widely known. we have a high ratio of engineers to marketers

<kaz_> publicly available EXI implementations

ivan: people are also becoming lazier with efficiency and throw more hardware at solutions
... that is going to be needed in IoT

john: those who know about it generally adopt it

ted: so as it applies to our json based spec... when there is need to not interact with the user but send large volumes of data an app using the json api can collect and package up in exi before streaming out

dave: it makes more sense to use json for browser interfaces

john: very true but when you are paying for bandwidth you need to be as compact as possible

<inserted> kaz: there is discussion on EXI within the WoT IG as well, so maybe it would make sense to have joint discussion with them, e.g., during TPAC 2015 in Sapporo

shinjiro: can you convery back to xml?

john: yes, it is called transcoding

ivan: what about open source data stream sniffers?

john: yes you can put a plugin into wireshark for example to see xml extraction

<kaz_> [ think EXI Primer http://www.w3.org/TR/exi-primer/ is a good starting point to know EXI ]

<kaz_> scribenick: kaz_

<inserted> [ Day2 ]

Agenda

Use Case Mechanism/Infrastructure

Breakouts

- Use Case

-- Categorization

--- Security

--- Privacy

--- Remote Access

--- Higher Level Functionality

--- Identification

-- Testing

2pm

- Presentations

--- @@@1

--- @@@2

Introduction

wonsuk: from ETRI

<junichi> use case spreadsheet: https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=867261678

day2_attendees: Dan, Paul, Greg, Ted, Wonsuk, Sakamoto, Ivan, Urata, Kaz, Hashimoto, Hirabayashi

<Ivan> I have arrived

<paul> https://klg.webex.com/klg/j.php?MTID=m3533658821a3b35ae42e5e77fcf43553

<paul> Meeting number: 731 650 244 Meeting password: Web729

Use Cases

<kaz> scribenick: kaz

<paul> http://www.w3.org/auto/wg/wiki/Use_Cases

<ted> https://www.w3.org/auto/security/wiki/Use_Cases

<paul> https://www.w3.org/auto/security/wiki/Use_Cases

paul: spreadsheet put together by Hashimoto-san
... and Use Case Wiki by Qing An
... Security Use Case Wiki by Kevin

(quick review by each)

-> https://www.w3.org/auto/security/wiki/Use_Cases Kevin's Security Use Cases

paul: what do we do on ADAS?
... security issue is authentication

-> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=867261678 spreadsheet on "Use Cases and Concerns"

paul: the spec doesn't cover logging
... another point is performance
... what do you do for frequent fresh rate?
... also register items for logging?

greg: frequency of ADAS information activation?

dan: would be helpful to capture some high level use cases

paul: would be great to capture high level use cases like logging ADAS information
... this looks like V2X thing

ivan: does the spec have a space for future systems?
... robust to system-wide

paul: can you generalize operations?
... identifying data
... could be a separate interface

ted: no. 6 from the spreadsheet vs. use case 4 from Kevin's wiki

junichi: we don't have to merge all the use cases during the meeting today

ted: require data sharing stated by governmental/federal instructions
... vs. sharing data with friends

hira: the point I think is granularity of the data

ted: people might be interested in average speed
... more efficient driving

paul: we should capture high level use cases first

hira: after that we should prioritize the use cases, etc.

paul: the goal is identifying use cases which are influential to our specs
... from the viewpoint of security and privacy
... our focus is the specs

kaz: btw, it would be better to have an ID (or URL link to the original wiki-based use case description) within the spreadsheet to identify each use case described on the wiki pages

paul: No. 25: driver would like to remotely start vehicle...

(Adam joins)

paul: discussing high level use cases
... to identify the priority
... auto maker's applications have complete access to all the data
... 3rd party applications just have access to part of the data

greg: automaker has concerns around impact compliance with emissions regulations due to 3rd party access
... security concern is giving direct access to vehicle control

paul: meaning accessing a server rather than directly accessing the vehicle?
... (updated the spreadsheet based on the discussion)

wonsuk: smart things, a venture company, provides a cloud-based mechanism to control smart home devices
... the cloud service can make decision on who can access what

kaz: in that case, the cloud service has authentication capability like fingerprinting?

wonsuk: not 100% sure
... but should have some mechanism for security
... could be fingerprinting plus passwords for payment service

paul: if HTML5-based headunit use JavaScript to send the data to the cloud server, the speed might be problematic

kaz: Sakamoto-san's demonstration in the afternoon is related to this problem

[ morning break ]

-> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=0 high level use case spreadsheet

<ted> scribenick: ted

[discussion recalling use cases from Bart @@@ of the Netherlands, emergency responders wanting to know locations of and/or ability to disabled air bags]

http://www.w3.org/2015/07/vehicle-data#idl-def-AirbagStatus

paul: this use case exercise will also be useful in discovering omissions in data spec

ivan: the data polling frequency is extensive

paul: some like traction control systems and oil pressure you want to know immediately
... it is also possible to have a bad data reading and those should be discarded
... there is monitoring for events which requires storing values and computing to calculate changes
... subscribing is polling for all data and determining when an event happens. separately we want a better event listener

dan: desire for a callback function

wonsuk: there are different approaches including callback. if the event happens we would want a handler
... it is less expensive than polling

paul: we might want to add that to the spec

wonsuk: in case of battery status, you want to see the value changes and not a specific event
... we have a subscription methodology, we will need to investigate others

kaz: we may want to have an extended version of subscribe which notices a significant change from previous poll

ted: i agree a listener would be advantageous and less expensive to developer but that requires processing upstream to trigger event. will oem do?
... i suspect many won't so i like extending subscription, cache of previous value, delta to consider change significant enough to act like a trigger and polling frequency to reduce cost when we are ok with checking every 10min instead of 10ms

<urata_access> https://github.com/w3c/automotive/issues/29

<urata_access> we did similar discussion recently.

greg: oem is not necessarily going to do the processing themselves or if they do willing to share

shinjiro: we already added duration to the subscribe method
... we did not want to overly complicate the interface
... i understand how setting a threshold would be useful as well
... we leave that to implementation specific solutions
... in case where battery is draining or tire wear increasing, people might want to be notified of delta event for a specific number
... event listener effectively deprecates subscribe and feel we should keep with a simpler subscription function

kaz: are you opposed then to extending subscription further?

shinjiro: it is possible. kevron lobbied to keep the interface simple and i feel the same way

dan: if you pass a callback function, your specific logic could reside there

paul: you need two data elements, actual battery voltage and battery status is low

greg: if that low status level is an agreed threshold

dan: passing your threshold value and callback function is what i had in mind, it could be an average or current value

ivan: just send the data to the callback function and leave the logic to them
... illustrated examples would be helpful

paul: are examples best within the spec or as a standalone document?

ted: concise examples should be included directly, collection of complex ones potentially split out and perhaps even published to an open repo where we can encourage their use and contributions

dan: i can see wanting a cloud based service or in car app running in the background detect the car is parked, it has started raining and closes the windows

paul: we went free form but we need to think about prioritization, which are candidates for further expansion etc
... which are out of scope for our specs
... spec was developed for on-board/in-car apps not external services although that is possible

dan: or a hybrid where data triggered by an event goes to an external service for evaluation, reporting and may send instruction back

[pause for lunch]

paul suggests we review the use cases together to see if they make sense

greg: it would be good in doing so to make clear to the security&privacy tf how they should work on them

paul: yes, first pass should be if they are things we definitely can expose through the api, priority, how to expand them
... we do not need to go full uml on them
... genivi tends to do quite a bit of use case mapping and it can be useful. you should be able to write test cases based on these
... end goal is to turn these into requirements for testing the spec

paul reads first one on wiping personal data on rental car

ted: it can perhaps be expanded to any shared vehicle situation, like borrowing a friend's car

dan: true but there may be some differences so maybe better to list separately

http://www.w3.org/2015/07/vehicle-data#personalization-interfaces

dan: clear contact information

paul: we don't do anything there

ted: could be something for the bg to take up because it certainly can be useful for apps to be able to access that

paul: this one can be expanded certainly
... i imagine the web runtime will not be active when the vehicle is off but cannot say that definitively, some may want to keep some background, low power capabilities

ted: there could be a signal sent (oem specific) to wake from suspend mode after which things can be queried

<kaz> kaz: in that case, we need to identify the state/mode of the car and the web runtime

<kaz> ... so we need some mechanism to manage the state and mode

(regarding wake-up signal)

kaz, we should perhaps raise this as an issue in gh

<kaz> yeah

<Dan> We may want to consider not only the mode of the car, but also the mode of the app. There may be things you want to allow the app to do in the background vs. foreground.

<kaz_> ISSUE: for remote controle and wake-up signal, we may need some mechanism to identify the state and the mode of the car, the web runtime and the application

<trackbot> Created ISSUE-1 - For remote controle and wake-up signal, we may need some mechanism to identify the state and the mode of the car, the web runtime and the application. Please complete additional details at <http://www.w3.org/auto/wg/track/issues/1/edit>.

<urata_access> off the topic. You may already but I found Genivi's vehicle web api reference implementation document. I though this might be good example for Testing Framework discussion because it mentions about data simulator and some test cases.

<urata_access> http://git.projects.genivi.org/?p=web-api-vehicle.git;a=blob_plain;f=doc/WebAPIforVehicleDataRI.pdf;hb=HEAD

Demo/Presentation by Sakamoto-san

junichi: we are looking at resource limits on vehicle and volume of data being processed
... logging parts to cloud. some want real-time monitoring
... it is necessary to monitor some sensitive data at least once a second
... we are providing on-board terminal, user interface and server side systems
... sever system is able to perform more calculations across specific and aggregate vehicle information

[review of project cycle - research, prototyping, inspection for mass production, mass production, improvement]

junichi: measurement to vehicle manufacturers, improve data workflow, ability to reproduce bugs and evaluate data
... it can be significantly easier to update cars than issue costly recalls to fix bugs
... there are several r&d teams at different organizations that are willing to share data

ivan: for reproducing bugs are you recording enough data to be able to reproduce the environment?

junichi: yes

[slide diagram of M2M architecture]

[slide on terminal system]

junichi: this system includes gps, 3g modules
... we used a usb-can transceiver circuit with read-only capabilities
... send function was disabled

[data filtering on terminal system]

junichi: we do filtering, re-sampling and data packaging

ivan: what do you mean by re-sampling?

junichi: combining like data
... and sampling different parameters at different intervals

[html5 ui]

junichi: you can drag and drop items onto your dashboard. it also can show graph data over time

[demo starts]

junichi: you can drag and drop from list various parameters you want to keep track of

[discussion of local data storage capability and deferred upload when network connectivity is interrupted]

steve: following this remotely you would see it as delayed then?

junichi: correct

paul: what is the main use of this is for oems, to verify their design?

junichi: our system is for gathering real time data. there are separate tools for analysis

paul: do you use other devices other than vtc-100 with the can transceiver or are there other ways you can collect?

junichi: just the vtc-100

shinjiro: what sort of typical time delay for following?

junichi: 10ms, usually worst is 1s

paul: you can guarantee the network?

[laughter]

junichi: i cannot guarantee the network
... we tried this Nürburgring, at a large test track in germany, with mountains obstructing cell signal
... we reduce the size of the packets to be transmitted as small as possible so we can get the payload out when we can, efficiently

greg: how are you securing the transmission?

junichi: https and device certification
... right now we are providing the cloud portion of the service but it can be an organization's private cloud

steve: this is being used when oem is testing vehicles
... are there any wanting to deploy this is production vehicles for real world data sampling?

junichi: yes. many are already doing telematics data gathering
... but typically their data sampling rate is too low
... server is able to detect some dangerous situations and report back to the user

paul: this seems like an area vector might be interested in

junichi: they are partnering

steve: the exi discussion yesterday from AgileDelta seems pertinent

ivan: did you create the interfaces yourself?

junichi: yes and all in html5
... we are using binary data format

shinjiro: which, something like exi?

junichi: no, proprietary

Presentation from Steve Ohmert on OpenCar Security

steve: i'll review our architecture in brief and security considerations
... we went through an outside review and certification
... we are a html5 solution. this application framework shows the different levels, web runtime, localhost capabilities

[slide of all the components]

steve: we isolate all the different layers and applications, similarly control all connectivity in and out
... we need to make sure everything is coming from our system, going through our gateway
... the browser runtime only talks to our local server
... the host layer handles all external connections

[diagram on connectivity]

steve: we make use of html5 web workers
... actually we have several different models but in this diagram it is web workers and iframe
... iframe is separated at dom level. we isolate with content security policy (csp)
... the applications are only allowed to communicate through a message pipe
... we keep the message communication constrained
... gateway, rest server, logic layer that restricts specific data access permisssions
... what sorts of concerns are you hearing? what security issues are you hearing?

dan: we are defining parties and what data they can get at. most things are explicitly read only

steve: we have two ways of addressing that in our system. anything going into the car is certified and embedded
... we have policies on which information is accessible to specific applications. we also generally expose things for read access

dan: who grants permissions for applications?

steve: the publisher includes in their package manifest what they are seeking access to

hashimoto: how do you handle the app install?

steve: package is download, checksums verified and then installed to run locally

hashimoto: it sounds similar to firefox os model

<inserted> scribenick: kaz_

kaz: question about the interface between the integration layer and component modules via websocket

steve: @@@

paul: explains OpenCar's downloadable version of SDK

steve: separation of HMI and app logic
... security concerns with downloadable apps?

ivan: you could send data to the headunit to open the door

steve: you need to have separation mechanism
... something has to say I have a permission

hira: how do you protect apps to be peeped?

steve: using a sandbox container is one level
... construct a barrier is another
... application should have access to various resources
... certified permission only allow components to access some specific information

paul: also signed application

steve: this kind of mechanism is common with any downloadable apps

paul: permission from web runtime is not directly tied with the OS

steve: some constraint for integration
... desire to allow JS codes to access low-level information is not a good idea

(thanks from all to Steve)

[ afternoon break ]

Use Case discussion (revisited)

paul: we did much discussion on use cases during this f2f meeting
... some same people should overview all the use cases
... I will overview them
... some others should also review them
... issues should be tracked on GitHub
... will do my review this week
... Hashimoto-san should also do the review as the Security&Privacy TF moderator
... what about Wonsuk as one of the Editors

wonsuk: we need to describe our use cases more clearly
... also we need to describe our requirements
... and then we can get feedback from others
... should we add descriptions to the wiki?

paul: we got high level use case descriptions

ted: we can continue to use Google Docs for a while

paul: does that make sense?

wonsuk: yeah

paul: at some point we should be able to say "this is our scope"
... would say less than one month

dan: what is the criteria for prioritization?

paul: have some idea, put it on the wiki, and have discussion
... we have two meetings
... August
... Asia friendly one and Europe friendly one
... Aug. 4 one is in the morning in Asia

wonsuk: can't make it

paul: should be better to make 1 hour later?
... does the security&privacy tf have regular calls?

hashimoto: no
... holding email discussions

paul: next Tuesday we'll talk about use cases
... if you guys (security&privacy tf) can talk with each other beforehand, would be good
... can talk about prioritization
... have a lit of topics
... will send it to the group

<scribe> ACTION: Paul to send out the list of topics based on the f2f discussion to the group [recorded in http://www.w3.org/2015/07/29-auto-minutes.html#action01]

<trackbot> Created ACTION-9 - Send out the list of topics based on the f2f discussion to the group [on Paul Boyes - due 2015-08-05].

paul: will talk about ISSUE-37 as well
... can you lead the discussion, Wonsuk?
... you can respond to the GitHub issue 37
... got no response from TAG yet

wonsuk: pros/cons of each method

paul: Urata-san also should be involved
... that's pretty much what I remember

kaz: wanted to double check the Aug. 4 slot
... 5pm Pacific?

paul: yes
... will send an announcement to the group

kaz: another topic I wanted to mention was demo showcase during TPAC 2015 in Sapporo

ted: should forward the announcement to the group list

kaz: ok, maybe the Member list

hira: question on user identification

paul: have a list of issues including that
... will send a message to the group
... we can add issues on GitHub
... probably 5-6 issues

hira: ok

greg: onborad vs offboard

ivan: electric vehicle and hybrid vehicle?
... just curious

greg: in the battery section

ted: trying to get those automakers as well

paul: can we invite them to one of our meetings?

(some discussion on related stakeholders)

paul: maybe you (those don't participate in the WG yet) can join the BG as well
... next f2f meeting on Monday/Tuesday (Oct. 26/27) in Sapporo

ted: tx to Paul and OpenCar :)

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/2011 for the latest spec/2011 for the first edition recommendation/
Succeeded: s/started back in 2004/second edition Rec in 2014/
Succeeded: i/shinjiro:/kaz: there is discussion on EXI within the WoT IG as well, so maybe it would make sense to have joint discussion with them, e.g., during TPAC 2015 in Sapporo
Succeeded: i/topic: Agenda/[ Day2 ]
Succeeded: i/[EXI vs gzipped BSON, CBOR]/scribenick: ted
Succeeded: s/wiki by Kevin/Use Case Wiki by Qing An/
Succeeded: s/access/direct access/
Succeeded: s/for that purpose/to manage the state and mode/
Succeeded: i|we are looking at|topic: Demo/Presentation by Sakamoto-san
Succeeded: s/at a large test track in germany/Nürburgring, at a large test track in germany,/
Succeeded: s/agile/AgileDelta/
Succeeded: s/Topic: Presentation from Steve Ohmert/Topic: Presentation from Steve Ohmert on OpenCar Security/
Succeeded: s/JS/JS codes/
Succeeded: i/question about the/scribenick: kaz_
Found ScribeNick: ted
Found ScribeNick: kaz_
Found ScribeNick: kaz
Found ScribeNick: ted
Found ScribeNick: kaz_
Inferring Scribes: ted, kaz_, kaz
Scribes: ted, kaz_, kaz
ScribeNicks: ted, kaz_, kaz
Present: Wonsuk_Lee Steve_Ohmert(OpenCar)

WARNING: Fewer than 3 people found for Present list!


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 29 Jul 2015
Guessing minutes URL: http://www.w3.org/2015/07/29-auto-minutes.html
People with action items: paul