Re: Minutes Auto WG 2016-04-19

Hi Kevin,

Thank you for the reference.
I understand that your idea is based on a local http-server and I agree 
that OAuth is a promising candidate for access control in that case.

However current approach affects security significantly because it is 
not an app-runtime interface anymore but an app-server interface. For 
example, runtime cannot control permission for app-server APIs.

Even the service-based interface of [1] is still an app-runtime 
interface; Dave's example uses a dedicate API to open a socket instead 
of using generic WebSocket API.

[1] https://github.com/w3c/automotive/issues/81

I prefer to WebIDL interface personally. However if we continue a HTTP 
approach, how about to add a special method such as 
vehicle.XMLHttpRequest to access the local server so that runtime can 
control the API permission and developers do not have to know which 
hostname/port is used in a given device.

Regards,
Junichi

On 2016/04/22 12:56, Gavigan, Kevin wrote:
> 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.1 Host: api.linkedin.com
> <http://api.linkedin.com> Connection: Keep-Alive Authorization: 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 <mailto: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
> <mailto: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>
>         <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 20 April 2016 at 08:50, Junichi Hashimoto
>         <xju-hashimoto@kddi.com <mailto:xju-hashimoto@kddi.com>
>         <mailto: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
>     <>------------------------------------------------<>
>
>


-- 
<>------------------------------------------------<>
          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 Sunday, 24 April 2016 13:02:22 UTC