Who is who: registrant, principal, admin, controller
Five words for what a reader counts as two or three people. The definitions are in the glossary and in §0 and §4 of the specification; this page walks one case.
The case
Northwind Ltd. wants an agent that files purchase orders with its suppliers. Ana works in procurement and opens the account. Ben, an engineer, runs the agent on a server and manages it day to day. The agent is ordering-agent.
- Registrant — Ana. The human who opened the account and accepted the terms. One per account. Recorded by the registry, not in the AID.
- Principal — Northwind Ltd. The entity the agent acts for. Appears in the AID as
credentialSubject.principalwith its DID (did:aria:…:org),legalName,jurisdictionandverificationStatus. At L0 that name is what Ana typed. - Account Admin — Ben. Manages agents in the portal; may differ from the registrant. The DNS analogy: registrant contact versus admin contact.
- Controller — Ben, acting for Northwind. Whoever holds the agent's holder key and can publish the anchor TXT. The party that performs the
did:ariaoperations in §3. - Holder key —
ordering-agent's Ed25519 keypair. Generated by Ben on his machine. Its public half is in the AID (holderKey); its private half never left the server. It is the key that will answer receiver challenges under ATP.
The list above is prose about one case, not a schema. The field-by-field reading of a real AID is Reading an AID.
Two keys, two owners
The AID carries two signatures from two parties. The proof is the registry's: it says "we issued this". The holderKey is the agent's: it is what the agent will sign with when it declares intent or answers a challenge. Confusing them is the most common misreading: a valid proof says nothing about who is talking to you now.
What the registry knows that the AID does not say
Ana's identity documents, Ben's e-mail, Northwind's billing details — all of that is in the registry's Case File, none of it in the public AID. Where each piece lives is Who holds what.