-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trust - User has to trust that the host of the PIS will not use their SSO credentials for nefarious purposes #21
Comments
Solution:I would suggest we keep everything encrypted. What this will ensure:
ImplementationEncryptionLet's put in place the facility for a user to generate a public/private key pair. Specifically let's use BIP-39. This will allow to generate a random seed phrase for the user from which we can combine with BIP-32 to generate the master pub/private key (m/0'/0'/0'):
Data consumer integrationFrom here we can either:
Consequence:
|
@PlamenHristov although I thought about a different approach your approach with encryption also sounds good! :) GoalAs discussed on the slack channel also with @carrollgt91 I understood the goal of this team (this repo) to build a server which should be the middle-man between the sensitive data of the user who wants to be automatically authenticated and some data-consumer who wants an authentication or some data (e.g.: another app which wants to train on some sensitive data)
SuggestionIf my description of the goal of this specific repo is correct I thought about using the Public or Private Grid Platform using the PyGrid-library to make the exchange of sensitive data from service endpoints or training data possible.
If I understood our goal correctly in both scenarios no direct channel would need to be established between the user and the data-consumer because either the data-consumer would train their model using PyGrid (the second use-case) or the data is only provided to the SSI team which would then do the issuing, validation, etc. of credentials for authentication with the data-consumer. I may have too limited knowledge about the detailed working of PyGrid and the specific data needs of the SSI team, but potentially this could help us use much of the already existing code from other OpenMined projects. |
@PlamenHristov Great thoughts here - I think some form of user-managed encryption scheme does solve a lot of the issues here, this one and the security breach piece, which is great. Just to make sure I understand your proposal, it seems that
Assuming those assumptions are correct... One thing I really like about this proposal is how easy the UX is for the user to share data with data consumers when they're on the same device that has the key pair on it. It's not meaningfully different from an SSO handshake where the app you're signing into is requesting certain data from the sign on provider - i.e. sign in with facebook -> provide your name and profile photos. However, there are some additional challenges we'd need to overcome with this strategy. I'm not as familiar with what we'll need to do to hook into the rest of OpenMined infrastructure (i.e. PySyft), so I'm not going to comment much on that piece, and instead I'll focus on the data consumer use case.
|
In addition to being an attractive target for hackers, storing these SSO credentials presents an interesting trust problem from the perspective of more privacy-conscious users.
We are just committing to the user that we are not storing their information. We are not providing strong guarantees, cryptographic or otherwise, that we will not use this information for our own gain.
Especially for more powerful SSO integrations, such as bank accounts, it might be hard to convince folks to trust us.
The text was updated successfully, but these errors were encountered: