Page History

...

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

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 page of hyperledger foundation:
   
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 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. 
4. And if I'm not logged in in LinkedIn, I need to login again, which means I need to know my password
5. Summary of Problems:
   1. The users
   are the business model!
   1. behavior is tracked in the current services, which makes the user to a product of social identity provider!
   2. The user need to remember so much passwords! 

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. The user have then a passwordless social identity, because the whole account is in your wallet
3. We introduce a easy auth server using SSI configured for the social accounts, that can be used for Login on every plattform.
4. 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 ...
   1. alternatively we plan to use zapier for easy integration, like trinsic
   2. Our goal is decentralize, so verey service provider need to add his own verifier but we provide the easiest way to do it
5. Minimum Implementation goal:
   1. 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 → 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@adnovum.ch → 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

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
• 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 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

...