skip to content

A new machine is handed a single-redemption enrolment token valid for ten minutes, so what does single redemption actually detect?

level: middleimportance: should knowfreq 40%

answer

  1. prevention is not what it buys
  2. exactly one presentation succeeds
  3. the loser's failure is the alarm
  4. only if rejections are investigated
  5. first presenter wins, whoever that is

basics

~20 s

Single redemption does not prevent theft; it makes theft of a copy observable. Exactly one presentation can succeed, so either the thief's copy is already dead or the legitimate enrolment fails — and that failure is the only evidence anyone gets.

solid answer

~40 s

The property is that exactly one presentation wins. Two things follow. If the intended machine redeems first, any copy taken in transit is already worthless. If a thief redeems first, the machine's provisioning fails at a moment when someone is watching a build, and that failed redemption is the alarm. So the control converts a silent copy into a loud collision. It buys nothing if a failed redemption is quietly retried with a freshly issued value, which is the usual way teams throw the signal away. And it does not authenticate who redeemed — the first presenter wins, whoever they are — so the short window and the care taken over the handover channel are separate controls doing separate jobs.

code

pseudocode · 17 lines
pseudocode
redeem(presentedValue, callerSource):
    record = enrolments.lookup(fingerprint(presentedValue))

    if record is absent:
        return REJECT_UNKNOWN
    if record.redeemedAt is set:
        return REJECT_ALREADY_REDEEMED      # a second presenter always loses
    if now > record.expiresAt:
        return REJECT_EXPIRED

    record.redeemedAt   = now
    record.redeemedFrom = callerSource

    if callerSource != record.expectedFrom:
        raise_for_review(record)            # odd, though a source can be claimed

    return issueIdentity(record.grantedTo)

go deeper

for a junior

Know the property first: the store accepts that value exactly once and refuses it afterwards. Say what that makes impossible, which is a second successful use of the same copy.

for a middle

Explain both orderings and what each leaves behind. If the machine wins, the copy is dead; if the thief wins, the failed enrolment is the notification. Mention that retrying a rejection throws the notification away.

for a senior

Show the operational half. Describe how a rejection is handled today, who sees it, whether anyone has ever chased one, and how the window is chosen against the real gap between issuing and provisioning.

for a principal

The tradeoff to argue is how much provisioning friction the organisation will accept for a bounded first credential, and what the fallback is when a machine must be brought up outside the normal path at two in the morning.

## What the control is for A machine being provisioned has to receive something the store will accept. However it is handed over — by an operator, by a provisioning system, through a ticket or a message — that handover is a channel, and channels leak. A **single-redemption** enrolment token accepts the leak as possible and changes what happens next: the store accepts exactly one presentation of that value and refuses every later one. The common mistake is to describe this as preventing theft. It prevents nothing. What it does is make theft **collide**, and a collision is visible where a copy is not. ## Who wins, and what the loser tells you There are only two orderings, and both are useful: 1. **The intended machine redeems first.** The exchange completes, the machine gets a real identity, and the copy the thief holds is now a dead string. Nothing is lost, and the theft may never be known. 2. **The thief redeems first.** The thief obtains an identity, but the machine's provisioning now fails with a rejection at exactly the moment a person or a pipeline is watching a build complete. That rejection is the evidence. The second ordering is the whole value of the mechanism, and it is worth stating plainly: **the failed redemption is the signal**. It is also fragile in a specific way. If the operational habit on a failed enrolment is to issue a fresh value and retry until the build succeeds, then the signal is discarded every time it fires, and the control has been turned back into an unobservable one. A single-redemption scheme is only as good as the treatment of its rejections. ## What each property bounds | Property | What it bounds | What it does not do | |---|---|---| | Single redemption | how many usable copies exist after the first exchange | stop the copy from being made | | Short window | how long a copy is worth anything | say who presented it | | Recorded source of redemption | whether an odd redemption can be noticed later | authenticate the presenter, since a source can be claimed | | Narrow scope | what the redeemer gets if they win | prevent them from winning | Those are four independent controls, and answers that collapse them into one lose the point. A short window with unlimited redemptions lets a thief use a copy repeatedly for ten minutes. Single redemption with an unlimited window leaves a live value sitting in a message thread for a year. They are usually combined for exactly that reason. ## What it does not do - It does not authenticate the redeemer. The store learns that *someone holding this value* asked; first presenter wins. - It does not protect the handover channel. A value pasted into a message is still in that message until it is spent or expires. - It says nothing about the rights the machine receives afterwards. Those come from the identity issued at redemption and are a separate decision. - It does not remove the trusted party. Whatever issued and delivered the value is now holding the right to introduce machines, which is its own subject. ## Operating it - Treat a rejection reading *already redeemed* as a possible theft until someone has looked, not as a build flake. - Record where each redemption came from and what was expected, so an odd one is noticeable even though a source can be forged. - Issue at provisioning time, not at build time, so the window covers the gap that actually exists rather than sitting open from the moment a template was produced. - Issue a fresh value rather than extending an old one when a window closes unredeemed. An extension quietly converts a bounded value into an unbounded one. - Expect unredeemed values: most of them mean a build never ran. They are dead, and the only thing they cost is the question of why provisioning did not happen. ## The answer an interviewer is listening for *It makes a stolen copy collide with the legitimate use, and the collision is the only notification we get* — followed by the caveat that this is only true if the rejection is investigated rather than retried. A candidate who adds that the window, the scope and the channel are separate controls has shown they understand which job each one is doing.

  • An enrolment value was never redeemed before its window closed. What now?
    It is dead, so issue a fresh one rather than extending it, and find out why provisioning never ran. Most unredeemed values mean a build failed, but it is also the only sign you get that the intended machine never received what was sent to it.
  • Why record where a redemption came from when a source can be claimed by anyone?
    It does not authenticate the caller. It turns a redemption from an unexpected place into a recorded mismatch someone can act on, and it raises what an attacker must arrange. The legitimate machine's rejection remains the stronger evidence.
  • Does this remove the need to protect the channel the value travelled on?
    No. Single redemption bounds what a stolen copy is worth, but a thief who redeems first still obtains a real identity. The channel still decides how often that race happens at all, and a careless one guarantees it will.

saying these in an interview costs you the question

  • Says a one-time value cannot be stolen in transit
  • Treats a failed redemption as a build flake and retries
  • Believes redemption proves which machine presented the value
  • Says a short window makes single redemption unnecessary
  • Assumes the handover channel stops mattering
  • Extends the window of an unredeemed value instead of reissuing