A platform-signed identity document arrives at the store from a workload holding no stored secret — what does the store verify before releasing a value?
answer
- a claim to verify, not compare
- who signed it, and for whom
- four fields, all four must pass
- recipient name blocks cross-store replay
- freshness plus a small drift allowance
basics
~20 sFour things: that the signature comes from an issuer it already trusts, that the document names this store as its recipient, that its subject is a workload the store has a rule for, and that it was minted recently.
solid answer
~50 sThe document is a short-lived assertion the platform signs on the workload's behalf, and the store treats it as a claim to **verify**, not as a secret to compare against a stored copy. Four checks: the **signature** must verify against the keys the named issuer publishes, and that issuer must be one the store was configured to trust; the **intended recipient** must name this store, so a document minted to be shown somewhere else is refused; the **subject** must be a workload identity the store holds a rule for; and the **freshness** fields must put the document inside its narrow window, with a small allowance for clock drift in both directions. The signature check gates the rest — until it passes, every other field is attacker-controlled text. Passing all four establishes *who is calling*; what that caller may read is a separate decision the store makes afterwards.
code
json · 9 lines{
"signedBy": "platform-identity-issuer",
"keyId": "k-7",
"intendedFor": "secret-store",
"workload": "search-api/production",
"issuedAt": "2026-09-19T09:14:02Z",
"notAfter": "2026-09-19T09:19:02Z",
"signature": "<opaque bytes over every field above>"
}go deeper
Recall that the workload holds no password here: it shows a short-lived document the platform signed, and the store checks that document rather than matching a stored value.
Be able to name all four checks and say why each exists — issuer and signature, intended recipient, subject, freshness — and explain why the signature check has to pass before any other field is read.
Show that you operate this: a small measured drift allowance rather than a generous one, fail closed on verification failure, a fresh document per fetch, and logging that records the subject and the outcome instead of the document.
The interesting trade-off is where verification strictness belongs across an estate — a shared, well-tested verification path against per-store configuration each team writes, and what it costs when one team's store quietly trusts one issuer too many.
## What the workload actually presents A **platform-attested identity** replaces the stored credential with a document the platform mints on demand. The workload keeps nothing durable: at start-up, and ideally again before every fetch, it asks the platform it runs on for a short-lived identity document, and the platform signs one describing the workload it believes is asking. The store never compares that document against a stored copy of anything — it verifies it. That is the whole gain: there is no shared value sitting in the workload for anyone to take. Whatever the platform, the document carries the same small set of things: - **who signed it** — the issuer, named so the store can find the right published key; - **who it is for** — the intended recipient, naming this store rather than some other service; - **who it is about** — the subject, a workload identity the store can write a rule against; - **when it was minted, and when it stops being acceptable** — the freshness fields; - **the signature itself**, covering all of the above. ## The four checks, in order 1. **Issuer and signature.** Look up the issuer named in the document. It must be one this store was configured to trust; an unknown issuer is refused before any other field is read. Then verify the signature using the keys that issuer publishes. This check gates the other three: until it passes, everything inside the document is text the caller controls. 2. **Intended recipient.** The document must name this store. A document is a bearer artifact — whoever holds it can present it — so without this check, any service that was legitimately shown a document for this workload could turn round and present it here as that workload. 3. **Subject.** The subject must be an identity the store holds a rule for. A perfectly valid document naming a workload the store knows nothing about is a failed authentication, not an empty authorization. 4. **Freshness.** The document must sit inside its validity window, allowing a small drift in both directions: not already expired, and not minted implausibly far in the future. All four must pass. A verified signature on its own establishes only that the platform minted *a* document for *some* workload, which is equally true of every document in the estate. ## What each check is worth | Check | What it establishes | What it stops | |---|---|---| | Issuer and signature | The document came from a platform this store trusts | A document the caller minted itself, or one from an unrelated trust domain | | Intended recipient | The document was minted to be shown here | Another recipient replaying a document it was legitimately given | | Subject | Which workload identity is calling | An unknown identity quietly matching a broad rule | | Freshness | The document was minted recently | An old copy still working long after it escaped | ## Clock drift, and why the allowance stays small Issuer and store clocks drift, so a document can arrive looking a few seconds expired or a few seconds premature. Stores therefore apply a small allowance in both directions. That allowance is not a tuning knob: it extends the usable life of every document by exactly its own size, so an allowance that is a large fraction of the document's lifetime quietly undoes the short lifetime the whole design was bought for. Platforms set a default lifetime, and it is deliberately short for that reason. Drift is a fault to fix and to alert on, not a number to absorb. ## What passing the check does not decide Proving who is calling and deciding what that caller may read are separate steps, and collapsing them is the common real defect here. Passing all four checks answers exactly one question — *which workload identity is calling, on this request* — and answers it for this request only, which is why the document is presented per call rather than exchanged once and remembered. What that identity may read is a separate rule lookup with its own failure mode: a store that verifies documents rigorously and then matches a broad rule has strong authentication and no least privilege at all. Two further limits are worth stating plainly, because candidates routinely overstate the check: - it says nothing about **what code** is running in the workload, only that the platform placed that workload somewhere and will vouch for it; - it is **not revocable** mid-window — nothing was stored that an operator could delete, so a document that escapes stays good until it ages out. ## Failure handling - **Fail closed.** A document that cannot be verified is refused. A store that falls back to another path on verification failure has made verification optional. - **Unknown signing key.** Refuse, and make it loud — it is a configuration problem at the store, not a caller problem, and silently accepting is the worst available answer. - **Record the decision, not the document.** Log the subject, the outcome and the reason; the document itself is still a usable credential for the rest of its window.
- The signature verifies, but the document names a different store as its intended recipient. Why refuse it?Because the document is a bearer artifact: whoever holds a copy can present it anywhere. The recipient field is what stops the service it was actually minted for — or anything that captured it on the way there — from replaying it here as that workload. Without the check, every place the workload ever authenticated becomes a place that can impersonate it against your store.
- Why does the store need a drift allowance at all, and what bounds how large it should be?Issuer and store clocks are never exactly aligned, so a document can look seconds expired or seconds premature. A small allowance absorbs that. The bound is the document's own lifetime: the allowance adds directly to every document's usable life, so an allowance that is a large fraction of the lifetime cancels the benefit of the short lifetime. Measure the real drift, set the allowance just above it, and treat larger drift as a fault.
- A document passes every check. What has the store established, and what has it not?It has established which workload identity is calling, on this request, at this moment. It has not established what that identity may read — that is a separate rule lookup — and it has not established anything about the code running inside the workload. A store that authenticates strictly and then matches a broad rule has done only half the job.
saying these in an interview costs you the question
- Thinks a valid signature alone is enough to release the value.
- Treats the identity document as a secret to store and reuse.
- Skips the intended-recipient check once the signature verifies.
- Assumes passing the check also settles what the caller may read.
- Accepts any issuer that presents a well-formed document.