[Phase-3] HIP-20: Add Proof Of Humanity login mode to cryptoauth.io

HIP: ??
title: Add Proof Of Humanity login mode to Cryptoauth 
author: Greg (@xunkulapchvatal)
status: Draft Phase 1
created: 2021-06-09

Simple Summary

Implement dedicated UI and simple configuration option for “Login with Proof Of Humanity” in Cryptoauth.


Currently when you want to allow people to login to your Discourse, WordPress, etc, using their Ethereum wallet and limit it to only people with PoH, you can use built-in Cryptoauth token restrictions mechanism. This works, but it’s far from ideal.

The user is exposed to more details (like proxy contract address) than necessary and looses the feeling of integrity. He clicks “Login with Proof Of Humanity” button, but nothing on login screens indicates that he is still in this (PoH login) process.

On the integration side, an integrator is required to ask me (Greg) to set token restrictions for given integrations instead of being able to set them on their own during configuration process.

Dedicated mode will improve end-user experience and allow for much easier integration of Proof Of Humanity login to new web applications.


I want to provide simple way for people to be able to add “Login with Proof Of Humanity” to their websites. I believe this will be beneficial both for Cryptoauth project (it will be much easier to use it) and to Proof Of Humanity project (it will be much easier for communities to adopt it in their forums and other websites).


The work in this proposal can be split into two categories: Configuration backend and Dedicated UI. Self-registration portal that would further enhance the integration experience is out of scope for this proposal.

Configuration backend

In order to make the integration as simple as possible I decided that providing “scope” based configuration option would be the best approach.

During the configuration of Discourse or other software to use Cryptoauth, you would pass proof-of-humanity in scope parameter and this would force Cryptoauth to switch from default mode to “Login with Proof Of Humanity” mode.

The work here is mostly on the backend services that need to interpret this configuration and pass it to UI.

Dedicated UI

UI changes are mostly described in designs.
Additionally, the wallet select screen would also need to change and address select screen would need to indicate which addresses are verified with PoH.
Wallets can provide multiple addresses for login and user should see clear information which of the addresses from his wallet are valid for PoH login.


Adding PoH login option to Cryptoauth looks like the easiest and the fastest way to enable simple “Login with Proof Of Humanity” for all interested communities.

Login with Proof Of Humanity as separate product

There is an option to create separate product that would deliver the same functionality (separate domain) and to deploy it independently from Cryptoauth (either maintained by me or by external team)

This was rejected as requiring more work for initial release.
This option would still be available even after PoH login will be added to Cryptoauth main codebase as both solutions share much of the required work.

Maintenance & Support

I’m able to provide support for users (via Crisp integration in Cryptoauth) and maintain the system as part of normal Cryptoauth operations, but I will require dedicated contact person to pass them issues related to PoH itself.



Cost: 8k USD (~1 month/one developer).
This includes development, testing, operations costs during development and producing materials like configuration guides etc.

Technical support

Cost: 3k USD ($500/mo for 6 months)
The initial period of 6 months after the deployment is when I would provide technical support for users and provide fixes for any found bugs. After this period the support for “Login with Proof Of Humanity” would be included in normal Cryptoauth operations.

Total Cost

The total cost amounts to 11k USD



I strongly support that proposal.

As it is quite complete already, you can move it to phase 2 by editing the post (phase 1 to phase 2) and giving it a HIP number (19 for example), then launching a signaling poll on Snapshot as explained here


I’ve created the signalling proposal on snapshot but I can’t edit this post, can one of the admins modify it to have HIP-20 and phase-2 tag?



I don’t understand the voting options you have chosen:

  • Make no Changes
  • Modify
  • Reject

There is no “Accept” option, so I’m unsure which one to choose to express support.

Is the “Modify” option supposed to mean “Yes”?

“Make no changes” and “Reject” are redundant.

Yeah, I voted “Modify” as you would need to modify the voting options.
Just “Pass to phase-3” and “Make No Changes” would be good (obviously if it’s rejected, you can always modify it and ask a new vote).

Oh :frowning: I though that “Make no change” means “This proposal is good, don’t change it, I accept it”

I’m not sure how but I missed this sentence " poll indicates the result Make no changes, the proposal will not pass to Phase 3." and somehow assumed it meant the opposite.

So what would be the ideal set of options?

No problems I think you can just put it to vote again with “Pass to phase-3” and “Make No Changes”.

yes / no usually works well. keep it simple.


Here is the new proposal with fixed voting options Snapshot

Can i have access to that login mode repo for the project i started ?

1 Like

Cryptoauth is not yet open source (will be by the end of the year), but you don’t need to set it up yourself. I can generate client Id and secret for you and you can integrate cryptoauth like you would do with “login with google”

1 Like

I support this HIP and look forward to voting yes. Great work so far @xunkulapchvatal.eth :pray:

I would vote yes if it was Open Source

1 Like

In an ecosystem that is largely embracing open-source, having a closed-source middleware does not make too much sense to me. Especially because it’s an authentication middleware, I don’t think it should be opaque and just trusted to be secure.

The OAuth specs are famously vague and leave a lot of room for errors.

How do OAuth authentication vulnerabilities?
[…] One of the other key issues with OAuth is the general lack of built-in security features. The security relies almost entirely on developers using the right combination of configuration options and implementing their own additional security measures on top, such as robust input validation.

1 Like

For a login implementation, I’m also not too hesitant on accepting it, just because its closed source and a login system would be an integral part of the PoH framework.

Is there any way to change this proposal so that the final product is Open Source?

Eg: by turning it into an external module that CryptoAuth imports instead of embbeding it the core code?
I know this would depend on CryptoAuth’s architecture, but it’s just an example looking for ways to solve the closed source matter…


I am curious about the future path for the project as well.

@xunkulapchvatal.eth can you please elaborate on this statement. Why was it closed to start with? What is the path to becoming OSS? Why the end of the year and not now?

Thanks :pray:


Hi, yes, So it’s closed source because I’m in the middle of extracting it from monorepo I’ve created two year ago when I started building it together with ethmail and other projects. I’m also cleaning it up from hardcoded values etc. The goal is to have it open source and available for anyone to deploy of their own stack, but it will take some time.
I’ve set myself a dealine to release it as open source by the end of the year.
One more reason for it being closed right now is that managing inflow of requests/PR/questions would take some of my available time (I can work on cryptoauth and ethmail only on weekends right now) and it’s just easier to not do it at this time.

Re. the oAuth implementation, I’m using GitHub - ory/hydra: OpenID Certified™ OpenID Connect and OAuth Provider written in Go - cloud native, security-first, open source API security for your infrastructure. SDKs for any language. Compatible with MITREid. for the “protocol” layer (no way I’m going to implement this part myself) and focus on delivering signature validation, wallet support and good UX.

1 Like

If you have limited time, are you the one who is going to work on the login implementation?
Also, I’d suggest that this implementation is started only CryptoAuth goes Open Source.

Also, this path would more sense to me. On my perspective, it would be more beneficial to PoH than the CryptoAuth login on its own. This would make a difference for developments that want to integrate PoH or build around it, without having to rely on Crypto Auth only.


Yes, and no. I have a frontend developer who would help me on the UI and I would be focused on backend changes.


Ok, the signalling proposal passed. As I understand HIP-5 this thread should be updated with Phase-3 tag (and with proper metadata), and I should create binding proposal on snapshot.

What would be good set of vote options for binding proposal?
I think they should reflect concerns mentioned earlier in this thread