What an actor is
Who can act at all, what has to be true before they can, and what an actor name in the record is worth.
An actor is a person, or a program acting for a person. The product honours no third kind.
That is not a description of the current release's coverage; it is a boundary the authorization server holds on purpose. There is no way to obtain a proof of identity that stands behind nobody — no credential belonging to a program alone, and no way for a program to present a password as if it were a person. Every token the product will honour traces back to a human being who signed in.
The two things that must both be true
An external proof of identity is only worth something when two separate records exist, and neither one implies the other:
| The record | What it says | What it does not say |
|---|---|---|
| the trusted issuer | that this authorization server may mint proofs this installation honours | anything at all about who |
| the enrolled person | that this particular person, named inside a proof, may act here | anything about which server vouched for them |
⇒ A person nobody enrolled is refused even when the server that vouched for them is perfectly trusted, and a perfectly enrolled person is refused when their issuer is not. Both records are written by a human hand, once each, and Trusting an issuer is the ceremony for both.
⚠ The two refusals do not look alike, and telling them apart is most of the diagnosis. An untrusted issuer is refused before the request is really considered at all; a trusted issuer carrying an unenrolled person is refused as a denial of access. If you are looking at the second, the issuer half of the ceremony worked and the person half is missing.
A program is never an actor in its own right
A program gets an identity here, and identity is the whole of what it gets.
- Its registration establishes who it is, never what it may reach. How far a token goes is resolved from the person it belongs to. A program cannot widen that by asking for more; it can only fail to be allowed to ask at all.
- One registration identifies the application, not each installation of it. A console, an interface, a command-line tool and a connector are four registrations whether they run on four machines or four hundred. Per-machine identity is a different thing, established when the machine is admitted.
- A program that registers itself is shown to the person it is asking to act for, and asks them a question before anything is issued. A program that a human registered by hand does not, because a human already vouched for it. That question is the approval page in What a token carries.
The refusal that reads like a success
⚠ A request whose proof is good but which asks for something outside its reach can come back inside a response that otherwise looks successful. The error is in the body of the answer, not in the transport's verdict — that is the shape the surrounding protocol requires. A client that inspects only the transport will read that refusal as a success and carry on.
Say this to whoever writes a client against this product. It is the one refusal on this subject that will not announce itself.
What an actor name in the record is worth
Exactly as much as the enrolment behind it.
When the product records that a decision was made by a named person, that name got there because somebody enrolled that person by hand, against an issuer somebody else trusted by hand. There is no automatic path by which a name arrives in the record — which is what makes the name worth reading, and also what makes the ceremony worth performing carefully. An audit trail is a projection of those two human acts. If you are relying on the actor names in the record, Trusting an issuer is the page that says how they came to be there, and what identity does not establish is the page that says what they still do not tell you.