Glenn: we have contracted a UC Berkeley professor on privacy
... from him we learned GDPR is not completely settled and EU might roll back some pieces
... he will be working on a paper including access and consent
... we will have better information to share at TPAC
... under IoT proposed regulation there are aspects about enabling data access with privacy considerations in mind
... we will share this document with W3C

Policy language overview

Armin: I will share the slides after

[on webex]

<scribe[slides]

Armin: I am working on a policy language, calling mine LPL Layered Policy Language as part of my PhD thesis at Passau
... the core problem I have come across in GDPR is generalized and holistic than specialized on a given industry like automotive
... there are quite a few regulations in EU. there are three main things to be considered
... privacy policy, method description (required by GDPR) documenting all processes concerning personal data, then contracts with third parties for accessing that data
... this is working in EU from legal point of view. the problem is that everything here is just bureaucracy and paperwork
... if you ask a privacy protection to answer a question it often can take them considerable time to give a response as they need to research whether they can provide that information
... having a machine readable policy privacy can be given to a user through a UI and personalize the policy indicating what data and purposes they agree to
... the details should stored along with the data itself, this is called sticky policies
... then we all want to use the data. we have a process called policy based anonymization
... we check all the purposes, rights, policies provided by user and anonymizing algorithms
... question is what do they develop here? there are a number of policy languages in existance and have slightly different approaches
... the difference in my approach is legal focus but also provenance
... set of purposes include recipients and any parameters on how long it can be stored, etc
... purpose can be consent or legal basis, if you talk with lawyers they tell you the legal basis is the way to go
... it has to conform to GDPR. there are exceptions when there is no legal basis for processing and there you need informed consent and freely given, not forced
... that is one of the core things to be considered
... for each purpose we need to define the recipient
... it can be a company, department or single person
... it is possible to have very fine grained access control later on
... here we describe in detail what data is collected, that you actually link each element in the database to this policy
... retention indicates when the data needs to be deleted
... some would like that data to persist but others may wish it limited to specific purpose
... now I want to discuss layers and the unique feature of my policy language
... a privacy policy can have a different underlying policy. we can therefore trace the data
... as an example a user of a vehicle accepts a given privacy policy, data is transfered to OEM or other data service provider
... data provider does not provide that information to arbitrary third parties. they need to ensure original policy is kept and any derived comply with the original
... data shared with a third party will have enough of underlying policy conveyed along with allowed purpose to define their own policy

[demo slide with user who accepts policy that is stored with first data controller, could be on the vehicle itself and then a new policy would be applied before sending it to external server in cloud]

Armin: many see privacy only as access control, while an essential part it is not all encompassing
... I define very fine grained anonymization of data elements, defined for select purposes
... it is linked to a possible hierarchy of anonymous values, defines attributes (eg min and max anonymization levels) to allow data quality control for intended purposes
... we consider whole data set for anonymization
... what we do is define in a very generic way what policy is used and its attributes
... to allow this personalization, user needs some readability. most elements are given descriptions in multiple languages
... it can be consented or accepted for specific purposes
... we could consider the anonymization level to be personalized as well as the retention
... this brings up the question about how much the user can comprehend about the policy
... there are discussions elsewhere about how to communicate to user
... LPL would start from a legal policy, negotiation with the data subject (user), accept and give consent for specific purposes
... if this is done some data would be preprocessed and stored
... we developed a prototype with UI
... focus on giving overview of privacy policy
... these slides have been focused on vehicles but applicable to other use cases
... privacy based anonymization process has two sets of steps
... first authentication and authorization to ensure information is being used by the right person for the right purpose
... then the anonymization process itself which gets more detailed
... in the end we have a dataset that is usable for intended purpose and anonymized accordingly
... we analyzed this against articles 12 and 14 of GDPR
... it is compliant. there are several informative things that had to be added, for example the user needs to be informed who is the responsible data protection officer and their rights
... this is important from legal point of view
... I am not claiming LPL is the solution, there are other policy languages
... you might see some popular ones like P3P, Prime Life Policy language, P2U

[large chart comparing them in slides]

Armin: they are all purpose oriented and consider access control but enough on human readability
... what we are working on currently is the framework, access control and support structures
... we want to automatically fullfil access data rights. as described earlier it often manual and tedious right now
... we extend some of the privacy model concepts we are using. we want to apply this to some scenarios and have had very good results with privacy rights groups and their data sets
... IoT, automotive, health care are some potential areas

Benjamin: thank you for providing us a complete representation with concrete examples
... I have not worked with policy languages in the past. if I wanted to use it, how would I handle the serialization. are there good practices?

Armin: I have not used enough of the other languages out there to answer, mostly I was assessing them. I can tell you what you have to do in LPL
... first of all you would need to define the whole policy, clear representation of the data and all purposes to be covered
... then you would load into whatever system you are using. our framework is still in development
... there is an interface to collect consent. framework will be open

Benjamin: we discussed recently about possibly of reusing W3C ODRL for our purposes, not sure you looked at it

Armin: I don't know it to be honest

Ted: we have been talking to some people about ODRL since they are nearby at W3C, focusing somewhat on that policy language and OASIS' XACML
... unsure which will be most suitable and we won't have bias towards ODRL
...ODRL is generic, multi-purpose but used primarily by media industry. it can handle pre-conditions such as licensing which might be applicable
... we have some exercises suggested to evaluate it better

Armin: I would encourage you look at these from not only technical but legal point of view
... you will find similar concepts across them, there are differences of course
... you have to distinguish between data subjects and controllers

<Zakim> ted, you wanted to discuss UI workshop

Tim: I presume in your step 5 in transfer is metadata on the policy that travels with the data

Armin: correct, the term is 'sticky policy' and allows you to always enforce that the data is handled properly
... it is a key concept that needs to be applied
... as mentioned layering (3rd and 4th parties) is important and ensure what they are doing is correct
... it is interesting that you consider user could change consent within their policy
... you will need a protocol or interface for the controller to inform the parties the information is shared with of the updates and verify
... this is a huge challenge

All: thank you Armin, looking forward to seeing you in Lyon

[adjourned]