<scribe> Scribe: Ted
<scribe> scribenick: ted
Sent scheduling survey to the list, will work on times after settle on days and start agenda wiki
Peter: there is a virtual GENIVI meeting in May
Gunnar: 12-14 May, afternoon/evening CET first two days, more Asia friendly the other two days
focus on second half of month, weeks of 18 and 25 May
Ted points to Best Practices wiki and task force call survey
Peter: I want us to try to focus
on how to move this topic forward, toward conclusions for
spec
... want to hear in particular from Gunnar, Isaac, Ulf in
particular
... what steps do we take next?
Ulf: I think we have some iterations and then can focus on decision for May meeting
Gunnar: not enough work being done on it, need to work through various aspects
Peter: meeting later in May will help as well
Gunnar: I want a clear flow
understanding on the tokens and various servers
... we need something for the authentication piece - how to do
identification
Peter: I agree with that
Gunnar: message sequence chart
Ulf: one example is the current implementation we have
Gunnar: this the proxy of user proposal?
Ulf: no, based on ViWi and later
discussions
... these tokens can be put into JWT decoder, it can serve as
input
MagnusG: we are pretty close to
Oauth2/OpenID like Isaac brought forward recently
... that can provide the sequence diagram
Gunnar: it makes sense to me
Isaac: we can try some of the
different possible flows to see what works best in this
situation
... one is probably pretty close to what Ulf has
Ulf: sounds good
Ted: been in communication with Armin on his LPL recently, XACML based now. I see policy and best practices as closely related
Isaac: part of sticky policies
interests, having privacy and other aspects attached to data
being sent to the cloud
... another discussion is how complex or simple the policies
can be
... not giving concern on where to store the policies,
assertions in them
Ted wonders about returning to oauth2 subtopic, see if Ulf has read through it yet
Ulf: in the Google developer
docs, they use their client/servers and can look at having
those interfaces in our Gen2 implementation
... their ADT equivalent gives back an email address and self
generates a token, ours gives token back
... that token to authorization server and it gives back
another which is used in final step where api is called (Gen2
in our case)
... main difference is the first step, rest quite similar. they
send back key pair to self generate token
... client then has control
Ted wonders about different flows Isaac mentioned for first step
Isaac: this way you can give
client long term capability to self sign as long as its key
pair lasts until expiry
... they are authenticating the clients
... oauth is delegating access
... in our case we will be authenticating applications
(as client)
Ted client app could store its key
Isaac: you can also have additional eg hardware tokens
2FA - or rather multi-factor
Isaac: app can have full access once granted, generated keys could be stored in device and no other instances
Ulf: what sort of protocols are used in sending the client the key pair?
Isaac: they have the oauth server generate a public key, gives it to client that uses it to generate another and send it back
Ulf: that is a pretty big requirement for implementations of Gen2
Isaac: it could be used for
authenticating devices being paired with the vehicle, may
require different flow
... re requirements, Android and iOS have similar models
Ted wonders about miniapps manifest spec https://github.com/w3c/miniapp/blob/gh-pages/specs/manifest/docs/explainer.md
Application ID is merely a string identifier, but could still be useful to identify a particular (application specific) flow for first interaction with oauth server generating the key pair, server can also call out of bounds to other authentication factors (hardware token, otp etc) as part of its flow at app registration/installation
Ulf: I also want to share
https://github.com/GENIVI/ccs-w3c-client
... data lake of GENIVI's CCS project
Gunnar: graphql example is up,
still missing the tooling
... there is a docker instance and once fired up you can play
with it in browser
https://github.com/GENIVI/vss-graphql
we now have a data policy for hosting graph data, lets see if we can get any legacy data as current rather limited
Glenn: we are looking at running Ulf's data lake and can move that to sandbox you provide
Ted inquires if Go devices still available if anyone wants, Glenn affirms
Glenn: we want to see other data sources from the OEMs
Ted encourages Peter to coordinate with Joakim as he thought he may have data to contribute
Peter: I'll get in touch with him
Ted to reach out to Daniel and Adnan (dropped earlier)