W3C home > Mailing lists > Public > public-automotive@w3.org > June 2016

Re: Draft Specification for Service Based Approach Using WebSockets

From: Gavigan, Kevin <kgavigan@jaguarlandrover.com>
Date: Fri, 10 Jun 2016 15:26:46 +0100
Message-ID: <CAKaHsmeKyKaC_DCjaFnWD9JqTRLhDKVEuLQwj=5+7HEX7q-VLg@mail.gmail.com>
To: Song Li <ls@newskysecurity.com>
Cc: Junichi Hashimoto <xju-hashimoto@kddi.com>, Paul Boyes <Paul.Boyes@inrix.com>, Peter Winzell <Peter.Winzell@melcogot.com>, "Crofts, Adam" <acrofts1@jaguarlandrover.com>, public-automotive <public-automotive@w3.org>, Peter Virk <pvirk1@jaguarlandrover.com>, Lovene Bhatia <lbhatia@jaguarlandrover.com>
Hi Song,

Thanks very much once again, your input was very helpful.

Regards and best wishes

Kevin

*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 10 June 2016 at 15:00, Song Li <ls@newskysecurity.com> wrote:

> Hi Kevin,
>
> Thank you so much for the nice write up, yes this covers the essential
> elements of my suggestion. As you mentioned, the success of the
> communication being secure depends on proper implementation of the client /
> server, i.e. client should always check the cert and if not trusted, client
> should refuse further communication with server. On the SOTA side,
> manufactures may choose to push and invalidate a cert any time as response
> to a security incidence, i.e. cert breach.
>
> Thanks again.
>
> Regards
>
> Song Li
>
> Co-founder and CTO
> NewSky Security <https://newskysecurity.com>
>
> On Fri, Jun 10, 2016 at 4:24 AM, Gavigan, Kevin <
> kgavigan@jaguarlandrover.com> wrote:
>
>> Hi Song,
>>
>> Thanks once again for your helpful response and I completely agree that
>> issues like software over the air (SOTA) renewal of certificates is a big
>> topic, more than a single email could cover.
>>
>> *>>  To solve this the client will need to have the infotain's cert
>> pre-installed and trusted.*
>>
>> Just to check I understand the part we have discussed so far, is the
>> proposal:
>>
>> i) the W3C specification would define that a client on the vehicle
>> connects to a server on the same vehicle using e.g. infotain:4343
>>
>> ii) On the vehicle, the etc\hosts file would be configured to map
>> infotain to 127.0.0.1
>>
>> iii) Each manufacturer that is implementing a server would create their
>> own self-signed-certificate with a common name (CN) of 'infotain' and
>> import details for the self-signed-cert into the cert store used by clients
>> on that vehicle e.g. the OpenSSL ca-bundle.crt file.
>>
>> iv) Client could then try to connect to infotain:4343 which would resolve
>> to the App Server running on the vehicle on 127.0.0.1 port 4343 and client
>> could verify the servers self signed cert; they then perform the TLS
>> handshake to create an SSL tunnel.
>>
>> v) Client and server have a HTTPS connection (so RESTful web service
>> could use this) or client can request that server moves to WebSocket
>> protocol (over wss).
>>
>> So in this scheme, all communication between client and server (which
>> could include details of user tokens), is encrypted  (which is good of
>> course as it prevents details being logged accidentally by a poor
>> implementation or sniffed using e.g. Wireshark)  but if an attacker had
>> root access on the vehicle, they could still circumvent the security and
>> install a MITM, but if they have root access the game is pretty much up
>> anyway?
>>
>> I would be very grateful if you could confirm whether this is what you
>> were suggesting
>>
>> Thanks and best wishes,
>>
>> Kevin
>>
>>
>> *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 9 June 2016 at 20:05, Song Li <ls@newskysecurity.com> wrote:
>>
>>> Hi Kevin,
>>>
>>> MitM attack is one my favorite topics. Yes, deciding which cert. to
>>> trust is critical. To solve this the client will need to have the
>>> infotain's cert pre-installed and trusted. This is not more vulnerable than
>>> the regular case where client talks to a CA to verify the cert, and
>>> provides more flexibility for manufactures. There are more details on the
>>> attack and defense scenarios, and how to update the cert upon expiration /
>>> breach, which I don't think a single email can cover.
>>>
>>> Regards
>>>
>>> Song Li
>>>
>>> Co-founder and CTO
>>> NewSky Security <https://newskysecurity.com>
>>>
>>>
>>> On Thu, Jun 9, 2016 at 2:16 AM, Gavigan, Kevin <
>>> kgavigan@jaguarlandrover.com> wrote:
>>>
>>>> Hi Song,
>>>>
>>>> Thanks very much for the very helpful details.
>>>>
>>>> For a server with domain 'infotain', do you have any suggestions/advice
>>>> on how to establish a WebSocket wss (TLS secure channel) between the on
>>>> vehicle client and server?
>>>>
>>>> I'm thinking particularly about how to prevent a Man in the Middle
>>>> attack between client and server and ensuring that the client is certain it
>>>> is communicating with the infotain server on the vehicle. Would this be
>>>> based on the server having an X.509 certificate for 'infotain'? If so would
>>>> manufacturers share an 'infotain' certificate issued by a Certificate
>>>> Authority (or have I misunderstood - always a possibility :-) ??
>>>>
>>>> Thanks and regards,
>>>>
>>>> Kevin
>>>>
>>>> *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 8 June 2016 at 19:02, Song Li <ls@newskysecurity.com> wrote:
>>>>
>>>>> Hi Kevin,
>>>>>
>>>>> Absolutely, I love to elaborate on this. I think it is a good idea to
>>>>> use a well-known name for the server, so that all manufactures can use the
>>>>> same name. While "localhost" is a well-known name, it is bound to the same
>>>>> server (127.0.0.1), I think we can use a different name, say "infotain", so
>>>>> that we have the flexibility of using a different ip in the future.
>>>>>
>>>>> For implementation details, lets assume manufactures are building
>>>>> their servers / clients based on some existing OS, i.e. *nix or windows.
>>>>> All those systems support hosts file as their first line of domain name
>>>>> service. In hosts file, we can map "infotain" to 127.0.0.1, same as
>>>>> localhost, this is consistent with today's draft spec. If, in the future,
>>>>> for some reason, a manufacture choose to move the server to a different
>>>>> machine than the client, a push update of hosts file will let the client
>>>>> talk to the new server, no code update required. The client still talks to
>>>>> "infotain:4343" but under the hood it is a different machine.
>>>>>
>>>>> In our spec we do not need to bind the server to a particular ip
>>>>> address, I believe this is something up to the manufacture to decide. It is
>>>>> most likely be some
>>>>>
>>>>> This setup will benefit development work as well. In most cases server
>>>>> and client will have different development / release schedules. Say the
>>>>> server team has a release candidate ServRC1 and deployed for testing, for
>>>>> integration tests the client team can simply modify their hosts file so
>>>>> that their code talks to ServRC1 instance. They don't have to install both
>>>>> client and server on the same machine for the testing.
>>>>>
>>>>> Now back to Junichi's security concerns. Today when infotain is
>>>>> actually localhost, we do not have the protection that we have when server
>>>>> and client live on different machines. We need to make sure client cannot
>>>>> access the sensitive resources of server. This requires client needs to run
>>>>> from a user that's not root, and server's sensitive information such as
>>>>> cert, credentials, cookies, etc are saved in places where client cannot
>>>>> access.
>>>>>
>>>>> If in the future client and server are running on different machines,
>>>>> it is a standard internet security scenario, where we restrict access to
>>>>> server machine's resources by restricting ports, client ip, etc.
>>>>>
>>>>> Again feedback welcome.
>>>>>
>>>>> Regards
>>>>>
>>>>> Song Li
>>>>>
>>>>> Co-founder and CTO
>>>>> NewSky Security <https://newskysecurity.com>
>>>>>
>>>>> On Wed, Jun 8, 2016 at 1:14 AM, Gavigan, Kevin <
>>>>> kgavigan@jaguarlandrover.com> wrote:
>>>>>
>>>>>> Hi Song Li
>>>>>>
>>>>>> Thank you to you and Junichi for excellent and very helpful feedback
>>>>>>
>>>>>> I would be very grateful if you could expand on the points you made
>>>>>> in your proposal - I have added a question in blue below.
>>>>>>
>>>>>>
>>>>>>    1. Name the server machine differently from "localhost". -
>>>>>>    Flexibility in long term evolution, can resolve the name to same machine or
>>>>>>    different machine
>>>>>>
>>>>>> localhost is being used to enable clients running on the vehicle to
>>>>>> connect to a server that is also running on the vehicle. This server (which
>>>>>> may be implemented using e.g. node.js is acting as a gateway on that
>>>>>> vehicle to vehicle signals. There may be other offboard clients, but they
>>>>>> also have to obtain the IP address of the vehicle when it is connected to
>>>>>> the internet, in addition to being able to address the server running on
>>>>>> the vehicle.
>>>>>>
>>>>>> Instead of using localhost, are you proposing that each server
>>>>>> implementer (vehicle manufacturer) should use a different domain name or ip
>>>>>> address for the 'server' on the vehicles they manufacture (and this is made
>>>>>> known to the client via documentation or a discovery mechanism) or is there
>>>>>> a better mechanism?
>>>>>>
>>>>>> I would be very grateful if you could you please expand on how the
>>>>>> alternative to using localhost would work?
>>>>>>
>>>>>> Thanks and regards,
>>>>>>
>>>>>> Kevin
>>>>>>
>>>>>> *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 8 June 2016 at 02:41, Song Li <ls@newskysecurity.com> wrote:
>>>>>>
>>>>>>> Hi Junichi,
>>>>>>>
>>>>>>> Thanks for pointing this out - yes, when the client is running on
>>>>>>> the same machine as the server, it is a much higher risk if the client is
>>>>>>> controlled by attackers, as you pointed out in your email, the attacker
>>>>>>> will have access to the server's certificate, and other sensitive
>>>>>>> information, from the file system.
>>>>>>>
>>>>>>> From security's perspective, and putting long-term system evolution
>>>>>>> into consideration, I think the problem is "localhost". I am wondering if
>>>>>>> the assumption that client and server are running on the same machine will
>>>>>>> always be true. It may be the case today, a client is running on the same
>>>>>>> computer as the server, but it may not be true in the future, and if it
>>>>>>> does happen that client runs on a separate machine than the server, our
>>>>>>> code should be able to call server. By binding the server to localhost,
>>>>>>> this will not be possible.
>>>>>>>
>>>>>>> May I propose to give the server a different name? The server's name
>>>>>>> can be resolved to the same machine as the client, as it is today, it can
>>>>>>> also be resolved to a different machine in the future. On the security
>>>>>>> side, the machine running the client should not name the path where the
>>>>>>> server stores its sensitive information, i.e. certs, tokens, DB, etc. This
>>>>>>> can be achieved with technologies such as virtual machine, or virtual path,
>>>>>>> etc. A different name for the server will help this separation. As long as
>>>>>>> the client, which is considered vulnerable and can be compromised, cannot
>>>>>>> name the sensitive resources, i.e. cannot specify the resource's path, it
>>>>>>> is considered safe from the client code and attacker.
>>>>>>>
>>>>>>> To summarize my proposal, we can:
>>>>>>>
>>>>>>>    1. Name the server machine differently from "localhost". -
>>>>>>>    Flexibility in long term evolution, can resolve the name to same machine or
>>>>>>>    different machine
>>>>>>>    2. Prevent client code from naming sensitive resources of
>>>>>>>    server. If client cannot name it, it cannot access it.
>>>>>>>       1. Multiple technologies can be used to achieve the naming
>>>>>>>       prevention, details to be discussed during implementation.
>>>>>>>
>>>>>>> Feedback welcome.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Song Li
>>>>>>>
>>>>>>> Co-founder and CTO
>>>>>>> NewSky Security <https://newskysecurity.com>
>>>>>>>
>>>>>>> On Tue, Jun 7, 2016 at 5:53 PM, Junichi Hashimoto <
>>>>>>> xju-hashimoto@kddi.com> wrote:
>>>>>>>
>>>>>>>> Hi Song,
>>>>>>>>
>>>>>>>> I think certificate type is a different topic but if your example
>>>>>>>> solves my concern, please share the idea.
>>>>>>>>
>>>>>>>> In the draft[1], we see the following sample code:
>>>>>>>>   var vehicle  = new WebSocket(“wss://localhost:4343”);
>>>>>>>>
>>>>>>>> To implement this, the local server has to keep a certificate which
>>>>>>>> common name is 'localhost' and also keep the corresponding private key.
>>>>>>>>
>>>>>>>> Because this key is a part of the local server 'app', it is very
>>>>>>>> hard to prevent attackers retrieving this key. This cause issues. e.g.,
>>>>>>>>
>>>>>>>> - Falsification of data
>>>>>>>> - Man-in-the-middle between apps and the local server
>>>>>>>>
>>>>>>>> Additionally, the certificate and the key are valid on anywhere,
>>>>>>>> anydevice. I don't think major providers allow such use.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Junichi
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2016/06/08 8:57, Song Li wrote:
>>>>>>>>
>>>>>>>>> Allow me to jump in for these questions.
>>>>>>>>>
>>>>>>>>> There are two types of ssl certificates: wild card and
>>>>>>>>> multi-domain. If
>>>>>>>>> example.com <http://example.com> is going to have a wild card
>>>>>>>>> certificate, it will cover all example.com <http://example.com>
>>>>>>>>> subdomains, such as www.example.com <http://www.example.com>
>>>>>>>>> api.example.com <http://api.example.com>, etc. If admin of
>>>>>>>>> example.com
>>>>>>>>> <http://example.com> choose to use multi-domain certificates, the
>>>>>>>>> certificates will cover a limited number of domains of example.com
>>>>>>>>> <http://example.com>. Multiple domains can share the same
>>>>>>>>> certificate in
>>>>>>>>> both cases, they do not have to have different certificates, but
>>>>>>>>> they can.
>>>>>>>>>
>>>>>>>>> Certificates are deployed to servers and they should not be shared
>>>>>>>>> with
>>>>>>>>> people who are not admins of the domains. Certificates are
>>>>>>>>> deployed on
>>>>>>>>> the servers hosting the domain(s), and only public key portion of
>>>>>>>>> the
>>>>>>>>> certificates will be sent over the wire. Things get more
>>>>>>>>> complicated if
>>>>>>>>> CDN is used to speed up content distribution, but can be solved
>>>>>>>>> using
>>>>>>>>> multi-domain certificates. Clients, such as browsers / java code,
>>>>>>>>> verifies the certificates before communicating with server for
>>>>>>>>> secured
>>>>>>>>> content.
>>>>>>>>>
>>>>>>>>> Let me know if you need examples / implementation details. Our
>>>>>>>>> company's
>>>>>>>>> using a wild card certificated for our
>>>>>>>>> https://www.newskysecurity.com
>>>>>>>>> domains.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> Song Li
>>>>>>>>>
>>>>>>>>> Co-founder and CTO
>>>>>>>>> NewSky Security <https://newskysecurity.com>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 7, 2016 at 4:23 PM, Junichi Hashimoto
>>>>>>>>> <xju-hashimoto@kddi.com <mailto:xju-hashimoto@kddi.com>> wrote:
>>>>>>>>>
>>>>>>>>>     Hi Kevin,
>>>>>>>>>
>>>>>>>>>     Implementers would like to know how to manage the certificates
>>>>>>>>> for
>>>>>>>>>     https/wss connection in the server. For example, they would
>>>>>>>>> like to
>>>>>>>>>     know whether each server should have different certificates or
>>>>>>>>> not,
>>>>>>>>>     how the certificates should be kept securely, etc.
>>>>>>>>>
>>>>>>>>>     Junichi
>>>>>>>>>
>>>>>>>>>     On 2016/06/08 0:36, Gavigan, Kevin wrote:
>>>>>>>>>
>>>>>>>>>         Hi,
>>>>>>>>>
>>>>>>>>>         I've updated the Security section to include some general
>>>>>>>>> points
>>>>>>>>>         that
>>>>>>>>>         apply to both WebSockets and RESTful web services:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations
>>>>>>>>>
>>>>>>>>>         Kind regards,
>>>>>>>>>
>>>>>>>>>         Kevin
>>>>>>>>>
>>>>>>>>>         /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
>>>>>>>>>         <mailto:kgavigan@jaguarlandrover.com>
>>>>>>>>>         <mailto:kgavigan@jaguarlandrover.com
>>>>>>>>>         <mailto:kgavigan@jaguarlandrover.com>>
>>>>>>>>>
>>>>>>>>>         /Office address:/
>>>>>>>>>         GO03/057 • Building 523, Gaydon • Maildrop: (G03)/
>>>>>>>>>         /Jaguar Land Rover • Banbury Road • Gaydon • Warwick •
>>>>>>>>> CV35 0RR
>>>>>>>>>
>>>>>>>>>         On 7 June 2016 at 14:18, Paul Boyes <Paul.Boyes@inrix.com
>>>>>>>>>         <mailto:Paul.Boyes@inrix.com>
>>>>>>>>>         <mailto:Paul.Boyes@inrix.com <mailto:Paul.Boyes@inrix.com>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>             Excellent indeed.  I will look at this in detail later
>>>>>>>>> today.
>>>>>>>>>
>>>>>>>>>             *Paul J. Boyes* | INRIX | Director of Telematics and
>>>>>>>>> Standards -
>>>>>>>>>             OpenCar  |  206-276-9675 <tel:206-276-9675> |
>>>>>>>>>         paul.boyes@inrix.com <mailto:paul.boyes@inrix.com>
>>>>>>>>>             <mailto:bryan@inrix.com <mailto:bryan@inrix.com>> |
>>>>>>>>>         www.inrix.com <http://www.inrix.com>
>>>>>>>>>
>>>>>>>>>         <
>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.inrix.com_&d=BQMFAg&c=QbuapHRvbn0JdC8vTVkPHg&r=PRAN7lum5Ra662QLho8LU3bhFjBvLXn3bBkFbW0Amjo&m=V5l0WXfOEJwhcE0JsN06mQ5SQhpXL-DuAuK3YcnTZoc&s=OqQVi_DcS5rv8or8hZdFvY0re6YF0Wl-_8okxrxOF0w&e=
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>                 On Jun 7, 2016, at 3:56 AM, Peter Winzell
>>>>>>>>>                 <Peter.Winzell@melcogot.com
>>>>>>>>>             <mailto:Peter.Winzell@melcogot.com>
>>>>>>>>>             <mailto:Peter.Winzell@melcogot.com
>>>>>>>>>
>>>>>>>>>             <mailto:Peter.Winzell@melcogot.com>>>
>>>>>>>>>                 wrote:
>>>>>>>>>
>>>>>>>>>                 Excellent !____
>>>>>>>>>                 I have just browsed through – Thank you for your
>>>>>>>>> hard
>>>>>>>>>             work!!____
>>>>>>>>>                 /pw____
>>>>>>>>>                 __ __
>>>>>>>>>                 *From:* Crofts, Adam
>>>>>>>>>             [mailto:acrofts1@jaguarlandrover.com
>>>>>>>>>             <mailto:acrofts1@jaguarlandrover.com>]
>>>>>>>>>                 *Sent:* Monday, June 6, 2016 12:58 PM
>>>>>>>>>                 *To:* public-automotive
>>>>>>>>>                 *Cc:* Kevin Gavigan; Peter Virk; Lovene Bhatia
>>>>>>>>>                 *Subject:* Draft Specification for Service Based
>>>>>>>>>             Approach Using
>>>>>>>>>                 WebSockets____
>>>>>>>>>                 __ __
>>>>>>>>>                 Hi All, ____
>>>>>>>>>                 __ __
>>>>>>>>>                 Kevin and I have drafted a specification for the
>>>>>>>>> service
>>>>>>>>>             based
>>>>>>>>>                 approach using WebSockets, as discussed in Issue 81
>>>>>>>>>                 <https://github.com/w3c/automotive/issues/81>.
>>>>>>>>> The draft
>>>>>>>>>             can be
>>>>>>>>>                 found in the working group wiki here
>>>>>>>>>
>>>>>>>>>             <
>>>>>>>>> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#WebSocket_2
>>>>>>>>> >.____
>>>>>>>>>                 __ __
>>>>>>>>>                 The specification builds upon the approach raised
>>>>>>>>> by Powell
>>>>>>>>>                 Kinney, using a single WebSocket to send JSON data
>>>>>>>>>             structures to
>>>>>>>>>                 the server. The JSON structure specifies the
>>>>>>>>> desired vehicle
>>>>>>>>>                 signal specification (VSS) path, an action
>>>>>>>>> parameter to
>>>>>>>>>             specify
>>>>>>>>>                 get, set, subscribe or unsubscribe as well as a
>>>>>>>>> number
>>>>>>>>>             of optional
>>>>>>>>>                 parameters.____
>>>>>>>>>                 __ __
>>>>>>>>>                 This specification allows:____
>>>>>>>>>
>>>>>>>>>                   * Use of the VSS, including wildcards and
>>>>>>>>> indexing____
>>>>>>>>>                   * GET/SET over WebSocket____
>>>>>>>>>                   * SUBSCRIBE to receive change notifications,
>>>>>>>>> allowing
>>>>>>>>>             settable
>>>>>>>>>                     change thresholds and upper/lower bounds____
>>>>>>>>>                   * SUBSCRIBE to receive notifications at a given
>>>>>>>>> time
>>>>>>>>>             interval.____
>>>>>>>>>                   * UNSUBSCRIBE via a subscription handle____
>>>>>>>>>                   * UNSUBSCRIBE from all notifications____
>>>>>>>>>                   * Security tokens to be passed from the client
>>>>>>>>> to the
>>>>>>>>>             server,
>>>>>>>>>                     such as OAuth 2.0____
>>>>>>>>>
>>>>>>>>>                 We'll go through this on the call on Tuesday night
>>>>>>>>> and look
>>>>>>>>>                 forward to hearing your thoughts.____
>>>>>>>>>                 __ __
>>>>>>>>>                 Kind regards, ____
>>>>>>>>>                 __ __
>>>>>>>>>                 Adam____
>>>>>>>>>                 __ __
>>>>>>>>>                 -- ____
>>>>>>>>>                 *Adam C**rofts MEng (Hons) MIET*____
>>>>>>>>>                 Connected Infotainment____
>>>>>>>>>                 Vehicle Engineering____
>>>>>>>>>                 Tel: +44 (0) 1926 921607
>>>>>>>>>             <tel:%2B44%20%280%29%201926%20921607> | 87311607____
>>>>>>>>>                 Mob: +44 (0) 7790 094350
>>>>>>>>>             <tel:%2B44%20%280%29%207790%20094350>
>>>>>>>>>
>>>>>>>>>                 Desk: G03/054, Building 523, Gaydon____
>>>>>>>>>                 Mail Drop: G/26/3, Building 523, Gaydon____
>>>>>>>>>                 __ __
>>>>>>>>>                 ____
>>>>>>>>>                 __ __
>>>>>>>>>                 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     --
>>>>>>>>>     <>------------------------------------------------<>
>>>>>>>>>              au x HAKUTO  MOON CHALLENGE
>>>>>>>>>                http://au-hakuto.jp/
>>>>>>>>>        KDDI/au competing in the Google Lunar XPRIZE
>>>>>>>>>        Providing communication technology support for
>>>>>>>>>        the Japanese team - HAKUTO
>>>>>>>>>     <>------------------------------------------------<>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> <>------------------------------------------------<>
>>>>>>>>          au x HAKUTO  MOON CHALLENGE
>>>>>>>>            http://au-hakuto.jp/
>>>>>>>>    KDDI/au competing in the Google Lunar XPRIZE
>>>>>>>>    Providing communication technology support for
>>>>>>>>    the Japanese team - HAKUTO
>>>>>>>> <>------------------------------------------------<>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Friday, 10 June 2016 14:27:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 24 October 2017 18:52:50 UTC