A store mints each reporting job its own downstream account at start-up — what must that downstream system expose for this to work?
answer
- the far side has to cooperate
- not one operation but three
- create, grant, remove
- rights narrow enough to be worth it
- the store needs a privileged identity there
basics
~20 sThe downstream system must let the store create a principal on demand, attach exactly that consumer's rights to it, and remove it again — and must accept an identity for the store privileged enough to do all three.
solid answer
~40 sGenerating a credential is not something the store does alone. On every request it reaches into the downstream system and performs three operations there: **create** a principal with a name and value the store chooses, **grant** it precisely the rights this consumer needs and no more, and later **remove** it. A system whose accounts are created by a human filling in a request, or whose only attachable rights are all-or-nothing, cannot back generated credentials however good the store is. All three operations run as an identity the store holds in that system, so the far side must also be willing to give the store one — which is the cost that comes with the design, not a detail of it.
code
pseudocode · 16 lineson request from consumer C for dataset D:
require store.rules.allow(C, D)
name = 'job-' + C.id + '-' + requestId
value = randomValue()
downstream.createPrincipal(name, value) # 1: create
downstream.grantRights(name, ['read ' + D]) # 2: grant exactly this consumer's rights
store.recordIssued({ name: name, consumer: C.id, dataset: D, createdAt: now })
return { name: name, value: value }
when this issuance ends:
ok = downstream.dropPrincipal(name) # 3: remove
if not ok:
alert('principal ' + name + ' outlived its issuance')go deeper
Recall the shape: the store does not invent the account, it asks the system that holds the data to make one, and hands you its name and value.
Be able to name the three operations the far side must expose — create a principal, attach exactly this consumer's rights, remove it — and say what each one is worth without the other two.
Show that you check the far side before promising the design: whether removal is programmatic, how narrow attachable rights can be, and what the creation write costs when a fleet restarts together.
Frame it as a capability standard for the estate: which downstream systems qualify, what minting identity you are prepared to hold in each, and where a shared credential is the honest answer.
## What "minted on request" asks of the far side A store that **generates** a credential does not hand back a value somebody typed into it once. When a consumer asks, the store reaches into the **downstream system** — the reporting warehouse, the message broker, the object store, whatever actually holds the data — creates a **new principal there**, attaches exactly the rights that consumer is entitled to, hands back the new name and value, and later removes it. None of that is local to the store. Every step is an operation the far side performs on demand, for a caller it authenticates as the store. So the first question about per-consumer credentials is never "does our store support it". It is: **can the downstream system do this at all, fast enough, with rights narrow enough to be worth it?** ## The three operations the downstream must expose 1. **Create a principal.** The system must bring a new identity into existence programmatically, with a name the store chooses and a value the store can read back exactly once. Where accounts are created by a person filling in a request, or arrive from a nightly synchronisation someone else owns, there is nothing for the store to call and the design stops here. 2. **Grant exactly this consumer's rights.** Creation on its own is close to worthless. If the only rights the system can attach are "everything" or "nothing", each minted account is as powerful as the shared one it replaced, and the smaller blast radius — the entire argument for generating — is quietly lost. The store must be able to express a narrow set of rights per consumer and have the system attach them at creation time. 3. **Remove it.** The system must accept a removal that the store can perform without a human. Without it the estate accumulates principals it can create and cannot end, which is a worse position than one shared credential, because now nobody knows how many exist. ## The identity the store must hold there All three operations run as an identity the store holds in the downstream system, and its properties decide most of what follows: - It is a **standing** identity: it exists between requests, not only during one. - On most systems, creating principals and attaching rights is an **administrative** capability, so this identity outranks everything it hands out. - Where the system enforces that a grantor may hand out only rights it holds itself, that identity is a **ceiling** — the store cannot mint a consumer more powerful than itself, and you can lower the ceiling deliberately. Where the system does not enforce it, no such ceiling exists and the only limit is what the store's own rules ask for. Systems genuinely differ here; check before assuming. - It is normally a **different identity per downstream system**, so a problem in one does not carry into the next. ## Where a system passes and where it fails | What the downstream can do | Verdict | What you actually get | |---|---|---| | Create a principal by an API call | passes | per-consumer issuance is possible | | Accounts created only by a human request | fails | one shared value, replaced by hand | | Attach narrow rights per principal at creation | passes | real per-consumer scoping | | One permission set for every account | weak pass | attribution, but no smaller blast radius | | Remove a principal programmatically | passes | access that can actually end | | No removal the store can perform | fails | access accumulates that you cannot end | ## What the design buys, and what it costs What it buys is concrete: there is no long-lived shared value sitting in several places waiting to leak, the value each consumer holds opens only that consumer's slice, and a value found somewhere it should not be names the consumer it was issued to. What it costs is equally concrete, and the three operations are where the cost lands: - The store becomes a **participant in the downstream system's identity management**, not merely a holder of values. - The store holds a **privileged identity** in every system it mints for. - Each consumer start-up now causes a **write** on the far side, which is a different and usually far more expensive operation than the reads that system is sized for. - The **population of principals** becomes a live quantity with a size, and something has to watch it. Whether a particular value should be generated rather than static at all is a separate decision with its own argument. This question is narrower and comes first: whether the far side is capable of it.
- What position are you in if the downstream system can create a principal but has no removal the store can call?You are worse off than with one shared credential. Every consumer start-up adds a principal nobody can end without a human, the population grows monotonically, and the system's own account limit is eventually reached by leftovers rather than by load. Either arrange removal, or keep a shared credential there and be honest about why.
- Some downstream systems let a grantor hand out only rights it already holds. What does that give you?A ceiling. The store cannot mint a consumer more powerful than the identity it holds there, so you can deliberately hold a weak minting identity and bound every account it will ever create. Where the system does not enforce that rule, no ceiling exists and the narrowness of each account depends entirely on the store's own rules being right.
- Why does creating an account per consumer put load on the downstream system that reading never did?Creation is a write against the system's own identity records, and on many systems those writes are serialised and far more expensive than a data read. A fleet that restarts together turns a read-shaped workload into a burst of writes on a path that was never sized for it.
saying these in an interview costs you the question
- Thinks the store invents the downstream account entirely by itself
- Assumes any system can have accounts created on demand
- Treats creation as enough, with no removal path at all
- Gives every minted account the shared credential's full rights
- Believes the store needs no privileged identity downstream