What identity does not establish

Identity answers one question: who acted. Every sentence below is a question it does not answer, and each one is here because reading it the other way is a mistake with a cost attached.

It establishes no authority

⛔ A proof of identity carries no grant of authority over this product's data, and no administrator of the authorization server can put one into it. That server authenticates people; it does not decide what anybody may do. Permissions live with the thing that owns them.

⇒ Anybody reasoning about blast radius should reason about the thing being reached, not about the proof presented to it. A proof that is valid everywhere it is accepted is still a proof, and only that.

A registration establishes a name, never an entitlement

⛔ A program that registers itself gets an identity and nothing more. It may ask only for the two things the authorization server acts on itself — knowing who signed in, and keeping the delegation refreshable. Anything belonging to another service is refused, and the refusal names the human act that would grant it instead.

That is a decision rather than an oversight. The authorization server will not issue authority over a resource it does not control and cannot check, so letting a program reach this product's data stays a deliberate act by a person who can see that the program exists.

⚠ It costs less than it looks like it costs. A registration identifies the application, not each installation of it, so a handful of registrations covers a deployment of any size.

It establishes nothing retroactively

⛔ A token already in a program's hands cannot be withdrawn. Not by revoking a person, not by replacing a password, not by withdrawing an approval, not by a hand-written statement against the database, not by anything.

Every act of revocation in this section stops the next proof. None of them reaches the last one. The window is that token's own remaining life — at most ten minutes.

⇒ So the honest sentence about any cut-off is two clauses, not one: cut off at the moment of the act, with any token already issued expiring within ten minutes. How a person signs in says it about revoking a person, What a token carries says it about withdrawing an approval, and it is the same sentence for the same reason.

A trusted issuer is not a trusted person

⛔ Enrolling one is not enrolling the other, and neither implies the other. An issuer record says which server may mint proofs this installation honours. A person nobody enrolled is refused even when their issuer is perfectly trusted, and the two refusals do not look alike — see What an actor is.

⚠ And pointing clients at an authorization server is a third thing again, deliberately separate from trusting it: advertising a server must never by itself grant it the power to mint proofs this product honours.

Signing in is not agreeing

⛔ "Somebody signed in" and "somebody agreed to this program" are not the same fact, and reading the first as the second is what the approval page exists to prevent. A signed-in person who clicks one link has not thereby agreed to anything a stranger registered.

⚠ Withdrawing an agreement is also not signing out. A withdrawal ends what a program holds; it leaves the person's own session exactly where it was, and anyone holding that session can approve the same program again a minute later. Change the password first if that is the situation you are in.

A live credential is not a working seat

⛔ A seat can hold a perfectly good credential and still be unable to do any work, because what refuses it is not its identity. There is more than one reason a piece of work does not start, and only some of them are identity.

⇒ Read a credential reading as an answer about the credential, and nothing wider. A seat's credential to its AI provider sets out the neighbouring failure that is confused with it most often — a spent usage allowance, which is cured by waiting and by nothing else.

An absence of measurement is not a clean bill

⛔ Where nothing has been measured, the product reports the absence as itself rather than as health, and you should read it the same way.

• a seat no work has ever finished on reads as never measured, not as fine;
• a reading that could not be taken reads as nobody looked, not as nothing found;
• where the product has not driven a provider's login flow end to end, it says so above the line it hands you rather than implying that it knows.

⚠ Recording that a human performed a login is a report, not a proof. The record says a named person says they did it. It never says the credential is good, and the next real piece of work is what confirms that.

It replaces no identity provider you already run

The supported shape is to have this product honour proofs from an authorization server, and that server may be this product's own or one you already operate — the ceremony in Trusting an issuer is the same one either way, and only the algorithm and the key address differ.

⚠ What is not on offer is a general path into whatever directory you already have. If you are planning a move that assumes user records will be synchronised out of an existing directory and into this product, check that assumption against Trusting an issuer before you plan around it, and note that enrolling each person is a separate act from trusting their issuer however that issuer is run. The size of that per-person act is what such a plan needs to budget for, and it is not something this section can currently size for you.