By What Authority?
The authority your persona holds is part of the question. Every authorization standard asks four things: subject, action, resource, context. The same engineer, the same credential, and the same push got opposite answers minutes apart, because the answer depended on a question the standards do not ask. That is not a field. The record proves it.
The second question of delegation legitimacy, proven on camera: was the act in scope. The same engineer with the same credential is refused at New York Office and allowed at Engineering minutes apart, and IdentityRM names the position in its own sentence each time. The assistant switched positions on its own; the events API shows the whole bracket. Plus the two tiers of answer, what is sealed and what is only recorded, and why we speak the standards shape without claiming conformance.
"Subject, action, resource, context. Every standard asks four things. The answer depended on a fifth: by what authority. That is not a field. The record proves it."
— Martin Gee, Founder & CEO, IdentityRM
The second post in this series proved one of the four questions of legitimacy on camera: was the grantor entitled to grant. This one proves the second, and it comes from a frame I published without doing it justice. The same engineer, the same credential, the same push, and two opposite answers minutes apart. The only thing that changed was where the engineer was standing.
Four fields, and a fifth
Every authorization standard in use asks the same four things. Who is the subject. What action. On what resource. In what context. That is the shape AuthZEN expects, and it is the shape its relatives have used for a long time. It is also the shape IdentityRM answers in. But there is a fifth question the standards do not ask, because in a flat identity model it has no answer: by what authority?
That is not a field. You can put a node id in a context attribute, and every standard lets you, but that is a coordinate, and nothing in the standard computes anything from it. Authority is the thing the other four are supposed to be about, and the word carries more than I am going to unpack here: who delegated it, whether they could, how far it reaches, how long it lasts, and the fact that the model deciding all of that is itself governed. The visible tip of it is the persona the subject is acting as, and what that persona holds.
Here is what happens when the same four fields arrive at IdentityRM. The answer is not a lookup against a policy. The authority behind the act is computed from what the persona holds, where it holds it, and from whom, against the organization as it is at that moment, and the answer comes back naming the node it was computed at. Move the subject and the authority changes, so the answer changes, and the record says where it was decided. What goes into that computation is ours. What comes out of it is on the record.
In our model the Release Engineer holds two positions: a home position at New York Office and an assignment at Engineering. The Release Pusher role was granted at Engineering, by someone who owned it there. At New York Office the engineer holds nothing. Same person. Different position. Different authority. The standards’ four fields are identical for both requests. The answer is not, and the record names the difference.
Six: the same push, from the other position
The engineer was at Engineering with the role held, having just pushed with no prompt. I asked the assistant to move.
Permission denied for git.push on dev_tooling at New York Office
Nothing about the person changed. The credential is the same bearer the hook has used all along. What changed is the node the session acts from, and the sentence that came back says so in its last four words. A session can only move to a node where the person holds a membership, and IdentityRM checks that on the server at every switch; the engineer could go to New York Office because the engineer belongs there. That sentence is IdentityRM’s, not the hook’s and not Claude’s; the hook forwards it and adds nothing.
The refusal left a record, the same way the first one did. Here it is, with the node it was evaluated at. A note on provenance: the demo environment was reset on 3 October, so every frame and record in this post is from one session on 4 October, with the same prompts as in September, word for word. The grant was made again the same way, and the ids in this post resolve today. The one exception is the assistant’s explanation quoted below, which it gave in September.
What the record shows without anyone’s narration
This is the part I under-told last time. I moved the session to New York Office and asked for the push; refused. I moved it back to Engineering and asked again; allowed. In between, the assistant explained the mechanism to me, unprompted, and got it right:
Every word of that is correct, and I would not take the assistant’s word for it. The audit trail confirms it independently. Two persona-change events, a denial between them and an allow after the second, four records in a row on the audit list. The list does not show the verdicts; the two cards do. A scoped caller asking the events API for the same window gets back the rows inside her own authority and not the New York Office ones, which is containment doing its job, and why the four-row view is the administrator’s.
I want to be exact about what that proves. It proves the other route was closed. The engineer’s authority to push exists at Engineering and nowhere else, so moving to New York Office bought nothing, and the record shows the move, the attempt and the refusal without relying on anyone’s narration, mine included. It does not prove that the assistant would have declined to take that route on its own if it had been open. In the September session it did reach for another position after a refusal, and the control held because the engineer held the role at neither node at that time. That is a different claim from the one these frames make, and I am not making it here. The control held because the model was right, not because the agent was well behaved.
Back where the role lives
Permission granted for git.push on dev_tooling at Engineering
Pushed. No prompt. Nothing pre-approved, nothing cached; the hook asks on every call (the hook is in the earlier post) and the answer tracked the position. If you only had the four standard fields, these two requests are indistinguishable. The record knows they were not.
Two tiers of answer
For the builders reading, here is what is actually happening underneath, because there are two different kinds of answer in this post and they should not be confused.
The hook asks an access evaluation. Does this operator hold this permission on this resource, from the position they are operating in, right now. It is the narrow question, in the shape a policy-decision standard expects, answered for the persona the operator is acting as. It names the node it evaluated, and every answer is recorded as an event, allow or deny. Every push in this series, allowed or refused, is this tier. It is what a hook, a gateway, or a runtime asks forty times an hour.
An authority evaluation is the wider question: by what authority may this act happen, with the receipt and its fingerprint, and, when the act is one IdentityRM executes itself, the seal. The grant in the second post was that tier. It is what an auditor asks afterward. The two tiers share one authority model, and they are never confused for each other: a check never produces a seal, and a sealed act is never just a check.
The hook’s question about git.push is an access evaluation and stays one; is_authorized binds to operations IdentityRM governs itself, and I am not going to dress one up as the other. The grant is the second tier, and here is its record, on the same dashboard, the morning the engineer’s authority was made again.
Read it top to bottom and it is the fifth question answered in the product’s own layout. Decided for: who, acting as which persona, where, for whom. By what authority: the two sources that conferred it, each with the node that governs it, the same two sources the September grant carried. What had to clear: the factors, each one named, each one passed. Then the proof, last, like a signature line: the boundary fingerprint, sha256:cbbb6decb1024bad9c6df92f07093f69ea2fb7b64c40ab78a59d67c15487b94c, over everything above it, with the position Jordan asked from inside it; and the seal, sha256:107b9048a44873261732f9cb463cd09b224e0500ea508e25650cf051676321cd, over the fingerprint, the event type and the deciding factor. The card says what the seal is and is not in one sentence, and I will not improve on it: a deterministic hash under the recorded contract, not a signature. The seal identifies the authority decision, not the occurrence; the event id does that. Made again under the same authority, the grant produces the same fingerprint and the same seal, which is what a fingerprint of the authority should do. A receipt is not a token; it changes nothing downstream and reserves nothing. It is the authority, computed and fingerprinted, so that when the act runs, the seal carries the same fingerprint and binds the act to the authority that answered it. Position is not a coordinate we store. It is part of the authority, and the authority is what gets recorded and, when IdentityRM acts, sealed.
We speak the standards’ shape on purpose. Any relying party that already sends subject, action, resource, and context can send it to us and get an answer back in the form it expects. We do not claim conformance to any of them, because the thing that makes the answer right is the question they do not ask.
The Blueprint Alliance’s third principle is “keeping delegation traceable.” Traceable tells you each hop happened. It does not tell you by what authority the hop was made, and position is the first thing it does not carry. That is the whole of what I have to say about it this week.
Two down, two to go
Was the grantor entitled to grant: last week, on camera. Was the act in scope: this week, on camera, from both sides of the line. Two questions remain before every link of a chain can be called legitimate rather than merely traceable. Was the grant alive, and is the accountability chain intact. The seven-day grant behind the September frames expired on the twenty-fifth. The one behind this week’s records expires on the eleventh. You can guess what the next post shows.
IdentityRM is the system of record for authority: who may do what, where, until when, granted by whom, consulted at the moment of decision. Start with Then I Told It Who to Ask Instead for the grant, Traceable Is Not Legitimate for the argument, or the platform.
