Slides: https://lists.w3.org/Archives/Member/member-automotive/2017May/0016.html
Peter: first slide is a rough overview of the architecture
... on top applications, then implementation in C++/QT of W3CServer
... we used OpenDS signal similator developed by some university in Germany. we used the open source version, there is a more robust commercial version as well
... we modified it slightly for our needs
... next slide, flow diagram of a subscription
app->w3cserver->processrequest (runs as separate threads)->requestion handler->subscription handler->vss signal broker then down to CAN, flexaray
(there are a number of other possible flow paths in diagram)
(auth handler, auth manager, json request parser, get/set handlers, unsub hander,getvss handler, rvi, opends similator)
Peter: quite simple really
... some of the signals in our demo were not realistic
... we were really happy to find opends. JLR has another and believe they sometimes use a proprietary one
[discussion of threading in Qt]
Ted points out the benefits of HTML5... :P
Peter: the open source licensing of Qt is driving some people away
Urata: if you use an obd2 dongle to a real car instead of opends
... then this would be immediately useful
Peter: Magnus (Melco) is working on that, similar to what you did in the Prius
Wonsuk: I'm also looking for a good dongle
Peter: depends on what you are looking for for connectivity
Paul: problem is they're slower
... if there were an OEM willing to step up here...
... some cars expose high speed CAN
... you need the definitions to map
Kevin: I believe our vehicles are available at the dealership
Urata: too expensive for testing
Peter: Rudi did something with an ODB2 and python scripts, not sure if it was BT or USB
Adam: our networking folks are pretty hesitant about exposing those definitions
Urata: this going to be part of GDP?
Peter: not sure because of Genivi's licensing preferences and QT
Ted: I've been wanting an open OBD2 Linux platform Vinli or Samsung's for live signals. Sanjeev pointed me at a crowdfunded one that hopefully will be available soon
Paul: problem is subset of signals and signal speed to be useful
Urata: this will be open source?
Peter: it is presently on my github account and will be moved to a Melco one, they are willing to go open source here
... we have more brush ups
Urata: mine is just for testing and do not plan to improve it
[next slide]
Peter: Peter: on a raspberry pi, performance was no problem. opends is java based
...server + broker in Qt5.6
... we have demo apps for android, iphone, html5/js
... when you have it up and running it is very easy to use our specification. it is really easy to write applications against it
... showing how good the specififcation is
... client demos on separate gh repo
[next slide]
Peter: we haven't found any really big issues
... it would be better to return things in an array
... filter function becomes complicated and trying to match different types and units
... we might want to look at filtering again
... we also noticed different clients (eg on iphone) implementations of websockets vary widely
... some of those are not very active, simpler proof of concepts by individual developers and not polished commercial products
.... webview in android does everything well
... we haven't done any benchmarking but simply watching load on the rpi with many concurrent connections we only used 3% of the cpu
Urata: you check latency?
Peter: no
... we haven't implemented servername. device token needs to be added. need to add system test to test suite
... also need to configure and run Urata's test suite
Eric: is there only one server instance per device?
Peter: we are running one server for all devices
Eric: can you run multiple?
Peter: sure
Ted: why would you want to other than to perhaps sandbox one further?
Kevin: some companies will have different mental models about how they want to architect their head units
Adam: back to returning arrays
... it depends on what you are requesting, some times you'll just get a single leaf
Kevin: an array can have zero one or more elements
... we can raise the issue
Ted: sssh! wait until after we go to CR to file it :)
Slides: https://lists.w3.org/Archives/Public/public-automotive/2017May/0001.html
Urata opens test suite client in browser (URI not public)
Urata: in this example get and subscribe are available
Ted: remind me of the signal source, recorded and played back or?
Urata: mock data
[example doing get and then set on door lock]
Urata: data model coming from VSS definition
[next slide on VISS proto block diagram]
Urata: I'm using a simpler mock server than Peter's opends
[next subscribe flow diagram]
[subsribe and authorize models, next slides]
Urata: what I want to show is
when client sends get method it converts to json, sent to
server via websocket
... there is a ws receiver. request is tored in request
queue
... request id is a unique key
... reqid is necessary since client doesn't know response is
based on which request otherwise
... this is basic structure of this implementation
Peter: are you waiting for value to come
[next slide on multiple client handling]
Urata: there is only one web
socket server instance, all clients connect to it
... but I create a "session instance" per client
... each with their own request queues
... if many clients are connected performance might decrease. I
haven't benchmarked against multiple yet
... yesterday we had a discussion about what happens when
multiple clients make a set
Ted: that can be a problem with different queues breaking the "last wins" model we discussed since a queue could be busier and break ordering
(across all queues)
Urata: that shouldn't happen but I cannot say it won't happen
Ted: remind me and apologies for not knowing but we have timestamps on requests?
Peter: yes
Ted: then we should have the central clearing from the multiple clients keep a cache and discard an outdated, conflcting set request so last still wins
Eric: that is the right way to handle it
Wonsuk: have you run your prototype against your test cases?
Urata: yes and will show the
demonstration in a bit
... here is the W3C's automatic test framework with our
tests
... presently we have 31 tests
[local server instance demonstrated]
https://github.come/w3c/web-platform-tests
Urata: they are separated by test
categories and I added vehicle
... nearby is https://testthewebforward.org
where W3C encourages people to contribute tests
... next slide on vehicle api case
<wonsuk> https://github.com/w3c/web-platform-tests
[test framework structure]
Urata: when I check out this repo
from w3c's gh there is a web platform test framework and
folders for each web api
... including a test runner html ui, there is a testharness.js
helper library
[slide on simple test case]
[Urata demonstrates running his test suite in local instance of web-platform-tests]
<scribe> scribenick: ted___
Urata: be sure to adjust your timeouts when running the tests as they take awhile
[summary slide]
Urata: some data has value ranges in addition to typing
Frank: we have an abstraction
layer on our side. we want to produce a standardized/semantic
data definition
... we have a huge number of data and concern on data which is
why we are interested in what you are producing
... we should be able to support all the vehicles
Urata: VISS is conforming to the specification and isn't looking at performance
Frank: understood, this is the necessary first step
Urata shows Hira's latest implementation plan
Hira: I changed document style from powerpoint to html5
<wonsuk> https://www.w3.org/WebPlatform/WG/PubStatus
<wonsuk> Implementation report: https://w3c.github.io/test-results/pointerlock/all.html
<wonsuk> Implementation report for HTML Canvas 2D Context: http://w3c.github.io/test-results/2dcontext/all.html
<urata> <wonsuk> test report plan document name should be renamed to 'test guide' etc.
<urata> <wonsuk> this document should be put into github so that members can comment, send pull request.
<hira> https://github.com/w3c/automotive/issues/123
<urata> Sec1 to 5 should be separated as 'testing guide' document. (tentative name)
<urata> test assertion part should be separated to a document ( or 2 documents such as 'VISS test assertion' and 'VIAS test assertion')
Paul demos Busmaster for recording singals, works well from eg Mazda and Ford
<wonsuk> https://rbei-etas.github.io/busmaster/
Paul: you'll need to do mapping through VSS
... windows based, they tell you how to extend it
... FOSS
Paul: somewhere on open garage site is links to CAN ID from a number of different manufacturers
(Craig Smith)
<Ian> https://www.w3.org/2017/Talks/ij_transactions_201704/w3c.pdf
<Stiepan> thanks ted
<Ian> https://www.w3.org/2017/Talks/ij_transactions_201704/w3c.pdf
Ian: slide 9
... you are on your mobile or laptop/desktop browser. this slide was for demo at u.s. treasury department so we chose buying a national park pass
... it is a push payment model. in an improved payment model slide 14 shows the streamlined process
... merchant calls the api, (used chrome in this example)
... merchant can ask for contact info, shipping location and browser can send with user consent this information
... it shows some information stored by the browser previously
... payment methods known by the browser that the user has
... browser has credit card information goes to merchant's bank
(not the merchant itself)
Ian: in thinking of pay at the pump use case
... car has payment apps provisioned by the car owner, fleet manager or user so that there is pre-stored information (including card info)
... basically on the car there are payment apps
... when you go to the pump you are prompted by the fueling/charging station to determine what services you want gas, wash, other
... one scenario is that cvv code is required or it could be stored
... some sort of confirmation is required
... the flow from our perspective using this api is seeing if the web merchant model works
... the website of the service provider needs to interact with the vehicle
... our api is not specific to cards, could be bitcoin or whatever
... we have 3 kinds of payment apps that can live in the system
... first is in the browser themselves.
... they already streamline checkout with auto-fill. this is an improvement
... next is mobile payment apps (google pay, alipay etc)
... this week we saw a demo with square that used android specific protocols
... alipay is a proprietary payment method but can still be used - native payment apps
... the way they talk to the browser will be proprietary
... third is payments from websites, mastercard has native app but can process their payments through websites
... data storage is shifting to the user side
... one effect of having data on user side is improving security. payment tokenization is off sites and onto apps
... we are working on a tokenization payment system for increasing security
... two specs, one at cr maturity level and other going to fpwd
Paul: some OEMs may not be planning on including a browser runtime
Ian: we understand not wanting open web access. it can be restricted to known vendors' sites
... what we haven't worked out was how to pair phone (with payment apps installed on it) paired and process payments on behalf of cars
Wonsuk: are there any plans for a RESTful API (in addition to WebIDL, in browser)
<Ian> https://github.com/w3c/webpayments-http-api/issues
... then any client including native apps could
<Ian> https://w3c.github.io/webpayments-http-api/
<Ian> https://www.w3.org/TR/webpayments-http-messages/
Ian: Manu Spory and Web Payment have some ideas for out of browser payments
... using HTTP, including message format
... we decided as a group there was more interest starting browser based and after gaining experience
... there is interest but not pursuing actively until we see how this goes
Rudi: what is the southbound interface for the payment processing?
Ian: that is a native payment app (PSP) and its job is to initiate transfer
... it has user and payment data to be able to handle the payment and get response status (success, failure) client can convey to merchant
<Ian> https://www.w3.org/Payments/IG/wiki/Automotive/UseCase_PayAtPump
Ian: John (IFSF) has been putting in requirements in the wiki
... this abstraction layer lets you avoid custom integration with multiple individual proprietary payment apps
Paul: useable by drive-thru restaurants as well
Ian: some of the other conversations with John include how to send information from a beacon via BT or other, get the pump number etc
Ted: another colleague (Dom) relayed bits on existing BT api options at w3c that can provide that piece
Stiepan: my question is about car-phone pairing and next steps related to it
Ian: we have some technoligies to handle web notice or push api but I am not super familiar with them
Rudi: how does this differ from entering credit card information or paypal?
... on current sites
Ian: this is stored on the user side
... for the user less typing. merchant doesn't need forms nor do they need to store sensitive information
Rudi: they don't want to because of PCI
Ian: right they would have to go through eg braintree
... merchants can still collect information on users for customer service
Rudi: on chrome i can store my payment information already if I'm brave enough, is this an extension?
Ian: yes and it just does pre-fill, you still need to tab through the fields
... this doesn't require a form
... they can do more by knowing data is available and having the client send it on their behalf
... this streamlines the user experience
Rudi: now I'm getting the hang of it
... what are the security ramifications
Ian: api still results in data going to merchant. we are planning to increase security with tokenization
... the 70,000 user credit card site hackings will be reduced as a result of this approach
... our group isn't constraining any particular type of storage
Rudi: can a malicious website tease out a transaction without the user's knowledge
Ian: today if I visit a malicious website and am duped, nothing I can do
Rudi: what about a malicious site using this api
Ian: that is a misconception. we can do better than the status quo to phish users. it is harder to hack than a webpage
... underlying payment apps themselves can and will do their hueristics of sites before completing the transaction on behalf of the user
... these are the sort of conversations we are having
Rudi: agree, often convenience comes at the expense of security
Junichi: if user wants to user multi browsers, the user has to input his credential on each browsers. it seems to be disadvantage compared to amazon like site.
Ian: mozilla started with desktop, google from mobile
... it shouldn't matter which you are doing in the long run
Ian: the more merchants that start implementing this more we'll see it pervasive
<Ian> https://github.com/w3c/payment-request-info/wiki/FAQ
... some merchants may not adopt it. some prominent ones like shopify intend to. amazon, may not for their site although they are attending meetings but would like to see amazon pay elsewhere
Ian: please also see our FAQ
Rudi: for GDP since we're using chromium it makes sense. the secured storage model might have other interesting uses
<junichi-hashimoto> another question i could not ask was which module/app is responsible to check user identity. in the case of car scenario, I don't want my son use my credit card for instance.
Ted describes benefit of this abstraction layer to multiple payment apps, not needing to integrate each
Rudi: I could see JLR wanting to become a payment processor and have app of their own
Urata: only a couple issues remaining on VIAS
... I think Rudi's is already resolved
https://github.com/w3c/automotive/issues/183
Urata: I think we can close
Ted: he reviewed the merge so ok to close
https://github.com/w3c/automotive/issues/198
Urata: authorize should not be DOMString but changed to Object
Adam: that will allow for multiple tokens
Urata: next part of this issue report is about naming, the subscribe callback method
... Adam suggests SubscriptionCallback
... I understand the point but this function handles both on-subscribe and on-subscriptionNotificiation
... I thought having two callbacks is redundant and thought it would be nice to simplify
PatrickB: wouldn't promises be better?
... you will get either your callback or the error
Urata: yes, one idea on solution would be using a promise
... I inherited this interface from Powell's idea. more common way is using promise
Wonsuk: there are two different approaches. in case of connect our interface provides success or error callback
... subscribe only provides success callback
... why provide two different interfaces
Urata: connection can be lost for various reasons. disconnect callback should be called in such cases
Ted: I recalled this came up before but do not believe it was fully resolved due to end of year slowdown then CES scramble
https://www.w3.org/2016/12/07-auto-minutes
[[powell: was there a decision on promise vs callback vs vanilla? rudi: vanilla ted: given how few callers we have that might be a good question to pose to the mailing list]]
(we were not giving Powell enough feedback at that point)
Ted: I think we can decide here on promises
Urata: I am fine with that
Adam: I like promises but do we have to be concerned with browsers not supporting promises
Paul: I know there are some older browsers in automotive
(webkit, especially in Qt)
<wonsuk> http://caniuse.com/#search=promise
<junichi-hashimoto> A minimalist implementation of a javascript promise https://gist.github.com/unscriptable/814052
Urata: do we have to support older browsers?
Adam: they can do callback
Wonsuk: I am in favor of promise
Junichi: we cannot translate simply error callback. error callback should only be called once
PatrickB: if you read the API you will get the promise only for the subscription
... if it fails you will enter the error path of the promise. when the connection breaks after you have to handle error on success anyway
... promise is on the subscription not on the connection
... you have to handle interruptions anyway
Urata: that is handled by the disconnect method
PatrickB: the success callback of the subscription needs to handle the subscription itself. the subscription object will have onmessage etc
... if we do multiple calls on the same callback then we need reactive programming
... that is highly valuable but far from a standard
... messages or errors could occur after the subsription
... you are confusing message and subscription callback
... I am a fan of promises
Urata: the onmessage cannot be used for continuous callback
PatrickB: think of a try {} catch {} block
Urata: will getVSS confuse the promise
<junichi-hashimoto> @23:53, I wanted to say that callback functions which could be called several times cannot be translated to Promise format
Urata: subcribe can't be handled by promise
[no ready solution making itself clear]
Wonsuk: promise has some limitations but we may be missing something
... we probably need to investigate more before we make a decision
Paul: criteria is to make the api more useful
Urata: we can leave this pending and go to FPWD
Paul: it can be a comment in the doc (since people don't look at issues list)
Ted: advantage of FPWD is we'll get more eyes on it and someone looking at it might have a good solution
Urata introduces WS in spec when we only support WSS in the spec
PatrickB: that becomes an issue with additional devices in the car (eg smartphones) and the vehicle not being able to update nor give an authorative (self signed) certificate
... self signed is a non-starter. also what if the root CA gets updated?
Ted: Junichi did a presentation at our Lisbon meeting on exactly this issue both to Auto WG and as an open session to rest of W3C TPAC
Urata: he opened a community group on it
<Stiepan> What is the link for the community group? (This relates to my previous question)
Ted: also surely an issue for WoT who were probably part of the Lisbon breakout session
<junichi-hashimoto> current wg consensus is to use special hostname, self-signed certificate and install self-signed root CA certificate into the client browser
<junichi-hashimoto> host file might be needed as well
<junichi-hashimoto> HTTPS IN LOCAL NETWORK COMMUNITY GROUP https://www.w3.org/community/httpslocal/
minutes of Junichi's presentation at Lisbon F2F
<junichi-hashimoto slides
<junichi-hashimoto> welcome:) --ad-- now the cg call for participants. https://www.w3.org/community/httpslocal/2017/02/06/call-for-participation-in-https-in-local-network-community-group/
<Stiepan> lost audio for some time; many thanks for the additional link Junichi, this looks really promising!
<urata2> https://www.w3.org/community/httpslocal/
<urata2> community group about http/wss in local network
issue-198 subsection 5...
Urata: I agree nullable can casue problems
Adam: our websocket spec has some get like functions
Urata: VIAS doesn't care if it is websockets or HTTP Rest underneath. having disconnect/connection optional isn't ideal
Paul: what happens when you have multiple subscribes?
Urata: VIAS was initially considered a JS library to sit on top of VISS. Hira/KDDI would like possibility of VIAS being on top of something else
Paul: does VIAS need to manage connections? how to handle unsubscribe when you have multiple subscriptions?
Urata: subscribe could be realized without web socket
... eg using web push technology
... VIAS doesn't care what is underneath
... connect/disconnect may not be needed by some
Paul: I would be inclined to drop them then
... have it handles under the covers
Ted: implementation specific can handle when it needs to subscribe
Wonsuk: handling multiple protocols underneath gets complicated especially for brower vendors
Ted: not necessary, they could choose and implement one
Wonsuk: think of the JS frameworks like Angular
... for example web storage which can be varied
... the more abstract and consistent the api you can make the easier it is for the developer
Wonsuk: frameworks at good at abstracting out complexities and varied browser capabilities
... what is the goal of this specification? we need to provide standard api to access vehicle signals
... here we want a more convenient api for developer
... not sure removing connect/disconnect and leaving it to the implementation is the right answer
Paul: as a convenience developers do not want to manage things like that
... framework yes, let it handle that but what are we defining here?
Ted: in addition to HTTP rest and sockets, some may choose to do WebIDL to talk to native libraries on the same host which will not have concept of connections
(at least not a network connection. connect method could check responsiveness to underlying c++)
choice is either leave it implementation or handle each (we identified three, potentially others) connection means (or hardwired if a browser extension or in browser
Ted: again we can go the comment route and people can tell us we're nuts or provide a solution based on elsewhere
... i can try to ask around beforehand
[discussion of next teleconference, cancel next tuesday due to travel/vacations. vias draft with comments can be done. call for concensus email can be done by any chair and doesn't have to wait until the following tuesday]
Ted: I want us to reboot our Privacy and Security TF. It has been fairly dormant apart from the https local topic. There was only one teleconference held and no mails to list in months.
... I have been partially participating in Genivi's Security Expert Group. We are in their queue for a review which starts with building an attack tree, then thinking on mitigation techniques. I made a presentation to them before lunch on how 3rd party app market could be structured with W3C Guidelines
https://www.w3.org/2017/Talks/tg-genivi-uk-sec/
Ted: We will have to cover other topics like rechartering, which at this point will not include RSI since that will follow BG report route at this stage, via email or subsequent teleconferences.