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 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| 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/p >>>> ushpalanka/ | 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 >> >> >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
