Most access systems ask two questions in order: who are you, and what may you do?
Capability security asks whether the first question is necessary.
A ticket lets you enter a theatre without describing your employment history. A key opens a door without presenting a global name. A signed capability can grant one program permission to write one file without granting it an identity recognised everywhere.
The distinction is old. SPKI/SDSI and object-capability researchers argued for authorisation certificates, local names and unforgeable permissions rather than universal identity plus sprawling access-control lists.
Identification creates a surplus
When a service learns who you are, it gains information beyond the immediate decision. The information can be logged, correlated, breached, compelled or reused to personalise a later judgement.
Sometimes identification is necessary. A hospital needs the correct medical record. A court must know which person is before it. But many systems ask for identity because their authorisation model has no smaller language.
The privacy-preserving move is not always a better ID. It may be a better permission:
- over eighteen, not birth date and name;
- licensed to perform this procedure, not a complete professional profile;
- allowed to read this document until Friday, not a permanent organisation account;
- paid member of this library, not a national identifier.
The agent lesson
This becomes urgent with AI agents. An agent may act for several people and services. Giving it a stable identity does not express what it may do now. A scoped, revocable capability can.
Identity answers “which actor is this?” Authority answers “why may it perform this action?” Good systems need both sometimes. They should not use the first as a substitute for the second.