Re: Local service location advice

Chatting with Yves a bit suggests some additional context would be
helpful.

The local network the service will be running on will have multiple
hosts and may permit other hosts to join, such as smartphones and
tablets that could have apps that talk to this service.

mdns is a possibility and a concern with broadcast/discovery is another
device might interject an early response to impersonate the service and
steal token credentials for the actual service. 

We will have to be using self signed certificates to encrypt the
communicate on the vehicle LAN. Static fixed clients (such as dashboard
and head unit) on the LAN could have the public cert already to avoid
sending tokens to an imposter.

Presently we are discussing a service for vehicle signals (data from
the car itself) but have ambitions and early drafts for other services
to run on the vehicle. There should not be more than one host
responding with a service for vehicle signals.

On Mon, 2017-09-11 at 16:20 -0400, Ted Guild wrote:
> On Mon, 2017-09-11 at 15:51 -0400, Ted Guild wrote:
> > TAG,
> > 
> > I am asking for your guidance on something that has been awkward
> > and
> > unresolved for some time.
> > 
> > For Automotive we are defining a service that will reside on a
> > vehicle's local network. This service is not meant to be addressed
> > publicly, ever, out of privacy and security considerations.
> > 
> > In the present spec draft we have a hard-coded hostname, wwwivi. It
> > will be used in wss:// and potentially later https:// URIs.
> > 
> > Appending .localhost or .localdomain will add some clarity. The
> > local
> > network should be able to handle resolution of any hostname.
> 
> I meant to give the GH issue link instead.
> 
> https://github.com/w3c/automotive/issues/223
> 
> > https://lists.w3.org/Archives/Team/team-auto/2017Sep/0011.html
> > 
> > I would suspect there may be similar concerns for Web of Things,
> > Second
> > Screen and other activities. They may be more suitable to network
> > discovery protocols due to adhoc nature of things and screen
> > services
> > becoming available on a network. We feel it would be preferable to
> > be
> > rigidly defined to prevent eg an impersonating service or
> > introducing
> > latency.
> > 
-- 
Ted Guild <ted@w3.org>
W3C Systems Team
http://www.w3.org