Hi, Sorry about the short notice. The security meeting to discuss this topic will be held today (Feb 16) 10-11 EST at my vidyo room. The web link to access my vidyo room is:
https://conf.inclusivedesign.ca/flex.html?roomdirect.html&key=BC6m8NWDbY If there’s time left in this meeting, we’ll talk about other in-time security tasks for APCP Pilots listed at https://pad.gpii.net/p/gpii-security-next-step-nov-17-2016-p0m4nmb, line 30-42 Thanks and see you there. Cindy On Feb 13, 2017, at 4:05 PM, Li, Cindy <[email protected]<mailto:[email protected]>> wrote: Hi all, Last time when we discussed on this topic, see meeting notes<https://pad.gpii.net/p/protect-the-preferences-server-jan-4-wy84nfy>, we agreed that OAuth2 Resource Owner Grant<https://tools.ietf.org/html/rfc6749#section-4.3> is a suitable solution for our use case where the local GPII acts as a highly privileged application to receive GPII user tokens, and then use user tokens to retrieve lifecycle instructions from GPII cloud. This leads to a question of how OAuth2 client ids and secrets can be securely stored on users' machines. This wiki page collects the research of possible approaches for safely storing credentials such as OAuth2 client id/secret on native devices, especially devices at public spaces: https://wiki.gpii.net/w/Continued_Researches_on_Possible_Approaches_for_Protecting_Communication_btw_LFM_and_CBFM#Results I’d like to hear your opinions on: 1. Other approaches? 2. Other vulnerabilities for these approaches? 3. Other areas I should look at for this security issue. 4. Any corrections or improvements to this wiki. Looking forward to your feedback. Thanks. Cindy _______________________________________________ Architecture mailing list [email protected]<mailto:[email protected]> http://lists.gpii.net/mailman/listinfo/architecture
_______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
