Should credential custody be one model across an operations browser and field tablets, or one model per client type?
answer
- diverge at the edge, converge at the server
- two clients, two threat surfaces
- one model serves one client badly
- count review paths, not code paths
- decide classes, not individual clients
basics
~20 sLet custody diverge at the edge and converge at the server. The two clients face genuinely different threat surfaces, so one model serves one of them badly — but two models are only affordable if the server side stays a single credential format, verification path and revocation story.
solid answer
~50 sA browser page executes code nobody on your team wrote and can hold nothing its own script cannot reach; a shipped application runs only what you built and has a platform key store. Forcing one custody model onto both means choosing which client to serve badly. The real cost of two is not code, it is **review paths**: two threat models, two runbooks, two audits, and findings that get fixed on one client and forgotten on the other. The rule that resolves it is that custody may differ on the last hop only. One credential format, one verification path, one revocation story on the server, and a difference confined to how the client holds and presents what it was given. If a second custody model implies a second server-side authentication path, you have divided the system rather than the client.
go deeper
The takeaway is that a browser and a shipped application are different kinds of client, so the same answer about where a credential rests does not automatically fit both. You are not expected to make this call.
Be able to state why a browser cannot hold something its own script cannot reach, and why a device application can. That asymmetry is what makes the question a real decision rather than a preference.
Apply the test in review: does this custody model force a second server-side authentication path? Converging behind the first hop is what keeps two client models from becoming two systems.
Own the longer horizon — how many client types exist in three years, whether one team reviews both, and whether your review capacity carries two models honestly. Decide custody classes rather than per-client designs, and say out loud what parity you cannot reach.
## The forces The turbine maintenance scheduler has two clients and they are not variations of each other. | | operations-room browser | field tablet application | |---|---|---| | what code runs in it | yours plus dependencies, embeds and anything injected | only what you shipped | | can it hold something script cannot read | no — anything it can send, its script can read | yes, a platform key store | | who is at the keyboard | one named operator at a desk | whoever picked the tablet up this shift | | network | stable, inside the operations network | intermittent, at the base of a tower | | how an incident presents | a compromised page in one browser | a lost or shared device | Every row pushes the custody decision a different way. That is why "standardise for consistency" is not automatically the right instinct here: the thing you would be standardising is the answer to a question whose *inputs* differ. ## The cost of insisting on one model - **Standardise on the browser's constraints** — a server-side component holding the credential and handing out references — and the tablet application carries a stateful hop it never needed, over an intermittent link, for a threat it does not have. It runs only your code. - **Standardise on the device's constraints** — the application holds the credential itself — and the browser holds a credential its own script can read, which means you deliberately chose the wrong loser for the one client that executes foreign code. Either way, one client is being served by a decision made for the other's threat model. That is a real defect, not a stylistic one. ## The cost of running two The cost is almost never the code. It is that everything *around* the code doubles: 1. **Two threat models.** A finding against one is not a finding against the other, and nobody will tell you which one a given report applies to. 2. **Two runbooks.** "The credential leaked" means a different set of actions per client, and the one nobody wrote down is the one that happens at 3 a.m. 3. **Two review paths.** A reviewer reading an endpoint now has to ask which custody model the caller is under before they can say whether a check is missing. 4. **A drift you will not notice.** The classic symptom, a year later, is a fix applied on one client and silently not on the other, discovered by an auditor rather than by you. ## The rule that resolves it **Diverge at the edge, converge at the server.** Custody is a client-side decision about where a credential rests and how it is presented. It may differ per client. What must not differ is anything behind the first hop: one credential format, one verification path, one revocation story, one place where a permission check is made. The test is simple and you can apply it in a design review. *Does this second custody model require a second authentication path on the server?* If it does, you have not given two clients two custody models, you have built two systems that happen to share a database — and the surface on which a check can be missed has doubled. If it does not — if the only difference is that one client is handed a cookie by a component of yours while the other is handed a token it stores itself, and both arrive at the same verification — then two models cost you documentation and nothing structural. ## Decide on classes, not on clients The question does not stay a two-way choice. A kiosk appears in the maintenance shed; a scheduled integration starts calling; someone wants a read-only display in the control room. If custody is decided per client, the third one is where review cost stops being linear. So decide instead on a small set of **custody classes**, each with a written model, and place every new client into one: - **runs foreign code** — a browser surface; assume anything it holds is readable, so hold the long-lived credential elsewhere; - **runs only what you shipped** — a device application; a platform key store, with the at-rest boundary stated honestly; - **unattended** — a kiosk or a display; no human to re-prove anything, so scope narrowly and expect the device to be physically reachable. Three classes cover most fleets for years, and a new client is then a placement decision rather than a design. ## What you cannot fix, and should say so You cannot make a browser as good a custodian as a device platform store. It is not a maturity gap that better engineering closes; it follows from the browser executing code you do not control in the same document as your credential. Say that plainly rather than designing as though parity were achievable, because a plan built on pretended parity fails in the direction nobody is watching. And say what you will measure: a single custody statement per client, reviewed when either client changes, and a standing check that a security finding raised against one has been dispositioned against the other.
- Whichever way you decide, what must stay identical?The server side: one credential format, one verification path, one revocation story, and one place a permission check is made, with the difference confined to the last hop out to the client. The moment two custody models imply two server-side authentication paths, you have doubled the surface on which a check can be missed, which is the exact failure the decision exists to avoid.
- How would you know a year later that running two models was the wrong call?Look for findings fixed on one client and not the other, an incident runbook that only describes one, and review comments asking which model an endpoint is under. Those are the symptoms of a divided threat model rather than a divided client. A shared server path plus a one-page custody statement per client is the cheap counter-measure.
- A third client arrives — an unattended kiosk in the maintenance shed. How does the decision scale?Badly, if custody is decided per client, because the third is where review cost stops being linear. Define a small set of custody classes instead — runs foreign code, runs only what you shipped, unattended — and place each new client in one. A new client then becomes a placement decision with a written model behind it rather than a fresh design.
saying these in an interview costs you the question
- Standardising custody for consistency without naming the two threat surfaces
- Assuming a shipped device application and a browser page face the same risk
- Letting each client bring its own server-side verification path
- Treating two custody models as free because the client code is separate
- Arguing a browser can be made as good a custodian as a device platform