Diagnose authority drift in a background download

Understand the likely causes

• The design may rely on request-time authority without defining later retrieval, carry client-supplied subject attributes into a job, use stale cached assignments, confuse an unexpired result with permission, or omit result-to-workshop scope. The correct behavior depends on the documented authority model. A current-assignment rule and an explicitly reviewed delegation model are different policies, not interchangeable assumptions.

Resolve the authority policy before changing checks

Determine whose authority applies at creation, job processing, and retrieval, and how assignment removal, subject deactivation, and expiry affect each stage. Do not automatically disable the retrieval check to make a legitimate case pass. Update the data-flow model with the stored result and its lifetime, then map the actual trusted facts used by each component. This guide chooses current assignment plus unexpired result as a fictional policy. It does not prescribe that model for every product or claim that a real service implements it.

Test permission, scope, and time independently

The example keeps assignment, result scope, and time as separate inputs. It accepts the legitimate current relationship, rejects removal even before expiry, and rejects an expired result despite assignment. These are declared local facts; a real handler must obtain them from trusted identity and storage boundaries. A request parameter claiming currentAssignment=true cannot supply authority. Include result-to-workshop binding so one valid assignment cannot unlock every stored result. The program does not start a job, validate a session, read a store, or prove cache freshness.

def may_download(assigned, result_workshop, requested_workshop, now, expires):
    return assigned is True and result_workshop == requested_workshop and now < expires

assert may_download(True, "w1", "w1", 99, 100) is True
assert may_download(False, "w1", "w1", 99, 100) is False
assert may_download(True, "w1", "w1", 100, 100) is False
assert may_download(True, "w2", "w1", 99, 100) is False
print("download relationship, scope, and expiry distinguished")

download relationship, scope, and expiry distinguished

Repair the lifecycle boundary and preserve legitimate use

Apply the chosen retrieval policy at the trusted shared boundary, and review job context propagation and any cached authority assumptions. Do not trust client-set provenance labels or opaque storage names as permission. Verify denial creates no new download capability or notification under the contract. If a delegation model is intentionally used, document its scope, lifetime, revocation, and review evidence instead of silently inheriting request-time permission. Include a legitimate assigned-organizer download so a repair that rejects every result cannot pass the review.

Keep it from recurring

• Trigger security review whenever a response becomes a stored artifact or a workflow extends authority lifetime. Keep lifecycle requirements, result scope, diagnostics, and regression cases together. Revisit the decision when tenant rules, assignment freshness, or delegation behavior changes, and preserve unresolved boundaries in release evidence.