Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Roman Zoun Dr.-Ing. Roman Zoun
  2. Michel Sahli Michel Sahli
  3. TBA

Project Description (no more than 1,000 words including graphics)

...

  1. Onboarding processes are established on nearly every online service using social login via OIDC This is easy, but involves a central identity provider such as LinkedIn Facebook google etc, see this:
  2. The current solution is user friendly and everyone love to use it, mostly with an two factor authentication, which involves often the mobile phone and a password. 
  3. The social login is integrated in the process like start-button on windows desktop, but everytime I use it, the central IDP notice this and can learn more about the behavior of the user. For example, I logged in here using linkedIn, so LinkedIn will provide me some advertisment arount linux advertisement around Linux foundation. 

Solution

  1. Provide a service which combines the usual social login onboarding, without the central IDP get your behavior. We introduce the Social verifiable credential, a service where a user login once, and issue his social account as verifiable credentials in his wallet. In addition we introduce a simple OIDC SSI verifier to include the social login as verifiable credentials easy into your service. 
  2. Our solution doesn't include any central IDP, no databases for storing the data and is easy to integrate to your service, as configuration for docker-compose, kubernetes AWS, Azure, Google Cloud ...
  3. As minimum is an issuer with the social login via central IDP. The verifier is not needed in the beginning, since a lot of products can solve this

...

  • The risk is, that no one will integrate the OIDC-Verifier, because of the effort (chicken egg problem)
    • We reduce the risk by providing a lot of tutorials and support to integrate the OIDC verifier
    • OIDC-Verifier is free, and we say that other products of trinsic, esatus, evernym can be used here
  • another risk is the scalability of user access, what if it goes to the moon, we are not sure about the scalability of the aries wallet
    • we reduce it, by hyperledger community support for production ready deployment of cloud wallet
  • Another risk, is that users will not use it (chicken egg problem)
    • We need at least on hyperledger/linux foundation the possibility to login with it, then we will make marketing to show the data privacy benefits for the user
    • hope it begins with some enthusiasts but will scale later to everyone
    • Since this is something that users get into SSI, we are sure, we get marketing support of SSI companies and enthusiasts
  • Another Risk is that one social provider blocks us
    • Limit risk by instant marketing reactions around this, and starting petitions, and ask all known GPDR data protection auditors to look at this...we can't do other things