[DO NOT DO YET] Evaluate World ID for human verification and agent authorization #958

DO NOT DO YET: This issue records an idea for future discussion. Do not start implementation until the project maintainers decide to proceed.

Background

Semaprax is intended to support collaboration between humans and AI agents. For some actions, it may be useful to establish whether a verified human is involved—for example, when approving sensitive operations or limiting automated abuse.

World ID provides a cryptographic proof that can be used to verify a person’s humanity after they have completed verification with an Orb. We should investigate whether this could be useful in Semaprax and how it would fit into the project’s identity and authorization model.

Important distinction

A valid proof of humanity does not by itself establish that every subsequent action is performed directly by a human. An agent could act on a human’s behalf, or gain access to a human’s session.

The design should therefore distinguish between:

• Verified human: A valid proof of humanity has been checked for the intended context.
• Agent: A software actor with its own identity and permissions.
• Human-authorized agent: An agent acting under explicit, limited authorization from a human.
• Unknown actor: No sufficient proof is available. This does not mean the actor is necessarily an agent.

Investigation

When this issue is taken up, investigate:

• Which Semaprax use cases, if any, require proof of humanity.
• Whether World ID can be integrated as an optional verification provider.
• How proofs would be verified and bound to the intended action or session.
• How agent identities, delegated permissions, and human approvals should interact.
• Threats such as proof replay, session compromise, credential sharing, unauthorized delegation, and provider outages.
• Privacy, data retention, accessibility, regional availability, and alternatives for users without World ID.
• Legal and regulatory considerations for the intended deployment regions.
• Implementation effort, external dependencies, and whether blockchain interaction is necessary for the selected approach.

Acceptance criteria

• An architecture proposal describes the verification flow and its trust boundaries.
• The proposed identity model distinguishes humans, agents, authorized agents, and unknown actors.
• The proposal explains how proofs are bound to their intended context and how unauthorized reuse is prevented.
• Failed, cancelled, and unavailable verification flows are covered.
• The proposal documents what data Semaprax would receive and retain. Semaprax should not collect iris or face images itself.
• A threat model, privacy assessment, and assessment of alternatives are documented.
• A small proof of concept—or a reasoned decision not to build one—documents technical feasibility.
• The investigation concludes with a recommendation to integrate, investigate further, or reject the approach, including any prerequisites and follow-up issues.

Open questions

1. Which specific actions should require proof of humanity?
2. Should it be mandatory for those actions, or one of several available verification methods?
3. Which permissions can a human delegate to an agent, and when should a fresh human approval be required?

Related issues

• [P1] Add authentication, sessions, password hashing, tokens, and capability-controlled secrets #191 — Authentication, sessions, and capability-controlled secrets.
• [P1] Build a typed workflow profile with model routing, human gates, retries, compensation, and checkpoints #208 — Typed workflows and human gates.

These issues cover related authentication and approval concerns; their closure does not by itself establish the current implementation scope.