Skip to Content
How It WorksCredentials

Credentials

Human ID Standard Credential Format

A leaf is an element of a Merkle tree. Merkle trees allow for efficient and anonymous proofs of set membership in zero-knowledge. Leaves are Poseidon hashes of 6 254-bit field elements:

IndexNameDescription
0Issuer AddressThe Ethereum address of the credential issuer, i.e. who provided this attestation
1Nullifier SecretA secret used to create nullifiers
2Issuer-defined fieldCan be used for anything the issuer wants
3Issuer-defined fieldCan be used for anything the issuer wants
4iatUnix timestamp in seconds when the credential was issued at
5ScopeDefault to 0 (wildcard) indicating it can be used anywhere. This field is mostly deprecated and is not used anywhere.

Note that while credentials can only have 2 issuer-defined fields, nothing prevents these fields from representing more: they can be set to the hash of unlimited custom fields.

Nullifier Secret

The nullifier secret is a value that only the user knows. Because it is pseudorandom, the preimage of the leaf cannot be guessed without at least brute-forcing the secret, which is infeasible at 16 bytes. Thus, even if the other fields are predictable, the credential will still be anonymous without knowing the secret. In this way, it acts as a pepper, obscuring the preimage from the publicly known digest.

It also has a particular property allowing for sybil resistance: credentials can be spent for a specific use case by publishing a salted hash of the secret pepper. This is referred to as a “hashbrown” because it is a mixture of salt & pepper. Accurate computation of the hashbrown can be verified in a ZKP without revealing the pepper. Some use cases involve anonymous reputation, anonymous voting, bot prevention, and fair airdrops. For example:

Whenever a user votes in an election with actionID abc123, they must publish hash(abc123, secret). And they generate a proof that the result came from abc123 and secret. This hash then gets added on-chain, so the user can never vote again without people seeing they’re trying to “double-spend” their secret.

Leaf Formats of Human Tech Issuers

Human Tech provides two issuers, though others are encouraged to create more issuers.

Government ID Issuer

IndexNameDescription
0Issuer AddressThe Ethereum address of the credential issuer, i.e. who provided this attestation
1Nullifier SecretA secret used to create nullifiers
2CountryThis is a number corresponding to the user’s country. Countries are numbered based on a custom accumulator scheme. This allows them to be used in efficient ZK arguments of presence in allowlists of countries.
3Additional InfoPoseidon hash of: Name, city, state/province, street, zipcode
4Time of credential issuanceRepresented as seconds since 1900 (unix timestamp with -70yr offset)
5Scope0

Phone Issuer

IndexNameDescription
0Issuer AddressThe Ethereum address of the credential issuer, i.e. who provided this attestation
1Nullifier SecretA secret used to create nullifiers
2Phone NumberPhone number in E.164 but without the leading + so it can be converted to a field element. E.g., +15555555555 becomes 15555555555
3Empty0
4iatDay the credential was issued at, in days since 1900/01/01
5Scope0

Biometrics Issuer

IndexNameDescription
0Issuer AddressThe Ethereum address of the credential issuer, i.e. who provided this attestation
1Nullifier SecretA secret used to create nullifiers
2Group Name1 (this maybe incremented)
3Reference HashHash of the reference id
4iatDay the credential was issued at, in days since 1900/01/01
5Scope0
Last updated on