Yesterday's minutes on this topic
Ted summarizes yesterday's discussion
VISS & VIAS
Urata:If W3C Directors made the decision, ACCESS understands with VIAS becoming a Note
... we have certain amount or implementation as a JS library and might publish it
Rudi: re VISS I would like to see us close the remaining issue
agreement on plan re v1 and v2 recharter
action Ted to write summary of the decision
<trackbot> Created ACTION-27 - Write summary of the decision [on Ted Guild - due 2017-11-14].
action Ted to draft recharter
<trackbot> Created ACTION-28 - Draft recharter [on Ted Guild - due 2017-11-14].
s/of the discussion/of the decision wrt v2/
Patrick: re LBS I think open
street maps would be good indeed
... they have the elements necessary and it would be easy for
developers to start playing with it and won't necessary have
access to Tomtom or Garmin
Magnus: I will discuss internally to see if I can get contacts for us and HERE
Ted: we have had some conversations with HERE initially on Sensoris that were favorable but more contacts there would be good
Peter: we are doing more with Google these days
Gururaja: on media, Adit - collab between Bosch and Denso
Magnus: we are doing pieces ourself, otherwise I don't know
Patrick: we mostly send out RFP
to suppliers
... iHeart as an example is looking toward the future and get
an advantage over the other media providers by being
adaptive
... it is important to have a reference implementation and at
least one company behind it. for LBS that could be
openstreetmap
... and then I can put that into my RFP to the other nav
providers
... point them at the spec
<Rodrigo_> i'm ex-Nokia and know very well HERE team. Let me know if i could help.
Rodrigo, yes please
Peter: how good is osm coverage these days? in some areas the coverage is better and it keeps improving
Patrick: it is okay-ish, it is
quite good for test bed purposes
... they have a good schema
<Rodrigo_> TED - ok, will do. Will align details of the request with you later and shoot the msg.
Peter: plus it is open source
Ted: another area we hoped to further for some time that I don't have on the list is voice. Nuance was a W3C member but wasn't interested in engaging
Patrick: in what context?
Ted: multi-modal for UX and accessability
<wonsuk_> Web Speech API Specification : https://dvcs.w3.org/hg/speech-api/raw-file/9a0075d25326/speechapi.html
Ted: there is a W3C CG focused on generic API based on Google's voice engine but we are not looking at it from aut at this point
Wonsuk: here is link for Google
based approach
... it is for speech interactions for web applications
Patrick: that could be very good
Agreement earlier to add Notification to list of "modules" for RSI
Patrick: issue will be binding that to Nuance
Ted: they have a monopoly now
Patrick: there is no suitable open source solution
Peter: we looked around when I was at Melco, nothing sufficient
[searching recollection for name CMU's swings]
Peter: if you compare it to Siri and others it isn't sufficient
Ted: we should encourage CMU to
follow and participate in Web Speech API
... any other modules we should be discussing?
Patrick: I can now talk about
Notifications. there is some IP there but we have partial
approval
... if we see things going forward we can open it up
Ted: no pressure, choice is to get it listed in the WG recharter or leave it in BG incubator
Wonsuk: what is the difference between this and push notification using web push?
Patrick: that Google based model
is triggered from bg and should come into foreground and the
needs on IVI are different
... what we were building is a central point of collecting
notifications and you can pull out which are needed
... we might need web push as well
... for ours we are listening
Magnus encourages Ted to talk with Open GeoSpatial Consortium
Ted: not explicitly re auto but
more generally we are talking to OGC about joining W3C
... re notifications we also want to handle v2x where x is our
car and need to alert user/driver
... some sort of push to the vehicle (client app receiving
notif as described by NHTSA) and then using your notifications
system, prioritization rating
Patrick: we haven't been looking at RSI that way yet but it would be complications wrt our protocol choice
Ted: perhaps using the socket, not REST
Patrick: connection could timeout, maybe some polling
Ted: this is a use case for our conversation with W3C TAG on HTTP2 and Fetch. HTTP2 does have push capabilities
Magnus: it has been some time since I worked with v2x. you will also have issue of needing to filter out irrelevant signals for current needs
Ted: RSI notifications is more on the receiving end. on the broadcast an app can use our signals + nav specs to send information of an event eg TCS engaged on highway to regional DOT with NHTSA's protocol
Patrick: I find that
interesting
... I am supportive of that use case
Magnus: that may be for later. for me one of the key items is to web developers to create apps
<Rodrigo_> Is there any use case where data (vin, odometer, info media being played) is obtained via a mobile app or service worker in the cloud and sent back to a car component to be displayed at the car HMI/screen?
Ted: think of NHTSA or whooever
as an app dev that is using our specs, we might not need to do
anything explicit for them
... if someone develops such an app that meets the requirements
regulators will be imposing using our model that will draw some
attention and spur RFP to tier 1s
Ted's presentation on MIT research group proposal
[Agenda bashing for afternoon]
[summary of specs and recharter plan for Volvo attendees]
[need for fresh use cases]
Patrick: use cases are for the developer not the customer/driver
Barbara: i recommend refreshing
them
... they have different personnas, one could be oem, end user,
developer as well as perhaps the key one
Patrick: I want use cases to align with the different milestones
<ted__> [initially review previous use cases with intent of regularly refreshing]
Patrick: do we want this bound in the charter?
Joakim: we did so for media
<joakim> https://www.w3.org/TR/2009/WD-media-annot-reqs-20090604/
homework for thursday, everyone write 10 use cases to wiki
<PatrickLue> Use Case descriptions here: https://github.com/w3c/automotive/wiki/Use-Cases-for-in-car-communication
Magnus: re privacy use case being discussed, to a certain extent it will be up to individual OEM preferences and local country regulations
Ted: incidentally Privacy INterest Group (PING) is eager to work with us. spec should have mechanism for granular acls but it would be more in the realm of guidelines to spell out sharing/opt-in considerations per app
https://github.com/j3ss5t/viwiLocationBasedServices
<peterw> VSS : https://github.com/GENIVI/vehicle_signal_specification
https://www.w3.org/community/autowebplatform/wiki/Main_Page#RESTful_Service_Interface
<PatrickLue> RSI Github: https://github.com/w3c/automotive-bg/tree/gh-pages/rsi
https://www.w3.org/wiki/TPAC/2017/SessionIdeas
explanation of breakout session mayhem
<wonsuk> 8 November Plenary Day Schedule: https://www.w3.org/wiki/TPAC2017
Patrick: we are going with 2FA based on having phone+app and knowing pin
<ted__> Proposal for joint TF with Payments activity
<ted__> Automotive Payments TF wiki
<ted__> Pay at the pump explainer
[sharing of pain points from various experiences]
[review of charter, wiki, proposal slides, pay at pump explainer]
Magnus: we have a mobile provider called Swish using an app on your phone with 2FA that you can send funds to another person
Patrick: Paypal and Shell are already doing some alternate pay at the pump options
[Prerequisites : The user has internet connectivity.]
Patrick: promise might be acceptable in some situations
Magnus: most vehicles now adays
have capability to connect to a local wifi
... OEM could manage POI connection information, including way
to verify certificates before connecting to service station
wifi
Patrick: car itself acts as a
half decent faraday cage, you'll need an external antenna
... requiring a connecting is an issue for vehicle usage
Caleb: toll (or whatever) system
could have the network connection and go off of license plate
and/or identifiers from NFC/DSRC
... we have lots of charging stations in garages where we know
there is connectivity problems
... we have to rely on trust factor in some cases
Patrick: a car could have a certain number of one time use tokens it could communicate to the merchant
Caleb: sort of like crypto currency exchange at that point
Magnus: blockchain could factor in
Patrick: chain would be useful for protecting the transaction itself but a token communicated could suffice
Magnus: you will need to register
for some service even though you are not interacting directly
with the pump
... ensure you are you. that is done today by signing
... how much do they expect biometrics or other auth
... you need to identify yourself
Ted: one option is to store your payment preferences on phone and proxy encrypted payment requests from the vehicle to it
Magnus: having a personal signed
certificate as your guarantee/signature
... this is already done today in signing data
[[If the browser is aware that this is a payment in a physical location]] what does this mean, confusing
Proposal to drop RSI calls since we are converging. maybe editors and Team contact will meet
Patrick: I think the BG meeting twice a month is a good idea. I would prefer the WG meet weekly
<PatrickLue> CEST: 6am / 3pm / 11pm
<PatrickLue> EDT: 12am / 9am / 5pm
<PatrickLue> PDT: 9pm / 6am / 2pm
<PatrickLue> BST: 5am* / 2pm / 10pm
<PatrickLue> JST: 1pm / 10pm / 6am
Agreement in the room to change to this proposed call schedule. Ted will send to WG mailing list for consideration after we settle charter issue. New schedule likely to take affect beginning of the year.
Hira: for payments we should collect distinctive use cases that cannot be covered by phones