On Tue, Jan 16, 2018 at 2:45 PM, Asela Pathberiya <[email protected]> wrote:
> > > On Fri, Jan 5, 2018 at 5:50 PM, Jayanga Kaushalya <[email protected]> > wrote: > >> Hi all, >> >> According to the GDPR act [1] Chapter 3, Section 3, Article 17 (Right to >> erasure) the data subject has the authority to request the erasure of the >> data from controller. And the controller has the authority to erase the >> data according to the conditions given in the Article 17. And in an event >> of erasure request, it should perform the action without giving an extreme >> delay and erase all of the relevant information. >> >> In the current implementation, some of the user information (Ex: >> username) scattered around multiple locations and it is technically hard to >> clear all of the data from a single action without giving a significant >> delay. For an example there are instances username is printed in logs and >> it is technically difficult to erase those instances from logs. >> >> *Solution - Introducing Pseudonyms for Username* >> >> By introducing a pseudonym for username we can limit the usage of actual >> username throughout the system. By doing this erasure of actual username >> will remove the underlying value represented by the pseudonym attached to >> it. Hence it'll make the removal of user information from all of the >> related locations technically feasible. There are two main approaches to >> implement the pseudonyms for username which are below described. >> >> *Approach 1 * >> >> Keep the core implementation to work with usernames and change all of the >> output locations to convert username to relevant pseudonym and output. >> >> *Approach 2* >> >> Change the core implementation to work with pseudonym and change the >> places where the user friendly username is required. >> >> *Preferred Approach* >> >> Approach number 2 is selected as the best approach since all of the >> internal usages will be change to use the pseudonym and in a event of >> failure pseudonym will be displayed instead of the actual username which >> will guaranty the compliance. >> > > > It seems to be that approach 2 would add some more advantages such as > implementing the usename renaming. But we need to more careful with the > design as interfaces may be needed to modify. > > Are we storing the pseudonyms vs username in somewhere ? internal store > or user store ? > Since the pseudonym is introduced from Identity Server side and we have to consider about read only user stores, we are keeping the mapping on a Identity Server side. Not on the user stores. > > When it comes to username. Does it consider as user store domain + user > store username + tenant domain or just user store username ? > Username will be just user store user name. But the pseudonym will be unique to user store domain + username + tenant domain. > > >> >> [1] http://data.consilium.europa.eu/doc/document/ST-5419-2016-INIT/en/pdf >> >> Thanks! >> >> *Jayanga Kaushalya* >> Senior Software Engineer >> Mobile: +94777860160 <+94%2077%20786%200160> >> WSO2 Inc. | http://wso2.com >> lean.enterprise.middleware >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks & Regards, > Asela > > ATL > Mobile : +94 777 625 933 <+94%2077%20762%205933> > +358 449 228 979 > > http://soasecurity.org/ > http://xacmlinfo.org/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
