Qiiub POS · Task 11 · C — IdentifyFirst LIGHT.Identificación previa a una acción privilegiada (override de precio, anulación, ítem restringido). El autorizador se identifica una vez para autorizar UNA operación — no es un login: el autorizador capturado vive en memoria y muere al confirmar/cancelar (no crea sesión, no escribe en tablas de identidad; solo estampa el audit de la acción). Reusa el patrón identify-first de B1 (número VISIBLE = etiqueta no-secreta per 0113 · PIN enmascarado = secreto). Es superficie de seguridad — incluye mapa de invariantes + 1 decisión que necesita tu call. Refs: spec §6 (IdentifyFirst), ADR-0091 Am1 pto.2 (autorización in-sale al momento de la acción — sobrevive RMS Am3), ADR-0113 (identify-first), ADR-0110 (3-tier authority). Created: 2026-06-24 | Last Updated: 2026-06-24
Authorization required
A supervisor must approve this action
Action to authorize
Price override
Paracetamol 500mg · 24ct$8.99$6.50
Supervisor number
07
PIN
Authorizes this action only — does not sign you in
Uniform failure — IdentifyFirst (review state)
Same banner for wrong PIN, locked account, or non-existent number. No attempt counter. Same PinAuthService + decoy PBKDF2 as B1 (timing defense inherited).
New surface, not "B1 but for an action". Each B1/B2 invariant mapped + one decision that is yours.
aEnumeration. Identify by number + PIN — no roster rendered, no length placeholder/prefix on the number (zero enumeration, same as B1 by-number). Number is VISIBLE (non-secret label, ADR-0113); PIN masked.
bEphemeral authorizer (the core difference from B1). The captured authorizer holds for ONE logical operation and dies on confirm/cancel (spec §6). It is NOT a session — no login(), no session state, never written to identity tables; only the authorized action's auditLog stamps who authorized. Reuses pinAuthService for the credential check only.
cClarity — no blind authorization. The action being approved is shown explicitly (type + item + old→new value). The authorizer always knows what they sign for. Shows only the action, not the rest of the sale's internals.
dIn-context, not occluded (unlike the lock). The cashier's own sale is behind the scrim (dimmed) — this is the cashier's in-progress transaction being authorized in place. No new-terminal/anonymous concern here (this is not a takeover or a lock); the scrim is presentational, not a security boundary.
eMemory-only / no leak. No identity/PIN material in logs, toasts, or the persisted layer beyond the audit stamp. Cancel leaves zero trace.
DECISION (yours) — uniform failure vs. "authenticated but not permitted". A privileged-action identify has a failure mode B1/B2 don't: a valid employee with a correct PIN who simply lacks the permission for this action. Two options: (1) keep it uniform — "we couldn't authorize this" for wrong-PIN / locked / not-permitted alike (no oracle: nobody can probe who holds which permission). (2) distinguish — tell a correctly-authenticated but unauthorized person "you don't have permission for this; get a manager" (more helpful, but reveals permission structure to anyone who can authenticate). I lean (1) uniform for the security parity with B1, but it's a real UX trade-off on a non-self-service surface — your call.