Hi Viduranga, I will put my attention to the changes that u have suggested. Thank you for the kind feedback.
Thanks and regards, Shan Chathusanda Jayathilaka Software Engineer (Intern) WSO2 Inc. Mobile : +94702062877 Email : sh...@wso2.com LinkedIn : www.linkedin.com/in/shanchathusanda/ On Thu, Dec 14, 2017 at 9:16 AM, Shan Jayathilaka <sh...@wso2.com> wrote: > Hi all, > > In this mail I attached the [1]swagger hub link for the > api-user-consent-management.yaml for a better view. > [1]. api-user-consent-management.yaml file > <https://app.swaggerhub.com/apis/ShanChathusanda/wso-2_identity_server_user_consent_management/v1.0.0> > > Thanks and regards, > > 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, Dec 13, 2017 at 4:26 PM, Viduranga Gunarathne <vidura...@wso2.com> > wrote: > >> Hi Shan, >> >> On Wed, Dec 13, 2017 at 10:39 AM, Shan Jayathilaka <sh...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> In this mail I would like to present my current situation of the project. >>> >>> I implemented some features of the consent receipt generation as the >>> Kantara Consent Receipt specification. In here I will explain those in >>> details. As I mentioned in my previous mails I created a MySQL database to >>> store the consents of the users. Also I implemented the DAO layer for that >>> database to update and retrieve the data. Now I’m currently implementing >>> the endpoint with RESTful APIs for the above database. I used swagger to >>> create the endpoint’s API documentation and generated the endpoint using >>> CXF. I attached the [1]swagger file( api-user-consent-management.yaml ) >>> below at this mail. >>> >>> I will briefly describe the APIs here. >>> >>> /consent/{subjectName} - Getting consent details of an user to populate >>> the UI >>> >> IMO this should be "/consents" instead of "/consent" because then it will >> give the idea of selecting a single consent out of a list and can i suggest >> using "userId" or "userName" instead of "subjectName" >> >> /consent/{subjectName}/thirdParty - Getting consent details regarding to >>> the third party which operated on the user data (In here I used a query >>> parameter to send the third party id to the backend) >>> >> Camel case notation is not the best practice when building REST APIs. I >> think this should be changed to "third-party" >> >> /consent/{subjectName}/serviceList - Getting details of consented >>> services by an user >>> >> serviceList --> /service-list >> >> >>> /consent/{subjectName}/services/{serviceId} - Getting service details >>> regarding to the subject name and the service id >>> >>> /consent/{subjectName}/services/{serviceId}/purpose - Getting details >>> of purposes of a service by subject name ( In here I used a query parameter >>> to send the purpose id to the backend ) >>> >>> /consent/configuration/dataController >>> >>> Post - Adding details of the data controller to the consent database ( >>> used a DTO in the body to send the details. ) >>> >>> Get - Getting data controller details by the id ( used a query parameter >>> to send the data controller id. ) >>> >>> Put - Updating the data controller details of the consent database ( >>> used a DTO in the body to send the details. ) >>> >>> /consent/configuration/personalInfoCategory >>> >>> Post - Adding a personally identifiable info category to the consent >>> database ( used a DTO in the body to send the details. ) >>> >>> Get - Getting personally identifiable info categories from the database >>> ( used a DTO List to get the details. ) >>> >>> Put - Updating personally identifiable info categories in the consent >>> database ( used a DTO in the body to send the details. ) >>> >>> /consent/configuration/service >>> >>> Post - Adding details of a service to the consent database ( used a DTO >>> in the body to send the details. ) >>> >>> Get - Getting details of services from the database ( used a DTO List to >>> get the details. ) >>> >>> Put - Updating details of a service in the consent database ( used a DTO >>> in the body to send the details. ) >>> >>> /consent/configuration/purpose >>> >>> Post - Adding details of a purpose to the consent database ( used a DTO >>> in the body to send the details. ) >>> >>> Get - Getting purpose details from the consent database ( used a DTO >>> List to get the details. ) >>> >>> Put - Update details of a purpose in the consent database ( used a DTO >>> in the body to send the details. ) >>> >>> /consent/revoke >>> >>> Put - Revoke consent of an user by service and purpose ( used a DTO List >>> to get the details. I used put because I used a flag called STATUS in >>> SERVICE_MAP_CRID table to keep the consent details’ status which can be >>> “Approved” or “Revoked”. I do that because in an organization they keep the >>> revoked user details at least 7 years. ) >>> >>> /consent/{subjectName}/receipt >>> >>> Get - Getting consent details of an user to create the consent receipt >>> >>> /consent/receipt/webForm >>> >>> Post - Adding user consent details from a web form which is provided by >>> the user. >>> >>> /consent/receipt >>> >>> Post - Adding user consent details from a JSON which is provided by the >>> user >>> Further details are in the [1] YAML file below. >>> <https://mail.google.com/mail/u/0/?ui=2&ik=2b82ec457b&view=att&th=1604e421cce6e0c1&attid=0.1&disp=safe&realattid=f_jb4la8zc0&zw> >>> >>> >>> [1].api-user-consent-management.yaml >>> (22K) >>> >>> <https://mail.google.com/mail/u/0/?ui=2&ik=2b82ec457b&view=att&th=1604e469ca5263b2&attid=0.1&disp=safe&realattid=f_jb4la8zc0&zw> >>> >>> >>> >>> Kindly requesting your feedback as before. >>> >>> Thanks and regards, >>> >>> 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, Dec 13, 2017 at 10:28 AM, Shan Jayathilaka <sh...@wso2.com> >>> wrote: >>> >>>> 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 <+94%2070%20206%202877> >>>> 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-9201e13564 >>>>>>>>>>>>>> 18 >>>>>>>>>>>>>> >>>>>>>>>>>>>> [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/pushpalanka/ | 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 >>> >>> >> >> >> -- >> Regards, >> >> *Viduranga Gunarathne* >> >> *Software Engineer Intern* >> >> >> *WSO2* >> Email : vidura...@wso2.com >> Mobile : +94712437484 <+94%2071%20243%207484> >> Web : http://wso2.com >> [image: https://wso2.com/signature] <https://wso2.com/signature> >> >> _______________________________________________ >> 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
