Re: Minutes Auto WG 2016-04-19

Hi Junichi,

*>> Do you think we need a special DOM API to pass tokens to runtime?*

If the Vehicle APIs are exposed over HTTP e.g. as a Web Service, then we do
not *have* to create a special DOM API to pass tokens at runtime, rather
the security token(s) can be passed in the HTTP header.

As an example, please see https://developer.linkedin.com/docs/oauth2

Step 4 of this article from Linked-In provides an example (reproduced below
for convenience) of how the Linked-In service will accept requests from a
user if the request contains a valid OAuth2 security token for that user in
the HTTP header.

Once you've obtained an Access Token, you can start making authenticated
API requests on behalf of the user. This is accomplished by including an
"Authorization" header in your HTTP call to LinkedIn's API.  Here is a
sample HTTP request including the header value that includes the token:
sample call

GET /v1/people/~ HTTP/1.1Host: api.linkedin.comConnection:
Keep-AliveAuthorization: Bearer
AQXdSP_W41_UPs5ioT_t8HESyODB4FqbkJ8LrV_5mff4gXZAAOYR

In a similar way, the Vehicle API could check that HTTP requests to get/set
or subscribe to sensitive data/notifications have valid security token(s)
attached to the request's HTTP header. If there is not a valid token
attached to the header then a suitable error code would be returned e.g. to
inform the requesting code that the token has expired and should be renewed.


*>> Re: Impact on specification*

If we continue with a HTTP approach, we could potentially add an
informational note to the specification stating that an implementer of the
specification could optionally support verifying the identity of the entity
(e.g. user or vehicle or device or organisation) making a HTTP request by
checking the validity of the OAuth2 token(s) in the request's HTTP header.

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

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

On 22 April 2016 at 07:01, Junichi Hashimoto <xju-hashimoto@kddi.com> wrote:

> Hi,
>
> I'm wondering how we integrate a token-based access control into the
> current spec. Do you think we need a special DOM API to pass tokens to
> runtime?
>
> Regards,
> Junichi
>
> On 2016/04/21 17:34, Gavigan, Kevin wrote:
>
>> Hi Junichi,
>>
>> The Candidate Logical Architecture is meant to show an example of how
>> the APIs could be exposed, rather than a detailed exposition of how to
>> implement an IVI system using the APIs.
>>
>> 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>
>>
>> /Office address:/
>> GO03/057 • Building 523, Gaydon • Maildrop: (G03)/
>> /Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR
>>
>> On 20 April 2016 at 08:50, Junichi Hashimoto <xju-hashimoto@kddi.com
>> <mailto:xju-hashimoto@kddi.com>> wrote:
>>
>>     Hi Kevin,
>>
>>     Thank you for sharing your logical architecture.
>>     If possible, could you also share a sequence diagram where a token
>>     is requested, generated, sent and consumed so that we can understand
>>     the security model more clearly.
>>
>>     Regards,
>>     Junichi
>>
>>
>>     On 2016/04/20 4:08, Ted Guild wrote:
>>
>>         Minutes for today's call are online
>>
>>         https://www.w3.org/2016/04/19-auto-minutes.html
>>
>>         Please send me any corrections
>>
>>
>>
>>
>>
>
> --
> <>------------------------------------------------<>
>          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
> <>------------------------------------------------<>
>
>