Show HN: Hellō, a cooperative approach for online identity

Hi HN!

I’m Dick Hardt[1]. Over the last twenty years, I’ve led the design of identity standards (OAuth 2.0, JWT) and systems that you and billions of others use every day.[2]

You know that these systems don’t always work in your favor. Each is bespoke and most, if not all, of your identity is locked up in these silos. I called this out in my Identity 2.0 OSCON talk in 2005 where I popularized a user-centric identity vision.[3]

Unfortunately, we have failed to realize the vision of user-centric identity: of giving you control of your identity. We have far too many passwords. Identity theft is rampant. Online interactions are either tedious or risky. In short, internet identity is a disaster today.

Most proposals today to give you control of your identity require you, your applications, and the issuers of claims about you (such as your bank or government), to adopt a new technology - a three-sided cold start problem.

I founded Hellō to take a different approach -- an abstraction layer that lets you use the technology and identity you already have -- that’s operated by a not-for-profit co-operative.

The Hellō journey did not start with building a product -- it started with exploring how to resolve the risks of a central service, and finding organizations aligned on the vision. Once three industry-leading organizations joined as founding corporate members of the co-operative, we built and tested our PoC, our MVP, and then our developer console.

Hellō is available for you to use today. We have a demo at https://greenfielddemo.com. Several apps use Hellō today, and many are exploring adoption. If you are building a new app, you can tick off most of your identity tasks in a few hours if you use Hellō. Details at https://hello.dev

We’d love feedback on your experience.

In contrast to other identity service offerings, Hellō does not help the developer manage and store user data -- Hellō helps the user manage their data and share it with the developer. The Hellō business model is to charge (in the future) an interchange fee of a few pennies for each new verified claim the user releases to the application. There is no MAU fee. No fee for authentication. No fee for users. No fee for issuers.

We expect you have more questions.

https://www.hello.coop/pages/approach.html describes:

- Our approach

- How the cooperative works

- How we’ll fund Hellō with smart contracts

- Our guiding tenets

- How we protect people’s privacy

- Our architecture

Thanks for reading and trying! Please share your questions, impressions, criticisms, and requests!

Want a more personal interaction? I am hosting an AMA on Twitter Space later today (Wed Oct 12) from 4-5PM PT.

https://twitter.com/i/spaces/1LyxBqvnmAyJN

You can also email me dick.hardt@hello.coop

[1] https://www.linkedin.com/in/dickhardt/ https://en.wikipedia.org/wiki/Dick_Hardt https://twitter.com/DickHardt

[2] https://datatracker.ietf.org/doc/html/rfc6749, https://datatracker.ietf.org/doc/html/rfc6750, https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/

[3] https://www.youtube.com/watch?v=RrpajcAgR1E

SIOP has been around for a long time without any adoption. A critical technical challenge is getting the operating systems to support managing the app that responds to the 'openid:' scheme. On iOS, the last app installed gets the call, which is not what you want for your identity wallet.

I gave a talk on the need to be pragmatic to get adoption:

https://www.kuppingercole.com/watch/eic2021-hardt-dogmatism-...

My name? It is special. =)

The second point is more concerning.

A related point is that it only works if the user already has a wallet installed that is listening on "openid:". "mailto:" and "tel:" work on a phone since there is an email and phone app on all phones by default.

This is a classic chicken and egg problem. Why would a developer use "openid:" if there are few, if any users, and why would a user install a wallet for "openid:" if there are no apps.

Thanks for your encouragement! ... would love any other feedback you have.

We believe Hellō is SSI (Self Sovereign Identity) -- decentralized approaches are one way to approach -- a distributed centralized approach like Hellō is another way that is more pragmatic.

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?