Re: W3C Automotive WG Phone Meeting

Hi,

I'll attend the meeting.
Attached is an outline of security note.
I apologies for the delay in posting this.

Junichi

---------------


# Note outline ###

# Purpose

This note describes security mode that Automotive API relies on and
best practices for API access control. Implied reader of this note is
Implementer of Automotive API and Developer who utilizes the API.

We assume the implementer is an automaker,
the developers are usually ones trusted by the automaker
and end-user is a driver.

# Security model

User agent where Automotive API is implemented on is assumed to be
placed on a infotainment system of a car. The system has connections
to CAN and the internet. Apps are downloaded from the internet and
access car information via the client API.

[CAN] - [Infotainment system] - [Internet]

This infotainment system consists of three parts: base OS, user-agent 
and apps.

## User agent
User agent would be implemented in two ways:

* Web-view
Each app is displayed on its own web-view. App life cycle (install, 
update, uninstall) is
managed by the base OS.

* Platform
User agent executes multi apps simultaneously. App life cycle is managed 
by user agent.
Drafted spec, such as Service Worker, should be took into account.

WG thinks web-view type is preferable for Automotive API version 1 but 
platform type is kept as an alternative.

## App distribution

App is distributed in two way as well:

* Package
(Almost) all resource is packaged in a zip, signed by its developer and
  distributed from a specific software market.

* Site
As classical web, app is distributed as a web content from anywhere.

WG think Site style is preferable because it's more open and developer 
easily join the community.

# Access control

Thorough discussion, WG reached a consensus that API access control is 
required for security and privacy reason.
Implementer should provide a way by which automaker controls API-use of 
App or App developer.
Here are candidates.

* Market
If automaker performs as a market, it can check apps before distributing.
In order the app not to be modified after distributed, Package-style 
should be selected.

Security model: Web-view & Package
Pros: There exists reference such as Google play or App Store.
Cons: Might be close and small community.

* Token
Beafor each api-call, check user-token and developer(organization)-token 
that are provided as
http response header from app server. Device-token and vehicle-token can 
be also took into consideration.

Pros: flexible control can be realized by user-agent
Cons: should be described in the spec?

* Local proxy filter
Let all internet access pass a local proxy server that sanitize scripts.

Security model: any combination (pros)
Cons: Filter design might be difficult.

* Automaker certificate
User agent allows api-use only for cite authorized by automakers root 
certificate.

Security model: Site
Pros: Comparatively easy to develop
Cons: Not a way to check apps but developers

# Additional consideration

Implementor should also consider following points.

* Set-api

WG think set-api is experimental and recommend to make it disabled for 
Version 1.
We don't have enough knowledge what happens by this at this moment.

* XXXXX
XXXXXXXXXXXXXXX



On 16/01/6 06:45 , Paul Boyes wrote:
> Here is contact info for tonight
>
>
>
> *W3C Automotive WG Phone Meeting*
>
> Scheduled: Jan 5, 2016, 5:00 PM to 6:00 PM
>
> 1.Please join my meeting.
>
> https://global.gotomeeting.com/join/524004349
>
>
> 2.Use your microphone and speakers (VoIP) - a headset is recommended.
> Or, call in using your telephone.
>
>
> Dial +1 (571) 317-3131
>
> Access Code: 524-004-349
>
> Audio PIN: Shown after joining the meeting
>
>
> Meeting ID: 524-004-349
>
>
>
> Paul J. Boyes
> --------------------------------
> Mobile:   206-276-9675
> Skype:  pauljboyes
>
>
>
>

Received on Tuesday, 5 January 2016 23:18:25 UTC