Answering the things people dislike about PIM

[FrodeHus]

Elevate makes PIM activation quick. It does not yet address the reasons people dislike PIM itself —
and those reasons are remarkably consistent wherever practitioners write about deploying it.

A survey of the public discussion (Microsoft Q&A threads, deployment write-ups, the PowerShell and
Graph workarounds people publish) turns up the same complaints, in roughly this order:

• "I activated, but nothing happened." The service reports the assignment active well before the
  access works — 2–5 minutes for Entra directory roles, 5–15 for Azure resource roles, longer for any
  session still holding a token minted before activation. The folk remedy is to sign out, sign back
  in, try incognito, wait.
• Approval is a black hole. The requester cannot see who is supposed to approve; PIM shows the
  approver list to the administrator configuring the policy, not to the person waiting on it.
  Requests stall, and the rollout gets rolled back after someone is stuck during an incident.
• The daily tax. Retyping justifications, re-picking the same roles, and — for anyone eligible on
  many Azure scopes — working through a long flat list one row at a time.
• Automation is second-class. People hand-roll Graph calls because there is no clean path from
  "I have just activated this role" to "run this authenticated command".
• Eligibility never gets cleaned up. JIT removes standing access and does nothing about
  standing eligibility: leavers, finished projects, one-off grants that were never revoked.

Elevate is unusually well placed to answer most of these, because it already sits in the right place
at the right moment. Several are also already half-solved — multi-select activation across tenants
with one justification, profiles, managed configuration, elevate run, and the standing-access rules
in elevate-audit — so what follows is mostly about closing the remaining distance rather than
building new mechanisms.

Stages

1. Make the green light mean something. Verify a role is effectively usable, not just reported active #181. Foundational: every other improvement is undermined
   if "active" does not yet mean "usable". Today ActivationWaiter polls the service's own view of
   the assignment, and elevate run --settle is a fixed pause rather than a check.
2. Make waiting survivable. Show the requester who can approve a pending request, and let them nudge #182. Show the requester who can approve, how long it has waited, and
   give them a way to nudge. RolePolicy carries requiresApproval as a bare boolean today; the
   approver identities are never read.
3. Cut the daily tax. Justification templates, history and an org-enforced format #185 (justification history, templates, and a format an organisation can
   enforce) and Azure tab: scope hierarchy, search and subtree selection #186 (scope hierarchy, search and subtree selection in the Azure tab). Both build on
   things that already work — remembered reasons and managed profiles; multi-select activation — and
   remove the tedium in front of them.
4. Reach past the panel. CLI: expose an access token to commands, and use it to sign in az, terraform and kubectl #184 (expose a token to commands, then use it to sign in az,
   terraform and kubectl) and elevate-audit: report eligibility that is never used #183 (an elevate-audit rule set for eligibility nobody uses).

Sub-issues: #181, #182, #183, #184, #185, #186.

Notes and decisions

• Client-side, not service-side. Several of these — enforced justification format in particular —
  are conveniences and data-quality measures, not security controls. Anyone using the portal directly
  is unaffected. The docs must say so plainly rather than letting an administrator mistake one for a
  guarantee.
• The Graph scope ceiling stays. CLI: expose an access token to commands, and use it to sign in az, terraform and kubectl #184 is genuinely useful for ARM, where
  user_impersonation is the full surface, and largely misleading for Graph, where Elevate's token
  carries only the four PIM scopes it is consented for. Widening those scopes to make the feature
  look better would trade away the minimal, auditable consent story — and would be worse still for
  anyone on the shared registration. Not worth it; the issue says so and the documentation should
  too.
• Not every complaint belongs here. MFA loops and Conditional Access conflicts are real and
  frequently reported, but they are Entra's behaviour and mostly beyond a client's reach;
  authenticationContext is already modelled, and better error explanation is the realistic
  contribution. Workload identities cannot do JIT at all, which elevate-audit already reports as
  SP-PERMANENT. Change-over-time detection for standing access is already achievable with --json
  and --save-snapshot; a first-class --compare would be a reporting nicety, not a new rule.
• Four of the six span macOS, Windows and the CLI. Where a stage lands in Core it should land in
  all three, as usual.