Re: [Minutes] Auto WG 2016-09-06

Although it's bad practice, I am just top-posting here as what I want to
convey is related but not directly in response to particular elements of
the discussion.

As you know, JLR has been working on a universal services framework for
vehicle connectivity which is called Remote Vehicle Interaction (RVI) [1].
RVI is a GENIVI open-source project. RVI's three macro use cases are:

   - SOTA
   - Remote Control
   - Vehicle Data

RVI implements two-layer security [2]:

   - Transport Security using TLS
      - All communication between RVI nodes is secured using TLS
   - Certificate-based Authentication and Authorization
      - For any entity to invoke a service the entity must present a JSON
      Web Token (JWT) that contains the requesting entities device certificate
      for authentication and a list of services the entity is allowed to invoke
      for authorization. The entire token is signed by the root certificate of
      the issuing entity (typically the OEM).

The following diagram depicts how I envision a potential architecture of
interaction between the socket server and RVI.

[image: Inline image 1]

In this architecture security is not handled by the Socket Server but by an
underlying layer. I think that makes very much sense as it can be left to
the implementing OEM or their Tier1 on what security mechanism to use. The
Socket Server only needs to be able to receive on pass on a security token
which is treated as an opaque data item. For RVI that would be the RVI JWT.
Other implementations can use a different format.

I do not think that all OEM and Tier1 have to agree on the same security
mechanism. The OEM has to provide the security token anyway. Even if a web
application is developed universally to run on any IVI system that supports
the Socket Server, OEMs will want to authorize that application for their
vehicles. If an OEM does not want to use RVI but another system that
implements its own security schema that is perfectly fine and desirable.
And even if multiple OEMs use RVI that does by no means imply that they are
using the same JWT to authenticate/authorize web apps.

In my opinion the Socket Server does not need to provide the security
mechanism nor does the W3C specification need specify the security
mechanism. It only needs to specify how security tokes are provided but not
what they are and what they contain.

Best regards,
Rudi



[1] https://github.com/GENIVI/rvi_core
[2] https://github.com/GENIVI/rvi_core/blob/develop/doc/rvi_protocol.md

On Wed, Sep 7, 2016 at 11:23 AM, Ted Guild <ted@w3.org> wrote:

> Found the link I was looking for related to certs and CA in auto space:
>
> https://www.regulations.gov/document?D=NHTSA-2015-0060-0004
>
> Interesting and ambitious although a very different use case. They want
> to have tons of short (or one time) use certs that can be verifiable
> and disposable while retaining anonymity.
>
> On Tue, 2016-09-06 at 18:39 -0700, Song Li wrote:
> > > > I missed the security part of the discussion - I would suggest we
> > > > include certificate management in our security model. It should
> > > cover
> > > > (but not limited to):
> > > > How to create certificates
> > > > How to deploy certificates to in-vehicle servers
> > > > How developers authenticate the server via certificates
> > > > How to revoke and renew certificates
> > >
>
> --
> Ted Guild <ted@w3.org>
> W3C Systems Team
> http://www.w3.org
>
>


-- 
*Rudolf J Streif*
System Architect - Open Source Initiative
Open Source Technology Centre

*M:* +1.619.631.5383
*Email:*  rstreif@jaguarlandrover.com



UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon, Warwick, CV35 ORR
US: 1419 NW 14th Ave, Portland, OR 97209
jaguar.com | landrover.com
-------------------
Business Details:
Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070

This e-mail and any attachments contain confidential information for a
specific individual and purpose.  The information is private and privileged
and intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient, please e-mail us immediately.  We
apologise for any inconvenience caused but you are hereby notified that any
disclosure, copying or distribution or the taking of any action in reliance
on the information contained herein is strictly prohibited.

This e-mail does not constitute an order for goods or services unless
accompanied by an official purchase order.