Hi all, First of all I would like to thank you for the kind feedbacks that you have provided and I’m very sorry for the late reply for this feedbacks.
As the feedbacks provided by you, we decided to go through this kind of solution for the PII CATEGORY and the Scopes. As an example let’s take a PII_CATEGORY called Contact. To this PII_CATEGORY we can add attributes like Address, Email and Telephone number. Regarding to the scope claim domain I think the PII_CATEGORY Contact is similar to a Scope and the attributes of the Contact is similar to the Claims. So I think we can create a custom scope in the registry to map the above scope and claims. Kindly requesting the feedbacks from you as previous. Thanks and regards, Shan Chathusanda Jayathilaka Software Engineer (Intern) WSO2 Inc. Mobile : +94702062877 Email : sh...@wso2.com LinkedIn : www.linkedin.com/in/shanchathusanda/ On Wed, Dec 13, 2017 at 8:54 AM, Shan Jayathilaka <sh...@wso2.com> wrote: > Hi Prasanna, > > I changed the data type of the Timestamp to integer. Thank you for your > kind feedback. > > Thanks, > > Shan Chathusanda Jayathilaka > Software Engineer (Intern) > WSO2 Inc. > > Mobile : +94702062877 <+94%2070%20206%202877> > Email : sh...@wso2.com > LinkedIn : www.linkedin.com/in/shanchathusanda/ > > > On Wed, Nov 8, 2017 at 3:26 PM, Prasanna Dangalla <prasa...@wso2.com> > wrote: > >> Hi, >> >> In the attached ER diagram, time stamps are defined to store using 100 >> characters in VARCHAR data type. I think we can reduce this size of this >> field If you are using unix time stamps. >> >> Thanks >> Prasanna >> >> *Prasanna Dangalla* >> Senior Software Engineer, WSO2, Inc.; http://wso2.com/ >> lean.enterprise.middleware >> >> >> *cell: +94 718 11 27 51* >> *twitter: @prasa77* >> >> On Wed, Nov 8, 2017 at 11:55 AM, Shan Jayathilaka <sh...@wso2.com> wrote: >> >>> Hi all, >>> >>> >>> I attached the [1]revised DB design to this mail. Following is a brief >>> description of the tables in our revised DB design. >>> >>> RECEIPT_TRACKER : This table will keep a track of all the consent >>> receipts which created by the organization ( Currently WSO2 ). This is for >>> the legal purposes. >>> TRANSACTION_DETAILS : This table will keep the details regarding to the >>> user and a system generated user id for each user by each data controller. >>> ( one user can give their consent to one to many data controllers ). >>> DATA_CONTROLLER : This table will keep a track of all the data >>> controllers in this scope. >>> SERVICES : This table will hold all the services given to the user. >>> PURPOSES : This table will hold all the purposes given to the user to >>> obtain their consent. >>> SERVICE_MAP_CRID ( will change the name ) : This will keep track of >>> consents which the user gave. ( For this purpose in this service ). >>> THIRD_PARTY : This table will contain the details of the third party >>> organizations that are going to use the user details for some purposes. >>> PII_CATEGORY ( will merge with the scopes in IS ) : This will keep the >>> details of personally identifiable information category that are going to >>> collect. >>> RECEIVED_CR_TRACKER : This table works as a log. This will keep the >>> details of uploaded consent receipt with a status accepted or rejected. >>> Other tables are to map all these above tables. This is for the legal >>> purposes. >>> >>> Kindly requesting your feedbacks. >>> >>> [1].revised_db_schema_20171108.pdf >>> (33K) >>> >>> >>> <https://mail.google.com/mail/u/1/?ui=2&ik=2b82ec457b&view=att&th=15f9a370a2cb00b6&attid=0.1&disp=safe&realattid=f_j9qmxzhz0&zw> >>> >>> Shan Chathusanda Jayathilaka >>> Software Engineer (Intern) >>> WSO2 Inc. >>> >>> Mobile : +94702062877 <+94%2070%20206%202877> >>> Email : sh...@wso2.com >>> LinkedIn : www.linkedin.com/in/shanchathusanda/ >>> >>> >>> On Wed, Nov 8, 2017 at 9:50 AM, Pushpalanka Jayawardhana <la...@wso2.com >>> > wrote: >>> >>>> Hi Shan, >>>> >>>> As discussed offline, please share the current revised DB design and >>>> the assumptions we made on the things that are not certain in the >>>> specification. >>>> Also +1 for Johann's suggestion to store PII categories separately then >>>> depending on scopes. Hence you can define a separate file in registry to >>>> keep PII category to user claims, similar to how we have stored scopes to >>>> user claims mapping. >>>> >>>> >>>> On Mon, Nov 6, 2017 at 3:19 PM, Shan Jayathilaka <sh...@wso2.com> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> As I am developing the consent receipt specification I have to keep >>>>> the details of the consents which are provided by the users. This is the >>>>> database design that I designed to store those consents. As a standard, >>>>> data in a database are not deleted permanently until some time is elapsed. >>>>> Regarding to the above scenario we need to put a flag to those data to >>>>> detect that as a deleted one or an active one. In this database mainly two >>>>> tables are populating from the user actions( TRANSACTION_DETAILS, >>>>> SERVICE_MAP_CRID). I already put flags to those two tables. Do we need to >>>>> put a flag to each and every table in this database to detect deleted >>>>> records. >>>>> Ex:- There is a table called PURPOSES to store predefined purposes to >>>>> capture user consents. When we want to delete a purpose from that can we >>>>> delete it normally or do we need to keep that with a flag to detect that >>>>> as >>>>> a deleted one. >>>>> >>>>> Regards, >>>>> >>>>> Shan Chathusanda Jayathilaka >>>>> Software Engineer (Intern) >>>>> WSO2 Inc. >>>>> >>>>> Mobile : +94702062877 <070%20206%202877> >>>>> Email : sh...@wso2.com >>>>> LinkedIn : www.linkedin.com/in/shanchathusanda/ >>>>> >>>>> >>>>> On Mon, Oct 23, 2017 at 4:49 PM, Shan Jayathilaka <sh...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Regarding to the GDPR regulation, the users have the chance to modify >>>>>> the consents which they provided before for the corresponding >>>>>> organization. >>>>>> When an user requests for his/her consents, the above organization must >>>>>> send the corresponding consents as a consent receipt. This receipt >>>>>> contains >>>>>> an unique ID called Consent Receipt Id. This ID is unique for the consent >>>>>> receipt. When the user modified his/her consent, this receipt id should >>>>>> be >>>>>> changed. Also the organization must keep track of these consent receipts >>>>>> due to legal issues. So we proposed a modification to the consent store. >>>>>> >>>>>> [1] receipt_tracker.pdf >>>>>> (25K) >>>>>> >>>>>> <https://mail.google.com/mail/u/1/?ui=2&ik=2b82ec457b&view=att&th=15f48687de0e56cd&attid=0.1&disp=safe&realattid=f_j93xsqet0&zw> >>>>>> >>>>>> >>>>>> The above table will keep track of the consent receipts according to >>>>>> the user. This table will populate after the consent receipt is generated >>>>>> to the user. >>>>>> >>>>>> *Brief explanation about the table* >>>>>> >>>>>> CONSENT_RECEIPT_ID - An unique id for the consent receipt. >>>>>> CONSENT_RECEIPT - Consents of the corresponding consent receipt. >>>>>> (unsigned JWT token) >>>>>> STATUS - 2 steps. >>>>>> 1. When the consent receipt is generated, >>>>>> STATUS will be "Generated" for that receipt, >>>>>> 2. If the consents are modified by the user, >>>>>> STATUS will be "modified" at that receipt and if the user is requesting a >>>>>> consent receipt, organization have to check the STATUS before sending the >>>>>> receipt. If the STATUS="Modified", a new ID will generated with the >>>>>> STATUS="Generated" for the new receipt and the previous receipt will be >>>>>> at >>>>>> the table with the STATUS="Modified". >>>>>> SGUID - This is a system generated user id to keep track with the >>>>>> user. >>>>>> RECEIPT_TIMESTAMP - The date and time of the consent receipt creation. >>>>>> >>>>>> Shan Chathusanda Jayathilaka >>>>>> Software Engineer (Intern) >>>>>> WSO2 Inc. >>>>>> >>>>>> Mobile : +94702062877 <+94%2070%20206%202877> >>>>>> Email : sh...@wso2.com >>>>>> LinkedIn : www.linkedin.com/in/shanchathusanda/ >>>>>> >>>>>> >>>>>> On Sun, Oct 1, 2017 at 7:08 PM, Johann Nallathamby <joh...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> I think it should be the other way around. PII category is protocol >>>>>>> agnostic. So we shouldn't store scopes in this new schema Shan is >>>>>>> proposing. Instead PII category can be referenced along with the >>>>>>> scopes, in >>>>>>> registry if that's where scopes are stored. >>>>>>> >>>>>>> Regards, >>>>>>> Johann. >>>>>>> >>>>>>> On Wed, Sep 20, 2017 at 9:45 AM, Hasanthi Purnima Dissanayake < >>>>>>> hasan...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi Shan, >>>>>>>> >>>>>>>> Along with these detail we save in these tables, we need to keep a >>>>>>>>> mapping to what each PII category means to WSO2 server. >>>>>>>> >>>>>>>> >>>>>>>> With our current implementation in Identity Server we maintain a >>>>>>>> scope-claim mapping in the registry level. For a scope a single or >>>>>>>> multiple >>>>>>>> claims can be mapped and we can define any custom or scope or claim. So >>>>>>>> IIUC here we can map PII category with scope. So indirectly we can map >>>>>>>> PII >>>>>>>> category with claims. But at the moment we don't store those scope - >>>>>>>> claim >>>>>>>> mapping in our database. So if we are to map PII category with the >>>>>>>> scopes >>>>>>>> we need to store the scopes in the db level. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Hasanthi Dissanayake >>>>>>>> >>>>>>>> Software Engineer | WSO2 >>>>>>>> >>>>>>>> E: hasan...@wso2.com >>>>>>>> M :0718407133 <071%20840%207133>| http://wso2.com >>>>>>>> <http://wso2.com/> >>>>>>>> >>>>>>>> On Wed, Sep 20, 2017 at 9:09 AM, Pushpalanka Jayawardhana < >>>>>>>> la...@wso2.com> wrote: >>>>>>>> >>>>>>>>> Hi Shan, >>>>>>>>> >>>>>>>>> Along with these detail we save in these tables, we need to keep >>>>>>>>> a mapping to what each PII category means to WSO2 server. >>>>>>>>> In that case we can think of a PII category as a collection of >>>>>>>>> claims. >>>>>>>>> >>>>>>>>> In IS we already have this concept of collection of claims, where >>>>>>>>> we categorize them into a scope. WSO2 APIM already make use of these >>>>>>>>> scopes >>>>>>>>> to provide role based access to resources. We can try to make use of >>>>>>>>> scopes >>>>>>>>> in the place of PII category to establish this mapping with server >>>>>>>>> claims >>>>>>>>> which are actually PII keys. In the 'PII_CATEGORY' table we can keep >>>>>>>>> track >>>>>>>>> of this. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> On Wed, Sep 13, 2017 at 2:45 PM, Shan Jayathilaka <sh...@wso2.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> There is a new regulation called the EU General Data Protection >>>>>>>>>> Regulation (GDPR) which replaces the Data Protection Directive >>>>>>>>>> 95/46/EC and >>>>>>>>>> was designed to harmonize data privacy laws across Europe. GDPR was >>>>>>>>>> passed >>>>>>>>>> as a regulation on 27th April 2016 and will be effective from 25th >>>>>>>>>> May >>>>>>>>>> 2018. Regarding to this regulation any organization who is >>>>>>>>>> collecting user >>>>>>>>>> data must collect data according to the user's consent. Also if an >>>>>>>>>> user >>>>>>>>>> request about his/her consents about the user data, the data >>>>>>>>>> collecting >>>>>>>>>> organization must provide those consents regarding to the user. In >>>>>>>>>> here we >>>>>>>>>> have to record what are the consents of the user to a database. I >>>>>>>>>> designed >>>>>>>>>> an [1]ER diagram for the database which collects the user consent. >>>>>>>>>> Also I >>>>>>>>>> attached [2] GDPR Regulation document ,[3] a blog to understand the >>>>>>>>>> GDPR >>>>>>>>>> and [4] Kantara Consent Receipt Management to this email. I hope >>>>>>>>>> they will >>>>>>>>>> be helpful to all. >>>>>>>>>> >>>>>>>>>> *Brief explanation about the database tables* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - TRANSACTION_DETAILS: Contains details about the consent >>>>>>>>>> receipt id and user identification. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - DATA_CONTROLLER: Contains details about the organization >>>>>>>>>> which collects the user data. >>>>>>>>>> - SERVICES: Contains details about the services provided to >>>>>>>>>> the user data. >>>>>>>>>> - PURPOSES: Contains details about the purposes to collect >>>>>>>>>> the user data. >>>>>>>>>> - THIRD_PARTY: Contains details about the third party >>>>>>>>>> organizations which take the user data shared by the data >>>>>>>>>> controllers. >>>>>>>>>> - PII_CATEGORY: Contains details about the personally >>>>>>>>>> identifiable information (pii) categories. >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> project_gdpr_new_erd.png >>>>>>>>>> <https://mail.google.com/mail/ca/u/1/?ui=2&ik=2b82ec457b&view=att&th=15e7a6f581a803f6&attid=0.1&disp=safe&realattid=f_j7ise0000&zw> >>>>>>>>>> (140K) >>>>>>>>>> <https://mail.google.com/mail/ca/u/1/?ui=2&ik=2b82ec457b&view=att&th=15e7a6f581a803f6&attid=0.1&disp=safe&realattid=f_j7ise0000&zw> >>>>>>>>>> >>>>>>>>>> [2] >>>>>>>>>> http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX >>>>>>>>>> :32016R0679 >>>>>>>>>> >>>>>>>>>> [3] >>>>>>>>>> https://medium.facilelogin.com/understanding-gdpr-9201e1356418 >>>>>>>>>> >>>>>>>>>> [4] >>>>>>>>>> https://kantarainitiative.org/confluence/display/infosharing >>>>>>>>>> /Consent+Receipt+Specification?preview=/76447870/90604248/DR >>>>>>>>>> AFT%20Recommendation%20Consent%20Receipt%20Specification%201 >>>>>>>>>> _0_0.docx >>>>>>>>>> >>>>>>>>>> Appreciate your feedback. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Shan Chathusanda Jayathilaka >>>>>>>>>> Software Engineer (Intern) >>>>>>>>>> WSO2 >>>>>>>>>> >>>>>>>>>> Mobile : +94702062877 <070%20206%202877> >>>>>>>>>> Email : sh...@wso2.com >>>>>>>>>> LinkedIn : www.linkedin.com/in/shanchathusanda/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Pushpalanka. >>>>>>>>> -- >>>>>>>>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons). >>>>>>>>> Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/ >>>>>>>>> Mobile: +94779716248 >>>>>>>>> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: >>>>>>>>> lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks & Regards, >>>>>>> >>>>>>> *Johann Dilantha Nallathamby* >>>>>>> Senior Lead Solutions Engineer >>>>>>> WSO2, Inc. >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> Mobile - *+94777776950* >>>>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Pushpalanka. >>>> -- >>>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons). >>>> Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/ >>>> Mobile: +94779716248 >>>> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/p >>>> ushpalanka/ | Twitter: @pushpalanka >>>> >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
