Identity AVAILABLE
An Ed25519 keypair and a did:key. Verifiable by anyone, registered nowhere.
What it is
- An identity names a party: an issuer, a subject, an approver. It is a keypair, and its public half is a `did:key` that carries the key inside it.
Why it exists
- A directory lookup is a dependency and a chokepoint. A `did:key` can be verified by somebody holding nothing but the DID and the document — offline, on a plane, years later.
How it works
- `bengar id create --name acme` generates the pair and stores the private half locally.
- The DID goes into permits as the issuer or the audience.
- Verification resolves the key from the DID itself.
Who uses it
- Organizations issuing permits
- Agents receiving them
- Anybody verifying either
Security boundary
- Trust identities are Ed25519. Chain accounts are secp256k1. Neither is derived from the other.
- A passkey is not an identity: it authenticates a person for a step-up and signs nothing the protocol reads.
Example flow
Two identities and a permit
- `bengar id create --name acme` — the issuer.
- `bengar id create --name agent` — the subject.
- `bengar permit issue --issuer acme --audience <agent did> …`
- `bengar permit verify permit.txt` — offline, no service.