Innovation Tagline: (decentralization of central Identity Provider)
...
- Roman Zoun Dr.-Ing. Roman Zoun → Lead (Marketing, Dev: Aries, Spring boot, Angular)
- Michel Sahli Michel Sahli (Deactivated) → First Dev Lieutenant (Aries, Spring boot, Angular)
- Thomas Eppler Thomas Eppler → User Excitement Officer
- Manuel Forster Manuel Forster → Genious IT Sculpter (Aries, Spring boot, Angular)
Project Description (no more than 1,000 words including graphics)
...
Source: https://twitter.com/SSI_by_memes
list of abbreviations
- OIDC - OpenID Connect allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.
- IDP - Identity Provider s a system entity that creates, maintains, and manages identity information for principals and also provides authentication services to relying applications within a federation or distributed network. Identity providers offer user authentication as a service. Relying party applications, such as web applications, outsource the user authentication step to a trusted identity provider
Problem
- 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 page of hyperledger foundation:
- 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.
- The social login is integrated in the process like start-button on windows desktop, but everytime every time I use it, the central IDP identity provider 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 advertisement around Linux foundation.
- And if I'm not logged in in LinkedIn, I need to login again, which means I need to know my password
- Summary of Problems:
- The users
- behavior is tracked in the current services, which makes the user to a product of social identity provider!
- The user need to remember so much passwords!
Solution
- 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.
- The user have then a passwordless social identity, because the whole account is in your wallet
- We introduce a easy auth server using SSI configured for the social accounts, that can be used for Login on every plattform.
- 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 ...
- alternatively we plan to use zapier for easy integration, like trinsic
- Our goal is decentralize, so verey service provider need to add his own verifier but we provide the easiest way to do it
- Minimum Implementation goal:
- 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 (trinsic, esatus, ...)
Accomplishment and Team
- Roman Zoun Dr.-Ing. Roman Zoun → Lead (Marketing, Dev: Aries, Spring boot, Angular)
- OIDC dev
- aries AIP1 jedi
- Springboot investor
- angular friend
- inventive thinker
- marketing executer
- Michel Sahli Michel Sahli (Deactivated) → First Dev Lieutenant (Aries, Spring boot, Angular)
- OIDC knight
- Security Boss
- aries AIP2 expert
- Springboot fabricator
- angular padawan
- applied researcher
- Thomas Eppler Thomas Eppler → User Excitement Officer
- Inventive thinker
- client satisfaction officer
- business researcher
- innovation driver
- metaverse mesmer
- early digital identity adopter
- Manuel Forster Manuel Forster → Genious IT Sculpter (Aries, Spring boot, Angular)
- Architecture
- aries AIP1
- Springboot guru
- DevOps expert
- angular lover
Project Plan
...
Milestone 1 - Define Data Governance
- Define schemas,
- Google Verifiable Credetnial schema
- Facebook Verifiable Credetnial schema
- Twitter Verifiable Credetnial schema
- ...
Milestone 2 - Implementing a Plattform includes social identity provider authentication
- implement platform with at least one social login (first google, then facebook, twitter, linkedIn, Apple, GitHub WeChat, amazon, etc),
- Spring Security Client with google IDP configuration
Milestone 3 - Implementing a service to issue the data from identity provider as verifiable credential to a wallet
- implement self-issuer service, which means the user see his data after login and then can issue it to his wallet (Evernym/lissi/trinsic/esatus),
- Spring Backend
- Spring Webhook, Aries cloud wallet for issuing and communication with user wallet
- Angular frontend
Milestone 4 - Marketing about out awesome plattform
- Start marketing for OIDC-Verifier and easy tutorials how to integrate with videos, twitter, with help of hyperledger
- Some Ideas for marketing
- Target Services: Create Video describing architecture and how central idp is working
- Target users: Create funny sketches how would it be if your wife/mama/dad would be like central IDP and know everytime you check in in a hotel or a bar or club
- Target Services: Create Architecture Video for decentralization of central IDP and the service still can save the data in the service, and for the service it doesn't have any negative aspects
- Target users: Same funny video how with the wife/mama/dad, but this time she only knows, you go to a friend, but doesn't know what you did next
- Share via twitter, tiktok etc
- Some Ideas for marketing
Milestone 5 - Implement a verifier, which allows OIDC authentication via SSI and the Credentials defined in Milestone 1 and issued by milestone 2 and milestone 3
- implement OIDC-verifier with configuration for the credential definition ids of the social login
- Spring athorization server + Spring Webhook + Aries cloud wallet
- configured on credential definition ids of the Verifiable credentials that are implemented on the platform
- Login page is QR code with proof request for this
- implement different ops configs, for Premis, Cloud, Proxy etc
Appendix
Support from ssi product provider
- If a product provider give us access to their technology for free, we will use it and be much faster.
- Trinsic, Lissi, Animo Solutions provide verifier, that can be used as verifier, too
Risk
Risk
- The risk is, that no one will integrate the OIDC-Verifier, because of the effort and users will not use, because it is not integrated in services (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
- 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 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 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
- Add positive feedback/marketing to providers who accept this for publicity and privacy of their customers
...