dickhardt

> I don't feel like it's worth giving up control over your user's authentication to an intermediary in return for saving a week of work. Maybe the case could be made for day-1 of a startup, but certainly not year-1, it's just too critical a component.

Are you not outsourcing to an intermediary with Apple/FB/Google?

Authentication is critical. Completely agree. It is also not a differentiator for your application unless done poorly. Using a 3P such as Apple/FB/Google leverages the account protection investment that those providers are making. Using Hellō gives the same protection, while preserving the user's privacy (provider does not know which app the user is logging into) -- and giving them choice and account recovery.

As noted, if you have already made the investment, Hellō does not provide the same value today.

> I'd also challenge this taking a week. Apple/FB/Google sign-on is pretty straightforward, and I've found the cost is mostly in setting up an open-source auth library in my webapps rather than enabling a given service provider.

I'm sharing my experience. Apple requires a D&B number to register your app. Many require you to jump through their process for proving control of a domain. Microsoft requires you register as a partner if you don't want the scary unverified label. FB disabled Hellō for not having the correct link to the app, then disabled for not having a required term in our T&S.

Others may not have the same challenges as I did -- but it was non-trivial amount of time to manage the app registrations.

FWIW I don't use libraries for the OIDC flows -- I find it makes it more complicated than it needs to be. I do use libraries for any JWT work of course.

Thanks 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.

Thanks for the questions!

Hellō is not decentralized -- apologies for any confusion -- did I mistakenly write that somewhere?

The governance is decentralized. Yes, it is another point of failure, as is any other service you build your app on. I have extensive experience with tier zero services such as AWS IAM and have applied those learnings to the Hellō deployment if that is any consolation.

The value proposition of Hellō is not as great for you as you have already made a substantial investment in your identity implementation. In the future when Hellō has a larger claims selection than verified email, phone and ethereum address -- you may find it valuable to use Hellō to request claims from your users. Additionally, depending on your application, you may want to make claims about your users that they can share with other sites. Empowering users to control their identity and share it is our mission. Claims can range from VIP cards to memberships to reputation scores.

Fully agree that social login is not hard to implement. (I'll take that as a compliment as one of the designers!) As you add additional providers so that you provider more choice to your users, the risk of a user fragmenting their identity by choosing a different provider when they return increases. Dealing with fragmented identities in your app is hard.

Additionally, registering and configuring your app at Apple / Facebook / Google etc. is non-trivial. I know what I am doing in theory, and I have already invested a week of time in configuration and approvals and updates.

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.

My name? It is special. =)

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

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

Existing libs for JWTs and PKCE

Minimizing a credential stuffing attack requires detecting the attack and then adding captchas or other bot mitigation techniques.

I did!

The identity federation protocol flows are pretty straight forward (I may be biased!) ... but you should use existing libraries for all the crypto.

Defeating credential stuffing attacks is HARD. That is where services such as Auth0 shine.

Your question is missing a couple key inputs. Q: Is your SaaS app targeting enterprise use cases, where the customer will want to enable SSO and centralized provisioning? Keybase is a reasonable choice in this case because of the SAML and SCIM support. Q: What is your expected revenue per user? Auth0 solves many problems out of the box, but is priced on MAU which can be prohibitive if your revenue per user is low, but deals with lots of complicated issues if not and lets you focus on building your app.

I'm the founder of Hellō[0], and if you are targeting consumers or individual professionals and want to give them choice, check it out.

As some background, I cofounded the OpenID Foundation, drove creation of OAuth 2.0 and what became JWT, and gave a popular Identity 2.0[1] talk years ago.

[0] https://hello.coop & https://hello.dev [1] https://www.youtube.com/watch?v=RrpajcAgR1E

My main gripe with LinkedIn is that the API is not even available for a fee through their partner programs.

Yahoo! mail recently launched integration with LinkedIn data, and Salesforce.com and Microsoft Dynamics have integration, but no other CRM is allowed to have access.

My app (Bubbler) used LinkedIn pretty heavily as a data source. There seem to be enough market demand that someone might be able to step in and be the new source of professional profiles.

Does the OP have an API for taking data out for Virtual CV users?

Facebook cut their API heavy when they phased out v2 last month. No access to friend data and limited access to user profile. LinkedIn is following FB's lead.