Re: Possible Security and Privacy Next Steps

Hi Ted,

That's great, thanks,

>> we should review the various use cases and attack vectors.

Completely agree and believe we should use these to develop a Threat Model
 (focussing on the API and its use), as the type of attacks and their
mitigations will inform what secure implementations of the spec would need
to address.

It wont be perfect, and in fact implementors will need to continually
review, revise and add to it as new threats and types of attack are
identified, but it will help us think about what the security model will
need to achieve in a more organised way.


*>> If Set/Get/Subscribe/Unsubscribe fails because of a security problem
what are the detailed error codes.*

Believe we need a high level view of how we are assuming security might be
implemented. For example, if there are authentication or authorisation
errors, will these be handled using HTTP 401 and 403 errors?

Then if this is the case, more specifically, believe we should define
common error codes that are returned to help ensure that this behaviour is
consistent across different implementations.

For example, believe we would need to define the following error codes for
a HTTP 401

user token invalid
vehicle token invalid
device token invalid (where device is e.g. a component or group of
components e.g. in a vehicle)

So would return a 401 if request should be retried after
user/vehicle/device has renewed its access token.

For cases where the information in the request will never succeed (unless
something else changes e.g. invalid VIN is passed, user does not have a
subscription and needs to pay for one before authorised request can succeed)

HTTP 403 Forbidden

user details invalid
vehicle details invalid
device details invalid

etc (need to add other cases)

Regards,

Kev

*Kevin Gavigan BSc, MSC, PhD, MCP, MCTS*
*Software Architect*
*Connected Infotainment*
*Electrical, Electronic and Software Engineering (EESE)*
Jaguar Land Rover


*Mobile: 07990 084866*
*Email:* kgavigan@jaguarlandrover.com

*Office address:*
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

On 27 October 2015 at 11:50, Ted Guild <ted@w3.org> wrote:

> I propose in addition to repeated iteration through the three steps
> (list use cases, review in detail identifying attacks vectors, derive
> requirements) as Junichi recommended we need to consider additional next
> steps.  Here are few that occur to me and for all we should survey other
> groups at W3C who may have approached similar problems so that we can
> leverage or learn from.
>
> Access Control Mechanism
>
> There will be inter-process security restrictions imposed by the
> operating system.  There is also a need to be able to do similar in the
> web runtime.  For both it is beneficial to have granular access control
> on our data spec.  This may be a separate document.  We discussed
> perhaps a tiered approach and it should allow for implementers to define
> their preferred different privileged tiers and attributes at that
> tier.
>
> Best Practices for Web Runtime in IVI
>
> Since the web runtime will have external interactions we should review
> the various use cases and attack vectors.  This is not directly related
> to our specifications but the environment app written against these
> specs will be operating in so most likely a Best Practices document.
> Mitigating these concerns are more likely going to be from enforcement
> systems in the operating system although some elements may be in the web
> runtime itself.  A sample possible mitigation technique could be for the
> OS to require all external web site/service interactions to go through a
> proxy server that manages certificates of sanctioned sites and does data
> sampling for integrity checks.
>
> Entity preferences profile
>
> For individual users, owners and applications to be able to define
> personal, payment, vehicle and other information.
>
> --
> Ted Guild <ted@w3.org>
> W3C Systems Team
> http://www.w3.org
>