Automotive Working Group Teleconference

wwwivi

https://‌github.com/‌w3c/‌automotive/‌issues/‌223

Ted provides summary

simplest case is 1 service per vehicle and only the head unit is allowed to connect. there are scenarios mentioned where there may be more than one service and devices allowed on network can connect which supports discovery. This has always been awkward and sparked questions.

Ted: we should conclude to go with zeroconf/discovery of eg mdns. question is would a static fallback be acceptible. incidentally I agree with Gunnar's comment in mail on how wwwivi wouldn't be the best choice for the name

Gunnar: viss.local was my suggestion. what is the actual mechanism being considered

Ted: issue I have with discovery is requiring each application to have to go through that process each time
… doesn't make sense for head unit for a given vehicle since there shouldn't be change, need to rediscover

Gunnar: @@

Mike: wouldn't this only apply when the service is running on a separate virtual host, would it often be localhost
… I understand we may support more than one VISS server within a vehicle
… it makes no sense to do discovery when it is on the same host

Ted: agree but that isn't necessarily the case

Mike: you could say in the specification that if you are allowed multiple a good naming convention would help
… I have been playing with mdns some. there is filtering capabilities
… we may want different names for the different roles

Gunnar: I am a bit reluctant towards that idea. how would you define a future IVI system with a different purpose later

Mike: that was more of an example than a real suggestion

<KevG> Also, we would need to allow others to use ivi as a term hence wwwiviv.local

Gunnar: you did bring up a good point, multiple nodes might be answering which we want to address

<KevG> Sorry mistyped, meant wwwivi.local

<KevG> or w3civi.local

Gunnar: preference might be for a local one before going out to the network

Ted: one idea is zeroconf discovery takes place during app install and generates a static conf

John: we had similar problem with IFSF, you don't want to reboot a service station
… we sit on a given port and broadcast (UDP) the other devices pick it up and use it
… we didn't want all the discovery effort

Ted: yes similar here

Mike: BLE (bluetooth beacon) is being supported by MS for parking meters

[we are consider BLE for fueling see https://‌github.com/‌w3c/‌automotive-pay/‌wiki/‌PayAtPumpExplainer]

Ted: for discovery I can also imagine a rogue device advertising itself as providing VISS and mitm the real service, steak tokens etc

Mike: application on smartphone is a bit different, it can also be involved in making payments. tollgate can talk to RFID reader which can talk to mobile phone

Ted: back to the specifics of wwwivi. What I am hearing from the W3C TAG and IETF (indirectly, there is overlap) is static is short sighted and we should do discovery
… we have issues as a result. 1) need to have client apps able to do discovery 2) this introduces overhead and modest delay on each reboot of the car 3) attacker could try to respond faster with mdns reply to advertise a mitm service

Kevin: parts of the vehicle rarely if ever shutdown so it is possible to keep some continuity
… manufacturers might want services on the vehicle to remain available overnight for eg SOTA updates
… often things will disappear off the network when the car is powered down. we might want some to persist to prevent rediscovery

Gunnar: I think we may be overthinking this a bit too much
… if you can discover the service at the first boot you can on subsequent
… there are some key issues here such as the security concern mentioned and included in the spec
… in the end we are just doing name->IP recognition
… simplest solution is eg an /etc/hosts entry

Kevin: it is a bit more complex than that
… on a linux based system you could have localhost and specific port number
… you can have other hosts that wish to connect

Rudi: it seems we are going around in circles. perhaps we can start simple and revisit when necessary
… we can think of a more elegant solution later

Ted: I did like the initial keep it simple approach for WD, I am hearing we may be blocked going to CR if we don't do discovery

Gunnar: we can have a tiered solution, local, local network at given name, discovery service
… choice can be left to the implementer

Rudi: we have to be consistent for sake of the app developer, simplest is a defined hostname
… I appreciate the merits of zeroconf but hesitant to prescribe a solution

Magnus: why can't we support both? static and discovery

Gunnar: I would agree with that and Rudi that we don't need to write that chapter in a first version of this spec

Ted: I can ask

Magnus: we could have this discovery described in the spec but also the simple static