3 ms·
What I'm interpreting the value of this to me would be is that I can bootstrap user enrollment by getting them to login to my application with a social identity
by motohagiography 4y ago
What I'm interpreting the value of this to me would be is that I can bootstrap user enrollment by getting them to login to my application with a social identity they assert via hello.coop, and then I can add layers of additional identity assurance on top of that login if my application requires it.
As a developer/architect, I would have a user enrollment waiting room role in my application/service where certain features would be available to hello.coop asserted identities, and then more features would become available as I got the necessary identity assurance/KYC from them. It removes the need for me to do password management and account recovery, because that's on the user to manage via their social identities.
As a user, I presume if I want access to a service, I just pick the IDP of my choice to use for a given service. (imo, protonmail needs to provide an oauth2 identity service as well)
The resilliance of this could be provided by linking social identities on a blockchain, so if any one or two IDPs decide they're going to cut hello.coop off, the users can still use their hello.coop identity that was linked to their other social logins, and just not the IDP who defected.
Is this an accurate interpretation?
- dickhardt 4y agoThanks for the comments and describing your interpretation -- which is correct -- clarifications follow: We not only support social login, but also crypto wallets that support browser extensions or Wallet Connect. The user can also just use email or phone. We will be adding support for Passkey once the implementations have sorted out some details. Yes, you can bootstrap enrollment with Hellō and then prompt the user for additional profile / identity assurance. We are working on supporting KYC claims as well so that you could request them and then Hellō would interact with the user on how best to gather those from the user if we don't already have them. IE we would be an abstraction layer for KYC similar to being an abstraction for login and profile registration. As a user, you pick your "IdP" for your Hellō wallet, and use that IdP for all apps that support Hellō until you want to change your preferred provider. In the future, the user does KYC once with us and then has a reusable identity. wrt. resilience -- we encourage users to setup two or more backup providers so they can recover their Hellō Wallet if they lose access to their preferred provider. Recovery requires logging in with two backup providers, and then they can change their preferred provider.