<Magnus> IoT Security WoT Plugfest - Kajimoto Permissions & User Consent - Sam Weiler HTTPS in Local Network - Tomoyuki Shimizu; 3DS, Web Auth and Payment Request
<Magnus> IoT Security
<Magnus> WoT Plugfest - Kajimoto
<Magnus> Permissions & User Consent - Sam Weiler
<Magnus> HTTPS in Local Network - Tomoyuki Shimizu;
<Magnus> 3DS, Web Auth and Payment Request
Ted was in Executive Summit and side meetings and missed the breakout sessions
Magnus: IoT security faces a
number of the same issues as us such as discovery and verifying
certificates of LAN devices
... for privacy they were focused more on UX from a browser
experience
... they were also discussing forgiveness vs permission with
respect to privacy
... user can disable what they disapprove of
... I spoke with Sam Weiler about the automotive use cases
<urata> IoTSec, Spacial Navigation, Https local, 3DSecurity
Magnus: HTTPS in local network,
they also look at service discovery and how to provide
verifiable certificates in LAN
... they defined 3 use cases with a public CA, private CA and
self signed certificates
... they are leaning towards a private CA
Patrick: can you elaborate on the mechanism?
<Guru> web auth, WoT plugfest, web extensions
<hyojin> Spatial navigation, Media and Entertainment IG
Magnus: they had an out of bound
challenge model (ACME) that could be applicable
... IoT security payed attention
Ted: If we rely on a private CA, off the vehicle we would be subject to intermittent connectivity issues when trying to launch an app. I would like to see public keys be part of app package manifests, more efficient and cannot be gamed but likely with other challenges.
Magnus: they also brought up
connectivity and maybe using caching
... when it comes to service discovery there is concern we had
as well about a malicious device trying to broadcast its
service and hijack
... here certs can help
... there was also discussion of using blockchain for self
signed certificates
... a tier 1 could sign the blockchain block and establish a
trust model
Ted: similarly an OEM could issue intermediate certificates and sign/assign certs for a vehicle's services
Magnus: we might be able to rely
on their solution
... 3DS was actually company proposed implementation for
possible standardization. they have a browser extension and an
API/library for embedded solutions
Gururaja: we also talked about webapps as a potential threat for accessing and attacking the system
<Guru> metadata of the web apps
Louay: for 2nd screen we are also interested in discovery and HTTPS on LAN
Ted: 2nd screen will also be of interest to automotive
Louay: we started in 2014 as a CG
as a presentation API and at the time it wasn't implemented
until recently into chromium, ff...
... you will be able to have your browser send an open request
to other devices that permit it
... there are protocols for discovery and communication that we
are considering
Hyojin: I attended the M&E breakout session also the next version of MSE and EME
https://www.w3.org/wiki/TPAC/2017#Session_Grid
All the breakout sessions have links to their minutes from the grid
Urata: mostly attended the same
as Magnus
... I also attended the spatial navigation and it seems to be
mainly targeting controller for tv screen
... and maybe not very relevant to auto however there may be
desire to use haptic device to modify behavior on the head
unit
... there is an algorithm to bring pointer to nearest potential
focus point
... they can also have it set to ignore eg Y axis and only look
for neared on X
<hyojin> Spatial Navigation: https://www.w3.org/2017/11/08-spatnav-minutes.html
Urata: the web content in
automotive should be simple enough that it might not be needed,
we need to ensure ease of use
... I also was in the HTTPS local that Magnus explained
... we do not want to have to modify the browser to add a
local, private CA
... using a public one would be better
<Magnus> https://tools.ietf.org/html/draft-ietf-acme-acme-07
<Magnus> https://tools.ietf.org/html/draft-sheffer-acme-star-02
Urata: advantage for public CA is
they are already in browsers list but are suited to public IP
addresses not local network
... Hashimoto-san is also part of the CG as are some other
people I know
... they could use some assistance in that group to bring
forward a proposed solution
Wonsuk: I participated in the WoT
plugfest and talking about hosting a future meeting in
Korea
... there are converging use cases between connected homes and
vehicles
... I have worked on a VISS server that is being used in WoT
demos
... I also attended the demos session for generic sensors and
verified credential handler
... the latter is of interest to payment request api
... there is a model where the wallet is stored on the cloud
and based on verification from the user that wallet can be
enabled
... that might be an interesting model for automotive
Ted: that is definitely applicable for shared vehicle use cases
Gururaja: do you have your smart home/connected vehicle use cases somewhere?
Wonsuk: I don't but there were some related demos yesterday
Guru: they used Amazon Echo for the voice controller
<PatrickLue_> https://github.com/w3c/automotive/wiki/Use-Cases-for-in-car-communication
[review of use cases]
Guru: re fines automatically being paid, I do not see acceptable of user
Urata: Ted covered usage based
insurance
... next is about diagnostics system breakdown and scheduling
an appointment for service
... information on type of repair needed can be communicated
along with calendar request
#3 dozing driving
Urata: JINS MEME glasses have
many sensors and is connected via BT to car
... it can detect head movement and eyes to recognize
fatigue
Ted: I have seen some prototypes with cameras installed in vehicle pointed at driver for the same purpose
#4 automated shopping
Urata: be able to place and pay for an order to have attended place it in vehicle's trunk
#5 parking places
Urata: to help find open and
reasonable parking based on user's preferences, vehicle size
etc
... information can be collected and shared back to a server in
the cloud for credits
Magnus: I could also imagine you could use such a service to rent out a space you own when you don't use it
#6 purchasing electricity
Hayato: you should be able to measure how much electricity someone is using and be able to bill them accordingly
(from a private residence or business)
#7 automatic map generation
Urata: this one is basically collecting data points to send back to mapping providers to improve their maps much like Google does
Ted: I can appreciate this since
there is a new road near me that is very convenient but hasn't
been updated yet by Google
... I hoped all the rerouting requests to their server would
have taught them by now
Hayato: Lidar data is rather huge
and would add network congestion and cost
... we hope our R&D center will be able to do
smaller/appropriate data sampling
Urata: LIDAR prices are becoming very reasonable, about $100 (e.g. although small powered one. https://www.spar3d.com/blogs/the-other-dimension/vol13no27-lidar-unit-your-kids-can-afford/ )
#8 nonsmoking cars
Hayato: for rental cars you might
want a sensor to know if smoking occured
... presently there are no such sensors but could be an
aftermarket addition
Ted: sensors like that could be aftermarket addition and VSS signals are designed to be extensible but the VISS/RSI service would need to be discoverable
Patrick: I could see a registry of sorts for adding components to the vehicle that can contribute data
#9 purchasing music
Urata: I might be in an Uber, like a song and request to purchase it
Ted: already doable with Shazam app but with RSI Media api that data could be made available to devices (eg phone directly)
#10 OTA for firmware
Hayato: some firmware might be updated while driving, other cannot
Ted: I think this is out of scope, Genivi and others have significant efforts on software (including ECU firmware) over-the-air updates. See uptane
Guru: this is part of the RVI work indeed
Magnus: I see it as out of scope as well
Urata: an OTA system may need state of vehicle information from us, know it is home and going to be stationary overnight to do update
Patrick: geoposition, time, etc are pertinent
Guru: usually part of HMI interfaces
Magnus: the UX piece might be our area
<ted__> Patrick: RSI is HTTP based, withing a service you have resources and always have elements
<ted__> [Patrick creating a tree model in an editor]
<ted__> Patrick: these can map directly to URIs
<ted__> ... everything should feel very familiar
<ted__> Magnus: is it possible to add parameters to the request?
<ted__> Patrick: every element has a structure
<ted__> ... element is described by a schema
[music example with element struct spelled out]
example /mediabrowser/tracks
{ name: "Jein"
artist: <uri to artist>
length: 123s
ratings: "good"
}
scribe:
Patrick: request to get this
particular song/artist is could be
/mediabrowser/tracks/?name=Jein
... that will provide all tracks by artist Jein
... PatrickB is not of the same opinion on this structure and
we are open to input
... people recognize this readily from daily usage
... error codes, usual HTTP error codes
https://www.w3.org/Submission/2016/01/
[showing HTTP methods and resulting behavior]
Patrick: what I wanted to point out to us. with HTTP you are use to receiving documents, here it is a resource or element
Joakim: is this for use by tablets in the vehicle or?
Patrick: we see it as the basic
means to provide services to clients within the vehicle
context
... we are using this same basic protocol for navigation,
media, signals etc
... you could have several services offering POI, yelp app on
your mobile device, contacts from phone, destinations chosen
through IVI ui
... you can give a URI for a POI resource to your nav system
for where you want to route to
Joakim: LG has that right?
Patrick: yes but this URI
approach is of benefit is a POI could be a person or other
vehicle in motion
... we want a generic interface so we can have different
providers over time
Magnus: service interface appears to be modular and can come and go
Patrick: correct, we have a
service registry model
... all the URIs can be requested via HTTP GET or subscribed
to
... that alerts you (via web sockets) when something
changes
... you can subscribe to a resource or an element
Magnus: is it up to the service provider to define their service type?
Patrick: you could have different
schemas for different services
... we have defined schemas for certain things like POI
eg rsi.service.poi/1.2.3
Patrick: that way you can know
what schema to expect
... the idea here is that it is similar to content-type
including version
... we have found our services are changing
Magnus: since you provide dynamic
service plugin, I was wondering the extensibility
... in 5 years some new revolutionary service and if you have
centralized schema registry then that would be an issue
Patrick: there is no schema
registry, client only needs to know the schema name and if it
is capable of handling it
... you can ?spec request a resource and get its schema back
which you could parse and handle dynamically in code
... service registry collects all services available on the
vehicle
... schema is defining type of the service
Urata: you use the same path mechanism for getting and subscribing to data
Patrick: yes, some things however are not subscribable
Paul: that for things that aren't changing?
Patrick: yes and some services may simply not offer/implement subscribe
Magnus: do you have a filter schema for POSTs as well?
Patrick: yes, some attributes
need to be set, some may be and others are immutable
... that is described in the schema as well
<ted___> [discussion of access control for service registry]
<ted__> Patrick: to be honest we do not have that much in the way of access control centrally but leaving that to the individual services
<ted__> ... it could be centralized with registry mechanism
<ted__> Guru: can you go back to your client/server image?
<ted__> ... we have VISS and data model already, can we plug that into RSI?
Patrick: what we are defining
here is the access means in RSI including learning what data is
available
... the underlying services providing that data could be
implemented
... I want in our charter that we are defining protocol and the
schema definitions
Ted: I agree with Guru that it might be possible to have VISS underneath as a service, some code will need to map the RSI requests in a manner it understands
[discussion of challenges of filters and subscriptions Melco had in VISS]
Urata: if you are interested in three different resources you have to do three different connections?
Patrick: no you will have one socket and you can add subscriptions to an existing connection
Urata: if you unsub from all subscriptions what happens to the socket?
Patrick: it stays open unless the client deliberately closes it
Guru: was there a comparison on service approach versus a browser API?
Ted screams nooooo
scribe: been there done that
Paul: we want to support more languages and can this way
https://github.com/w3c/automotive-bg/pulls
<wonsuk> http://w3c.github.io/automotive-bg/rsi/protocol/index.html
call for editors - some local lobbying
discussion of pending pull requests, mock server, desire to have in GDP
Magnus: I can see extending our VISS to also be able to handle RSI if we can agree on the data model
[data model negotiation]
Patrick: we can see a more
complex type like a struct with more depth and detail
... back to the doors example, we may be able to nest windows
under doors instead of a pointer
... sometimes a relation (by uri) is better than nesting
Paul: a place description is not a vehicle signal
Ted: Magnus Feuer (JLR) has some nice tools on producing alternate views eg JSON from VSS YAML, could do similar with spec on various signals
Joakim: for media annotations we took the other approach, we wanted to funnel into core attributes and make it easier for web developers
Patrick: for the submissions we have description schema file for every service
Ted: good, so you are already doing that
Patrick: yes Ted yes
Joakim: do you know what were the influencers from DLNA in creating yours?
Patrick: I am trying to remember where Patrick took that from, npm packages perhaps
Patrick: we are using Patrick's
mock server quite a bit to try things out rather quickly
... protocol definition worked on here, vehicle signals
continue over at Genivi, other schemas maybe here or
elsewhere
Magnus: it would depend but for some it might be better elsewhere based on area expertise
Paul: challenge is coordinating
with other groups. it is good if it already exists
... there is overhead in trying to coordinate with other
orgs
Joakim: if it is something already in use then adoption will be easier based on familiarity
Patrick: I want to hear what
people really like about the current VISS that should be
brought over
... filtering perhaps as there is more flexibility there
... we heard from Melco that part was complicated
Peter: we decided not align with
the specification because it was not as straight forward as we
hoped and subject to interpretation
... I am hesitant to discard it because it is powerful
Magnus: that shifts the complexity to the application developer then
Patrick: filtering server side is
good, instead of congesting the client with too much data
... complexity belongs on the server more than in the
client
... you want the developer to get the data needed and not need
to post process
Paul: what about cpu load on the server?
Magnus: we should not assume this
will only be used on vehicles
... I could see cloud side clients accessing this
information
Ted: they will want a filter for
limiting bandwidth consumption
... OEM are already building silos and they can use this and
combine with EXI (as some already are for proprietary XML)
Patrick: if you find something
too difficult to filter on, you can annotate the documentation.
* not available here
... I am fighting switching to the tree concept
internally
... it is less clean. for example trying to apply a filter on a
complex type
Ted: agree links feel right but [in some cases] it could expand and give results
Patrick: that is what i did in the door/window example
Urata: when I want to get everything about a door then I would have to make multiple requests, dereferencing window and other links
Patrick: you can set an expand level, a current feature. it cannot be guaranteed as the expandable component might not be able to
Ted: if you don't care about the window but only open or locked then it is like a filter, not expanding
Patrick: you also can say which fields you want explicitly
$fields parameter
Patrick: one of the rationale for the expand feature was to GET the state of the linked elements at the same point in time
Urata: in that case it would be a single HTTP request and the server handles the expansion?
Patrick: yes but only if it is reachable by that service
Ted: on discovery, our issue
#223, the registry helps simplify that. client apps will still
need to be told where to find the web server
... I'm unsure how the client app knows what services are
available
Patrick: client can query the registry
[discussion on aftermarket additions being able to register or new year models/different package levels being able to easily add new features]
Patrick: there are several
identities client apps, users and I would like to discuss how
to define them
... this is close/related to an access model
Urata: identity is not described in the main topic
Ted: I have a few different
people in mind for getting ideas on how to represent and
protect identities
... I also expect different answers from these different
people
... I would like to see ids encrypted and persistence
identified when created with a means to auth and unlock on use
- OTP, biometrics, pin (weak) plus paired device
... webauthn
Patrick: JWT might be a good
model
... they have TTL for rental use case you mentioned