A federation officer sets a member's password before a congress — what must that path do that a self-service change need not?
answer
- a proof nobody present can give
- authority over the subject, not seniority
- must-change marker with a deadline
- same rule set, separate entry point
basics
~20 sAn officer-initiated set cannot re-prove a credential nobody present knows, so it substitutes an authority check over actor and subject, records both on the change, and stores a handover value carrying a must-change marker and a deadline.
solid answer
~50 sThe self-service change rests on re-entering the current password, and on this path nobody can: the member has lost access and the officer never knew the value. So the precondition is replaced rather than waived. The path checks the acting officer's authority over that specific subject, records the actor alongside the subject on the change event, and runs the same rule set as every other write path — an internal tool is still a write path. The value itself is treated as a handover rather than a credential: the row carries a must-change marker so the member sets their own at next sign-in, plus an absolute deadline after which the value stops being accepted. Nothing keeps a copy. And it gets its own entry point rather than the self-service endpoint with the re-proof quietly made optional.
code
pseudocode · 24 linesfunction set_password(subject, new_value, context):
must_change = false # set for every path, so the write below is honest
change_deadline = null
if context.kind == "self_change":
# knowledge re-proof of the exact credential being replaced
if not verify_current(subject, context.current_password):
return Rejected("current password did not verify")
if context.kind == "officer_set":
# nobody present can re-prove a credential the actor never knew,
# so the precondition is replaced, not skipped
require_authority(context.actor, action: "credential.set", on: subject)
must_change = true
change_deadline = now() + OFFICER_SET_VALIDITY
if not rules.accept(new_value): # one rule set, every path
return Rejected("new password rejected by the rule set")
store(subject, derive(new_value), must_change, change_deadline)
emit CredentialChanged(subject: subject,
actor: context.actor, # null when the holder acted
kind: context.kind)
return Accepted()go deeper
Know that an officer setting a password cannot be asked for the current one, and that the member must replace the value themselves at their next sign-in.
Explain the substitute precondition: an authority check over actor and subject together, the same rule set as every other write path, and a change event naming both parties.
Bound the handover — a must-change marker with an absolute deadline, no copy retained — and refuse the shortcut of reusing the self-service endpoint with its re-proof made optional.
Weigh how wide this capability should be and who may hold it. Every account it can reach is an account whose strongest control becomes somebody else's judgement at a desk, so the blast radius is the design question.
Before a congress the federation office gets the same message every year: a player cannot get into the rating-submission site and has results to submit tomorrow. An officer sets a password on that account. Everything interesting about the path follows from one fact — **the proof the self-service change rests on is unavailable here**. ## The proof that is missing An authenticated change asks the member to re-enter the current password, which shows that whoever is typing knows the exact credential being replaced. The officer has never known it and must not be able to learn it: the stored value is derived rather than readable, so a support process that hands a password back is a broken process, not a helpful one. The officer path therefore cannot inherit the self-service endpoint's precondition. It needs its own. ## What replaces it Three things, and none of them is the claim the member would have made: 1. **Authority over this subject.** The question is whether this actor may set a credential on that account, evaluated against actor and subject together — not whether the actor is signed in, and not whether they hold an officer title in general. Being an officer is not the same as being permitted to act on this member. 2. **A record naming both parties.** The change event carries who acted as well as whose account it was. Without the actor, an officer-initiated set and a self-service change look identical afterwards, and a member's later 'that was not me' has nothing to be checked against. 3. **The same rule set as every other path.** An officer-initiated set is a write path. Supervision is not validation, and 'it was an internal tool' is how a value no rule would have accepted ends up stored. ## The value the officer sets is not the member's password Someone other than the account holder knows this value, so treat it as a bounded handover: - The row carries a **must-change marker**, so the member's next sign-in leads to setting their own value before the rest of the site is reachable. - The marker carries an **absolute deadline**. If the player never appears, the set value stops being accepted and the account goes back to the ordinary recovery route rather than sitting indefinitely on a credential an officer chose. - Nothing retains a copy of what was set. If the player loses it between the desk and the hotel, the path is run again, not looked up. This forced change is one-shot and caused by an event. It is not a clock that makes every member type a new password each quarter — a different idea with a much weaker argument behind it, and conflating the two is the quickest way to lose the point. | | Self-service change | Officer-initiated set | |---|---|---| | Precondition | The current password verifies | The actor's authority over this subject | | Who knows the new value | Only the member | The officer and the member | | Written on the row | The stored value | The stored value, a must-change marker, a deadline | | Event carries | Subject, changed by the holder | Subject plus the acting officer | | Ends when | The member chooses to change again | The member sets their own, or the deadline passes | ## Why it is a separate entry into the same routine The tempting shortcut is to reuse the self-service endpoint and let officers leave the current-password field empty. That makes the endpoint's strongest precondition optional, and an optional precondition is one bug away from being skipped for everybody. Give the officer path its own entry with its own authority check, and let it call the same shared set-password routine every other path calls. The rule set and the change event stay in one place; the preconditions differ only where they honestly differ. The same reasoning survives when the credential ultimately lives in an enterprise directory whose own change operation treats the current password as an optional field. Optional there does not make it optional for you — your server decides what it demands before it forwards anything downstream. ## What this path hands on rather than decides A credential somebody else set is a larger event than a routine self-service change, and other parts of the system act on it: what happens to sessions already signed in, what the member is told and through which channel, whether an enrolled second factor survives. This path's job is to emit the event honestly — marked as set by another principal — and let those decisions live where they belong. ## What an interviewer is listening for - That the candidate notices the missing proof first, instead of describing a form. - That the substitute is an authority check plus a record, not 'officers are trusted'. - That the handed-over value is bounded in time and must be replaced. - That the shortcut of making the current-password field optional is named and refused.
- The officer hands the value over at the congress desk and the player never signs in. What bounds the risk?The absolute deadline on the must-change marker. Once it passes the value stops being accepted, and the account goes back to the ordinary recovery route rather than sitting indefinitely on a credential an officer chose. Either way the change event is already on the record, so the set is not invisible.
- Why not reuse the self-service change endpoint with the current-password field left empty for officers?Because that makes the endpoint's strongest precondition optional, and an optional precondition is one bug away from being skipped for everyone who calls it. Give the officer path its own entry with its own authority check, and let both entries call the same shared set-password routine.
- What does the shared routine emit differently for an officer-initiated set?The same credential-changed event, marked as set by another principal and naming the acting officer. Consumers treat 'the holder changed it' and 'somebody else changed it' differently — what they do about existing sessions, notifications or enrolled factors is decided there, not on this path.
saying these in an interview costs you the question
- The officer can look up the member's current password and read it back.
- An officer-initiated set is internal, so the rule set can be skipped.
- The officer is signed in, so no record of who acted is needed.
- A value the officer chose is fine to keep once the member signs in.
- Forcing a change at next sign-in is the same control as quarterly password expiry.