W3C

Automotive Data task force call

15 Nov 2018

Attendees

Present
Armin, Glenn, Benjamin, Ted, Harjot, Adam, Hira
Regrets
Chair
Benjamin, Glenn
Scribe
Ted

Contents


<scribe> Scribe: Ted

<scribe> scribenick: ted

Policy Language

Armin's slides

Ted: of the topics we are pursuing ontology, sampling methodology metadata, consent and policy language I want to focus on the latter. it really should be merged with consent

Armin: I looked critically on my work. the base structure which has a policy and set of purposes for set of data
... need some sort of identity/entity for data source and recipient
... in P3P they define only a limited set, not enough
... trying to match policies of different providers as data is exchanged is a challenge
... policy needs to be human readable. we need to provide some text and information to the user
... it needs to be machine readable as well for automated processing
... there is of course the sticky policy concept, the policy needs to be bound to the data
... layers of policies should be used. from my point of view that is necessary and a valid approach
... it should be implementation agnostic, representable in json, xml, semweb, other...
... usually based on the structure of the data itself
... user should be able to decide purpose, data elements etc in providing consent
... second step would be to show this in a user interface
... i have anonymization model factored in. at point of definition of privacy policy you need to know how the data will be used in the future
... which is contradictory to anonymization

[slide 3]

Armin: it is not all about the technical issues. you need to consider how the policy is to be used
... do you need something domain specific? eg medical sector has strong legal considerations
... surely some special considerations for automotive as well
... GDPR, HIPPA, unsure of privacy in Asia

Ted: what I like most about GDPR is that it follows EU citizens globally and as a consequence becoming a de facto standard in rest of the world. we know OEMs customize their product offerings regionally and may want or need to do so for data policies. we should see if any that work with us can relay questions internally
... we should see if our OEM colleagues can get answers for us on this question

[slide 4]

Armin: purpose of policy: inform users, data marketplace, enforcement of policies?

Ted: I hope to get support from an American OEM on a project for enforcing policy on-vehicle

Armin: we will need a user interface. there has been quite a bit of work on this already
... we need to inform them according to GDPR on the uses of the data
... we should not inform them on legalities but purposes of the processing
... especially those which are more unusual
... they would expect for instance for their addressed to be used for billing purposes
... research or marketing is not something they would necessarily expect
... there needs to be personalized opt in and opt capabilities
... does it mean the most private is what is provided, granular or grouped/categorized broadly?
... I am not aware of any standardization process on privacy icons for instance
... next point is how to capture consent. I presented my approach where I have only active/acknowledged purposes enabled
... for GDPR it needs to be explicit opt in
... there needs to be guideline for policy creation
... lawyer might not produce something understandable by lay person, that might be thankfully outside of our scope
... for LPL I presented our UL, icons, consent/dissent and working on a next version
... next set of topics I call user experience, how they perceive privacy
... we need to consider different user groups, children, typical, disabled etc
... process of giving consent to a policy would require tools. eg for P3P people created APPEL
... decision process needs to be fast
... there is research on tracing of agreed/consented policies. this has been done with browser plugin that remembers decisions chosen and applies them again
... last point is to ensure the privacy policy is conformant. i would like to see an icon in browser address bar like you see for strong ssl
... we need to give consideration on whether personal information is collected and therefore required to encrypt, signed. is data provider required to be evaluated and certified?
... how do we ensure polcies aren't tampered. is the policy validated, this is not something that P3P did for conflicts
... you need some sort of protocol to handle sharing of policies and data. how do we communicate these?
... how do you handle different versions of the policy? you should assume there will be iterations
... you need some mechanism that distributes rescind request to all related services
... you need proof you are doing things correctly for legal reasons
... I have heard of blockchain based proposal for that
... there are many policy languages out there, some special projects funded by the EU
... there is ongoing work and much of it is going toward semantic web. i am not sure that would be the final solution but it seems to be a current direction
... LPL is currently in its 4th iteration
... giving emphasis on GDPR considerations

Glenn: several weeks ago we had a presentation from Caruso that did a model mapping for privacy considerations for data on the vehicle
... does it directly relate to your approach?

Armin: I am not aware of the presentation

Ted: I will look for the minutes (**April 20, 2018 presentation by Caruso), my understanding and recollection is Caruso/Fraunhofer were hoping to keep it to broad strokes and not necessitate a policy language. prior to your getting involved we discussed the complexities enough that we felt using a policy language is warranted. you and Ulrich should talk, I will try to bring him back to these calls/

Glenn: we would like to have a prototype in NV for exchanging data
... would this be worth implementing there?

Ted: absolutely, probably too soon
... does the group agree we should explore LPL? lessons learned won't be wasted effort if we end up going a different direction

Glenn: no objection

Benjamin: I would prefer a good look at the state of the art before making such a decision
... on the other hand we do not have a competing so why not

Ted: maybe a next step would be to try to represent some scenarios with specific data elements in a policy language, especially if you have some examples to share

Armin: yes that might be a good next step
... I cannot provide an example policy as I am working on next user interface, earlier iteration is a bit outdated
... if we can collect data points desired that would help

Benjamin: perhaps we can take a look at draft version especially as we are not experts

Armin: agree, I will keep you in the loop and updated on the progress. All I can say is I don't have a good example at present

Ted: in absence of an example, perhaps people can for the next call come up with a written in plain english (or your own language) of a scenario. what data elements to be stored by whom and shared with which third parties and what actors may be required to give their consent

Glenn: I was just at a conference with someone from U of Colorado involved in this for heavy duty trucks. I will make an introduction

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/11/15 17:24:16 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]