+1 for the idea given there's a standard way to extend the consent management module.
Do we already have associated properties for the consents? If not it's something definitely worthy having so that there's a defined way of storing data like this without involving external source which in turns requires maintaining configuration files etc. But in this case we can resort to that if this isn't available. On Sun, Jun 2, 2019 at 7:10 AM Ruwan Abeykoon <ruw...@wso2.com> wrote: > Hi Johann, > +1 for the idea. > List of devices maintain are some data we collect about user. The data can > grow and shrink with time, per user. It is not correct to ask for consent > per each alteration of the data. > The consent here is that the consent would be, and go to consent > management. (no change is needed) > "We collect your device information (i.e. Browser type, OS) and put > unique untraceable identifier as a cookie. Purpose is to allow better login > experience by remembering the devices you generally visit" > > The at the login flow, we ask, "Remember this device" at the successful > logon on new device, if the consent is already given. Prompt the consent > page if consent is not given (normal flow) > > Cheers, > Ruwan A > > > On Sun, Jun 2, 2019 at 12:54 AM Johann Nallathamby <joh...@wso2.com> > wrote: > >> Hi Godwin, >> >> I think the consent management framework in IS is only meant to manage >> consent receipts and not the data related to the consent transaction. So I >> have an alternative proposal which combines solution 1 and 3 above. >> >> What if we manage the remember device consents through the consent >> management module, and extend the consent management module to maintain a >> separate table to manage the device name/description for each consent >> given? We can use the consentReceiptID as the link between the consent >> receipt and the related consent data. >> >> I believe any kind of consent in future has to go through similar model, >> where the consent receipt is managed using the consent management module >> and consent related data is managed separately. Now if we had the >> capability to manage properties against a consent receipt with a CRUD API >> (not to delete the entire consent and create a new one, but just modify the >> properties only), probably we could have used those properties to store the >> data related to a particular consent receipt without adding a new table. >> Although you have mentioned that managing device IDs via properties is not >> a clean solution, you have not mentioned why. I assume it is because the >> APIs we have to do this, has some limitations. Is that the reason? >> >> What are your thoughts on my suggested approach? >> >> Regards, >> Johann. >> >> On Tue, May 28, 2019 at 10:36 PM Godwin Shrimal <god...@wso2.com> wrote: >> >>> Hi All, >>> >>> >>> Requirement >>> >>> 1. >>> >>> Maintain list of Remembered devices and show it in the user’s profile >>> 2. >>> >>> There should be a consent page in the authentication flow to get the >>> user’s consent and description/name for the device (Human readable) and >>> we >>> need to persist. Should be able to skip the consent page >>> 3. >>> >>> There is an option to “Forget device” where user can remove >>> Remembered devices from user profile. >>> >>> >>> Please see the proposed solutions for this requirement. >>> >>> Solution1 >>> >>> 1. >>> >>> Keep a separate table to maintain device information >>> 2. >>> >>> Expose device CRUD operations as rest services >>> 3. >>> >>> Store some signed information in the cookie with some unique >>> identifier >>> 4. >>> >>> When user login need to extract the cookie and do the validation >>> with what we have persisted in the table (We need to decide how >>> enforcement >>> happens. Ex. using an authenticator or some other way) >>> >>> >>> Solution2 >>> >>> 1. >>> >>> Maintain device information as a claim of a user >>> 2. >>> >>> Since user can have multiple devices, claim will be a json content >>> with multiple devices information >>> 3. >>> >>> Use SCIM API to get/update claim of the user >>> >>> >>> Solution3 >>> >>> Use current consent management implementation to maintain remembered >>> devices. Here we either have to maintain device ID as PII or as a property. >>> If we are maintaining as a PII, we need to add device ID as a PII category >>> and then its creating PII category per device. >>> >>> Note: Maintaining device as PII category having scalability issues and >>> maintaining device ID in the property also not a clean solution for this. >>> >>> From above solutions, I would like to go ahead with the claim based >>> solution (Solution2) since it’s more suitable with the current >>> capabilities we having in consent mgt. >>> >>> Appreciate your thoughts. >>> >>> Thanks >>> >>> Godwin >>> -- >>> Godwin Amila Shrimal | Technical Lead | WSO2 Inc. >>> (m) +44 744 466 3849 | (w) +44 203 696 6510 | (e) god...@wso2.com >>> <http://wso2.com/signature> >>> >> >> >> -- >> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | >> WSO2 Inc. >> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >> [image: Signature.jpg] >> > > > -- > Ruwan Abeykoon | Director/Architect | WSO2 Inc. > (w) +947435800 | Email: ruw...@wso2.com > > -- Shazni Nazeer | Senior Lead Solutions Engineer | WSO2 Inc. (m) +94 777737331 | (e) sha...@wso2.com <https://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
