Automotive Data task force

14 Jun 2018


Ted, Edward, Dominik, Benjamin, Tim, Magnus, Harjot, Glenn, Ulf, Adam, Ulrich



Consent Capture

Slides (PDF)

Dominik: Ulrich invited me to present the progress we are making on consent handling
... Caruso is essentially an implementation on Neutral Server for a provider to make information available to data consumer
... we have to take specific measures to ensure the lawful protection of personal information
... we currently analyze different options
... we want to build them into the platform for flexibility
... we did a small PoC to see how it works and want to make it public
... we want to form an open ecosystem
... for this concept we had some key requirements that needed to be addressed based on conversations with partners and OEMs
... trying to balance the perspectives
... data providers will not necessarily know who the data consumers are
... wanted to avoid consumers to have to make individual arrangements for consent
... desire to leverage existing security models and Oauth was discussed within Extended Vehicle realms
... there are advantages and disadvantages for the different approaches

[slide 3]

[diagram illustrating car, user, service provider and consumers]

Dominik: we expect the user already signed a contract giving consent on providing data to the OEM
... they will have an identity with the data provider
... all the consumers need to abide by privacy laws and ensure they have access rights
... this is mostly between service providers and consumers. it was not clear how to handle this
... of the different options discussed the model where consumer registers with a 3rd party (Neutral Server provider)
... lawyers advised us to have clear consent, abiding by GDPR. that is not the sole lawfulness necessary
... it can be done by means of "balancing of interest"
... it will lead you to an assessment of whether or not you can access and use the data
... the legalities have us deviating from ExtVe standard
... we believe following this convention is legally sound
... there is a risk for abuse
... we had a set of requirements we wanted to address with a solution [slide Requirements for Consent Handling]
... identities most not be totally open. we want the consumers to not have to interact with the OEMs
... the data providers should not trust a 3rd party unconditionally
... OEMs wanted to be sure they could expose data this way
... we strove to abide by ExtVe as much as possible
... our 3rd proposed solution is based on Oauth and what our PoC is based on
... I will focus on this solution but can speak to the others if people are interested
... the Neutral Server acts as client in this Oauth setting
... this is a higher level of granularity

[SA.II OAUTH - OEM Authorization slide]

Dominik: example app needs to examine certain data points retrieved through Neutral Server
... there can be a single Neutral Server provider for multiple OEMs

[diagram of consent handling]

Dominik: user registers app, provides initial consent
... request is sent for an auth link to NS, including intended purpose for wanting the data, specific items they want to process
... mapping produces a state id based on vin, purpose and data item
... NS will create auth link with auth provider using Oauth
... data items that need to be retrieved, stating purpose and scope
... there is a NS callback mechanism based on id provided to app
... normal Oauth flow starts. OEM auth server would require user login
... owner will be prompted again with elements and purpose
... registered client will be called back
... id is included in the link
... this will provide auth and request tokens
... all the parties have the relevant data, know and can verify consent was given and data is available
... we created PoC code based on this scenario

[Consent PoC slide with example parties]

Dominik: we tried to keep it simple
... leveraged what we could so we didn't have to implement all the pieces ourselves

[video demo]

Dominik: 1-2-3-Workshops example app requires email, vin and password to register
... app lists Caruso dataplace as an option, user selects and starts consent process
... here you see the fictional OEM to authenticate
... provides options for what information to send to the NS
... it is possible to revoke the consent at any time
... app will cease to work unless the process is repeated
... we created detailed documentation of how the process works. this is just an overview for now and you can read more later
... in the PoC we covered some topics on auth of user by OEM, of data consumers by NS
... there are limitations and gaps at present such as on security features and NS used
... focus was on consent handling, not full GDPR compliance
... we are currently in the process of reviewing this from technical and legal standpoints
... we have alternative solutions we did not discuss since we found solution #3 the most interesting
... for solution #2 there needs to be a trust relationship between OEM and NS. in solution #3 all parties can verify consent
... a central trusted entity would provide infrastructure to grant and revoke consent

Ulrich: thank you for presenting that
... I will be sending the slides and documentation mentioned

Ted: interest of time we should defer on questions to email as Ulrich suggested and perhaps reconvene next week at our regular time instead of in two weeks (general agreement) and will send out notice along with the minutes

Ulrich: without a technically sound solution there cannot be a market that is GDPR compliance
... we tried to break this PoC to proove it works. there are other infrastructures we looked at
... this shows auth server at the OEM based on current political environment but it could be handled by an independent entity
... our experience shows the technical solution was not as complicated as we feared
... this demonstrates it is feasible and more attainable

Glenn: thank you Dominik for the presentation and this constructive work
... it aligns with some work we have been furthering and will definitely go into detail to provide feedback

Dominik: any constructive feedback is very welcome

Ted: you didn't mention authentication mechanism[s] other than initial password and Oauth after. I will be meeting with FIDO who we collaborate with in W3C WebAuthN Working Group for stronger auth and will looping them in

Ulrich: one issue is ensuring individual is the owner

Harjot: we have a similar click through mechanism much of what you discussed and will follow up


Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/06/26 18:04:57 $