Proving you are a unique human does not authorise a payment

Uniqueness and authorisation are different properties, and a system optimised for the first does not incidentally provide the second. The gap is not a maturity issue; it is what each was built for.

Part of Category comparisons

Two different questions

Each row is a legitimate requirement and they do not substitute. A system that answers the first tells you nothing about the third, and an enterprise wire transfer is entirely a third-row problem.

Where personhood genuinely matters

Worth stating clearly, because the criticism below is about fit rather than value.

• One-person-one-vote governance, where duplicate accounts break the mechanism
• Distribution of a limited resource where a person should receive one share
• Reputation systems vulnerable to sock puppets
• Any context where the harm comes from a single actor appearing as many

In each of those, uniqueness is the property that matters and identity may be irrelevant. That is a real problem with few good solutions.

Why it does not extend to enterprise actions

An enterprise does not have a sybil problem. It knows exactly who its employees are, having hired them, and duplicates are not the threat.

Its threats are the opposite shape: a known identity being used by someone else, or a known person approving something they did not understand. Neither is addressed by establishing that a person is distinct from other people.

The biometric liability

Beyond fit, there is a deployment obstacle that enterprises cannot easily accept.

The revocability row is the one that should end the discussion for any security architect. A credential that cannot be revoked and replaced is a liability that compounds over time.

Where they could compose

There is a coherent architecture in which both appear, and it is worth describing because the two are not adversaries.

# Personhood layer  — where uniqueness matters
  establishes: this is a distinct human, one account
  use: consumer platforms, governance, resource allocation

# Authorisation layer — where acts matter
  establishes: this human approved this specific act
  use: enterprise workflows, payments, permissions

# A consumer platform might use both:
#   personhood to prevent duplicate accounts
#   authorisation to gate consequential actions on those accounts

The error is treating them as competing answers to one question. They are answers to different questions that happen to share the word human.

The test for which you need

Ask what the failure looks like.

• If the failure is one actor appearing as thousands, you have a personhood problem
• If the failure is an action taken that nobody intended, you have an authorisation problem
• If the failure is someone accessing an account that is not theirs, you have an authentication problem

Most enterprise losses are in the second category, which is why personhood systems have found limited enterprise traction despite considerable investment. It is not a go-to-market problem; the product answers a question enterprises were not asking.

Where personhood genuinely earns its place

This is a fit argument, not a quality one. Sybil resistance is a hard problem with few good answers, and systems that attack it are doing real work.

Most enterprise loss is the third row. That is why personhood systems have found limited enterprise traction despite considerable investment: it is not a go-to-market problem, it is a product answering a question enterprises were not asking.

Objections and honest limits

“The biometric objection is overstated.” The revocability point is not. A compromised iris cannot be reissued. A platform credential is deregistered and re-enrolled in a minute. For anything an organisation must hold for years, that difference compounds.

“Consumer platforms need both.” Agreed, and they can have both: personhood to prevent duplicate accounts, action authorisation to gate consequential operations on those accounts. The error is treating them as competing answers to one question.

What action authorisation does not give you: any assurance that one human is not operating fifty accounts. If that is your loss, personhood is the right tool and this is not.

Choosing between them

1. Describe the loss in one sentence. If the sentence contains “the same person, many times” you need uniqueness. If it contains “nobody meant to” you need authorisation.
2. Count the enrolment population. Enterprises enrol people they have already hired. That removes the problem personhood solves.
3. Check revocability. Ask what happens when the credential is compromised. If the answer is “nothing can be done”, that is a liability you keep.
4. Check the legal posture. Centralised biometric enrolment carries statutory exposure in several jurisdictions that device-local verification does not.

Terms used here

Sybil resistance

Preventing one actor from presenting as many distinct participants. Matters for voting, resource allocation and reputation; rarely matters inside an employer.

Proof of personhood

Establishing that an account corresponds to a distinct human being, typically once, often through a biometric enrolment.

Revocability

Whether a compromised credential can be replaced. Keys can be; irises cannot.

Frequently asked questions

Is proof of personhood useless? No. It addresses sybil resistance, which matters for governance, resource allocation and reputation systems. That is a real problem with few good solutions.

Why doesn't it fit enterprise workflows? Enterprises know who their employees are and do not have a duplicate-account problem. Their threats are impersonation and uninformed approval, which uniqueness does not address.

What is the biggest deployment obstacle? Irrevocability. A biometric credential that is compromised cannot be reissued, which is a liability that compounds. Platform authenticators can be deregistered and re-enrolled.

Can both be used together? Yes. Personhood to prevent duplicate accounts, authorisation to gate consequential actions on those accounts. They answer different questions.

Is proof of personhood useless for enterprises? It addresses sybil resistance, which enterprises rarely have. They know who they hired. Their losses come from impersonation and uninformed approval, which uniqueness does not touch.

Can the two be combined? Yes. Personhood to prevent duplicate accounts on a consumer platform, action authorisation to gate the consequential operations performed on them.

Sources and further reading

• Uniform Electronic Transactions Act (ULC)
• Illinois Biometric Information Privacy Act, 740 ILCS 14 (Justia)
• W3C Web Authentication: An API for accessing Public Key Credentials Level 3
• Published research — proof of personhood and sybil resistance