<scribe> scribenick: ted
<scribe> scribe: Ted
PatrickL: I saw last week
discussion about API style for on and off board clients
... I personally wanted to hear opinions if the group thinks it
is a good goal for our solution to have in mind and how high we
should prioritize solution for off board client
... including the big data category
Ulf: I think both are quite important
PatrickL: are off-board clients running on mobile devices?
Ulf: I see that as one type of off-board client
PatrickL: ok for me. we have
clients that are interested in quick communication with the
vehicle and minimal latency and second category that are
alright with not realtime data in bursts
... especially the caching and bursting of data is something we
should give more thought
... as the connectivity is not normally that good
Ted: I have generally seen sending
data off the vehicle as being pushed instead of pulled
data
sampling and edge computing on vehicle side, send upstream and
retry until complete
Glenn: thinking of CCC and
mirrorlink for mixed fleets to smartphone, it is a developed
use case already
... the capacity with third party hardware device as used by
mixed fleets at present in OBD2 port
Ted: a device would not be necessary, you would run app directly on the head unit
PatrickL: would we want some of
the caching and other capabilities supported by the
protocol
... we can have our services addressable by backend in cloud,
off board
Magnus: I think the simpler
approach would be better at this time. we tend to get into
complex use cases and try to solve too much at once and mire
ourselves down
... I would rather we address the simpler, obvious first
Glenn: agree with Magnus
... the vehicle is property with an owner who will want access
to data on vehicle and not from oem in cloud
Ulf: I want to challenge the
thinking that the unreliable nature of the connectivity is
something we need to try to solve
... that can be handled outside of our spec
... taking VISS as an example, wouldn't that be possible to use
for on and off board? I would think it is
PatrickL: I think the subscribe
mechanism is not robust enough to handle dropped network
connections
... the API itself is fine
Ulf: can't it be used as a component in a larger framework that handles those issues?
PatrickL: I don't have an opinion
Ulf: if we do not need to solve
it, better to leave it out
... best to partition and restrict scope you are trying to
solve
Ted: vehicles will have times of
poor connectivity, having a server incessantly polling when the
vehicle is in a coverage dead zone or even shut off is
inefficient
...better is trying to have vehicle store and
send off
...yes you could have a caching proxy of sorts on the vehicle for
the service in the cloud to request historic information but would
have difficulty using standard http proxy with resource
information at different points in time
PatrickL: solution you describe would not need modification
* user identity
* user agent / client identity
* encrypted transfer
* signed data
* access control models
* ...
PatrickL: in German we have
safety and security as a combined word, here we are talking
more about security
... let's start with user identity
... this is separate and distinct from user agent
Ted: my understanding is JLR is
working on storing profiles in the cloud
... this is more
important as we move towards increased usage and less ownership
...would be good for various things we have been talking about,
consent capture, music preferences, payment methods
...this
could be an area to standardize if OEMs would be willing to
discuss the solutions they are working on
PatrickL: service will need
something to identity the user or should we be more specific
and define a user object?
... complete with fields. what is the group thinking for level
of detail?
... from a former colleague at Audi, I understand we are
already having problems defining a user identity
... it depended heavily on type of service being used. it can
mean different things, eg Facebook account and VW
customer
... identity I have to transfer to access certain elements
offered by a service might be different
... identity in some cases is then transfered to the vehicle,
representing the individual
... if we start describing container for the identity we limit
ourselves to handling that single purpose
Ted: previously we left this out of
scope. service authenticates an app based on token and can
restrict what information or actions it can perform based on token
as identity
...how it gets issued and whether it is specific
to an individual is not something we have dealt with
PatrickL: service identifies app or individual based on the token. that could be assigned to an anonymous driver and up to the infrastructure to make sense of that token
Glenn: your summary captured my
understanding of what Ted described
... I think it best not to have identity of the user on the
vehicle itself
PatrickL: by the way, the smartphone/car contrasting comparison reminds me of how I prefer to describe a car, comparing it more to a TV - different users with different preferences on content services
Ulf: identity can be managed by the underlying vehicle, verifying tokens. idenity itself can be left outside our initial scope
Benjamin: I agree we should not
try to include identity management by ourselves and not within
the vehicles
... we should create user identity - driver and owner for
instance. connected services might need to distinguish
... I am not aware of defining a standard way of distinguishing
the individual for OEM services
PatrickL: do we handle the user agent in the same manner?
Ted: we have found in practice
people do not set unique, identifying user agent strings
...we often see default (eg libwww, Python-foo or Java) from
underlying library
...arbitrary string and easy for a dev to get wrong so I do not
put much weight on it. also would complicate multiple different
protocols scenario
PatrickL: will that be true for what we describe as well or will it be a webapp using the protocol providing one?
Ted: a good practice would be unique per app but that would necessitate a registration
PatrickL: that can be
impersonated and misused
... token could handle it as well. we can leave it outside of
our scope
Ted: OK with having user and app
identity out of scope for now
if we come up with concise
suggests or find a suitable other standard to reference we could
in spec itself
...we also can produce guidelines and best
practices outside of a spec and publish
PatrickL: we are doing out of
band signaling to handle the two parties, is that something
group would be ok with as well?
... or would people prefer things in-band, within the protocol
itself?
... this relates to earlier discussed desireability of
supporting multiple protocols which could have limitations on
authentication methods they support
... we will want to be able to handle ID of client and see it
as necessary
[adjourned]