Insulating Privacy in User Operations

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Insulating Privacy in User Operations

Jayanga Kaushalya
Hi all,

To cater the requirements related to [1], we are planing to implement a set of utility classes to mange privacy of privacy concerned objects (Eg: User).  

All the objects that are with privacy concerned attributes will be wrapped inside a privacy insulator object. Duty of the privacy insulator is to prevent the misuse of privacy related attributes. It will hide the attributes that are related to object's privacy and provide a hash or id as a pseudonym to represent the attribute instead of the real value. Furthermore, classes can be marked as confidential as well. All confidential classes should provide the pseudonym to represent there privacy concerned attribute. So whenever using a confidential object, pseudonym will be used instead of the underlying real value. 

There will be separate ID manager to map the related ID with the underlying actual value. So wherever the actual value should be needed, (Eg: Display the users username in a UI) ID manager can retrieve it and used. But this should be used only in places where pseudonym can't be used.

Please provide your thoughts.  

[1] [Architecture] GDPR - Pseudonyms For Username

Jayanga Kaushalya
Senior Software Engineer
Mobile: +94777860160
WSO2 Inc. | http://wso2.com
lean.enterprise.middleware



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Insulating Privacy in User Operations

Awanthika Senarath-2
Hello Jayanga,

This looks interesting and timely, however, two questions. How do you plan to identify the "privacy concerned attributes" for a particular person? From your email, it appears as the identification of the "privacy concerned attributes" is straightforward or you are having a predefined list of attributes that you believe to be privacy concerned.

The other question is what are the "places where pseudonyms can't be used"? 

Regards
Awanthika Senarath
PhD Research Student
Australian Centre for Cyber Security
Australian Defence Force Academy
The University of New South Wales (UNSW Canberra)


On Thu, Jan 11, 2018 at 5:21 AM, Jayanga Kaushalya <[hidden email]> wrote:
Hi all,

To cater the requirements related to [1], we are planing to implement a set of utility classes to mange privacy of privacy concerned objects (Eg: User).  

All the objects that are with privacy concerned attributes will be wrapped inside a privacy insulator object. Duty of the privacy insulator is to prevent the misuse of privacy related attributes. It will hide the attributes that are related to object's privacy and provide a hash or id as a pseudonym to represent the attribute instead of the real value. Furthermore, classes can be marked as confidential as well. All confidential classes should provide the pseudonym to represent there privacy concerned attribute. So whenever using a confidential object, pseudonym will be used instead of the underlying real value. 

There will be separate ID manager to map the related ID with the underlying actual value. So wherever the actual value should be needed, (Eg: Display the users username in a UI) ID manager can retrieve it and used. But this should be used only in places where pseudonym can't be used.

Please provide your thoughts.  

[1] [Architecture] GDPR - Pseudonyms For Username

Jayanga Kaushalya
Senior Software Engineer
Mobile: <a href="tel:+94%2077%20786%200160" value="+94777860160" target="_blank">+94777860160
WSO2 Inc. | http://wso2.com
lean.enterprise.middleware



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev





_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Insulating Privacy in User Operations

tharindue
Hi Jayanga,

Currently for identity claims, the claim URIs start with http://wso2.org/claims/identity/XXXXX which is used to identify the identity related claims separately. How about we follow similar approach here for isolating the sensitive attributes? This way we can define new claims as well easily which should belong to the same group of sensitive attributes.

Thanks,
TharinduE

On Thu, Jan 11, 2018 at 3:34 PM, Awanthika Senarath <[hidden email]> wrote:
Hello Jayanga,

This looks interesting and timely, however, two questions. How do you plan to identify the "privacy concerned attributes" for a particular person? From your email, it appears as the identification of the "privacy concerned attributes" is straightforward or you are having a predefined list of attributes that you believe to be privacy concerned.

The other question is what are the "places where pseudonyms can't be used"? 

Regards
Awanthika Senarath
PhD Research Student
Australian Centre for Cyber Security
Australian Defence Force Academy
The University of New South Wales (UNSW Canberra)


On Thu, Jan 11, 2018 at 5:21 AM, Jayanga Kaushalya <[hidden email]> wrote:
Hi all,

To cater the requirements related to [1], we are planing to implement a set of utility classes to mange privacy of privacy concerned objects (Eg: User).  

All the objects that are with privacy concerned attributes will be wrapped inside a privacy insulator object. Duty of the privacy insulator is to prevent the misuse of privacy related attributes. It will hide the attributes that are related to object's privacy and provide a hash or id as a pseudonym to represent the attribute instead of the real value. Furthermore, classes can be marked as confidential as well. All confidential classes should provide the pseudonym to represent there privacy concerned attribute. So whenever using a confidential object, pseudonym will be used instead of the underlying real value. 

There will be separate ID manager to map the related ID with the underlying actual value. So wherever the actual value should be needed, (Eg: Display the users username in a UI) ID manager can retrieve it and used. But this should be used only in places where pseudonym can't be used.

Please provide your thoughts.  

[1] [Architecture] GDPR - Pseudonyms For Username

Jayanga Kaushalya
Senior Software Engineer
Mobile: <a href="tel:+94%2077%20786%200160" value="+94777860160" target="_blank">+94777860160
WSO2 Inc. | http://wso2.com
lean.enterprise.middleware



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev





_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev




--

Tharindu Edirisinghe
Senior Software Engineer | WSO2 Inc
Platform Security Team
Blog : http://tharindue.blogspot.com
mobile : +94 775181586


_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Insulating Privacy in User Operations

Jayanga Kaushalya
In reply to this post by Awanthika Senarath-2
Hi Awanthika,

There aren't any predefined set of attributes and here we are mainly concerning about user's username. All claims that are related with user information are classified as privacy concerned attributes and we do not log or misuse them earlier as well. Idea for this privacy insulator is to extend this to a level much similar like Java security manager in future and use policies to manage the privacy concerns. 

As "places where pseudonyms can't be used" I meant the places where end user directly access and should have the meaning of that attribute. For an example, In a user dashboard if there is a section where we need to display the username in the UI, it is not user friendly to show the pseudonym and instead we should show the real value.

Thanks!

Jayanga Kaushalya
Senior Software Engineer
Mobile: +94777860160
WSO2 Inc. | http://wso2.com
lean.enterprise.middleware



On Fri, Jan 12, 2018 at 2:04 AM, Awanthika Senarath <[hidden email]> wrote:
Hello Jayanga,

This looks interesting and timely, however, two questions. How do you plan to identify the "privacy concerned attributes" for a particular person? From your email, it appears as the identification of the "privacy concerned attributes" is straightforward or you are having a predefined list of attributes that you believe to be privacy concerned.

The other question is what are the "places where pseudonyms can't be used"? 

Regards
Awanthika Senarath
PhD Research Student
Australian Centre for Cyber Security
Australian Defence Force Academy
The University of New South Wales (UNSW Canberra)


On Thu, Jan 11, 2018 at 5:21 AM, Jayanga Kaushalya <[hidden email]> wrote:
Hi all,

To cater the requirements related to [1], we are planing to implement a set of utility classes to mange privacy of privacy concerned objects (Eg: User).  

All the objects that are with privacy concerned attributes will be wrapped inside a privacy insulator object. Duty of the privacy insulator is to prevent the misuse of privacy related attributes. It will hide the attributes that are related to object's privacy and provide a hash or id as a pseudonym to represent the attribute instead of the real value. Furthermore, classes can be marked as confidential as well. All confidential classes should provide the pseudonym to represent there privacy concerned attribute. So whenever using a confidential object, pseudonym will be used instead of the underlying real value. 

There will be separate ID manager to map the related ID with the underlying actual value. So wherever the actual value should be needed, (Eg: Display the users username in a UI) ID manager can retrieve it and used. But this should be used only in places where pseudonym can't be used.

Please provide your thoughts.  

[1] [Architecture] GDPR - Pseudonyms For Username

Jayanga Kaushalya
Senior Software Engineer
Mobile: <a href="tel:+94%2077%20786%200160" value="+94777860160" target="_blank">+94777860160
WSO2 Inc. | http://wso2.com
lean.enterprise.middleware



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev






_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev