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