We have decided to move on to a new approach. Please see the details related to new approach in [1]
[1] GDPR - Compliance Tool (Right to be forgotten) *Jayanga Kaushalya* Senior Software Engineer Mobile: +94777860160 WSO2 Inc. | http://wso2.com lean.enterprise.middleware On Mon, Jan 22, 2018 at 6:01 PM, Jayanga Kaushalya <[email protected]> wrote: > Hi Maduranga, > > Idea of this user id is to decouple the username from where it is used > inside the system. So in an event of user removal, user id will not give an > actual meaning. So this user id is internal to the system and we are not > going to use it out side the system. > > Thanks! > > *Jayanga Kaushalya* > Senior Software Engineer > Mobile: +94777860160 <+94%2077%20786%200160> > WSO2 Inc. | http://wso2.com > lean.enterprise.middleware > > > > On Mon, Jan 22, 2018 at 5:37 PM, Maduranga Siriwardena <[email protected] > > wrote: > >> Hi Jayanga, >> >> Now as we are maintaining a userId in our system, shall we use the same >> as the id in the SCIM requests/responses also, rather than maintaining a >> separate identifier for SCIM? >> >> Thanks, >> Maduranga. >> >> On Thu, Jan 18, 2018 at 7:59 PM, Jayanga Kaushalya <[email protected]> >> wrote: >> >>> 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-IN >>>>> IT/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 >>> >>> >> >> >> -- >> Maduranga Siriwardena >> Senior Software Engineer >> WSO2 Inc; http://wso2.com/ >> >> Email: [email protected] >> Mobile: +94718990591 <+94%2071%20899%200591> >> Blog: *https://madurangasiriwardena.wordpress.com/ >> <https://madurangasiriwardena.wordpress.com/>* >> <http://wso2.com/signature> >> >> _______________________________________________ >> 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
