# WP-62 — Backend: medewerker caller identity + authz seam

Status: todo
Phase: 11 — Behandelportal

## Why

The backend's only identity today is `CallerIdentity` (BSN + display name, from WP-53)
modeling a single zorgverlener actor. ADR-0002 requires a second actor kind
(medewerker/employee) that authenticates differently (no BSN, has `rollen`) and needs its
own capability checks for backoffice calls. This slice adds that identity + authz surface
on the backend only — unused by any frontend until WP-64 calls it, matching the same
"seam, not provider" discipline WP-53 used for citizen identity (stub, no real employee
SSO — out of scope per CLAUDE.md, same as DigiD).

## Read first

- [ADR-0002 §3 — Principal union](../reference/architecture/0002-user-groups-and-bounded-contexts.md)
- `backend/src/BigRegister.Api/Domain/Authorization/CallerIdentity.cs`,
  `IIdentityProvider.cs`, `StubIdentityProvider.cs` (WP-53's pattern to extend/mirror)
- [WP-53](WP-53-inbound-identity-and-citizen-scoping.md)

## Decisions (pre-made, don't relitigate)

- Model the two actor kinds as a discriminated union (mirroring ADR-0002 §3:
  `{ kind: 'zorgverlener'; bsn }` | `{ kind: 'medewerker'; medewerkerId; rollen }`),
  backend-side, extending `CallerIdentity` rather than introducing a parallel type.
- Stub the medewerker identity the same way WP-53 stubbed citizen identity (a
  header-driven `StubIdentityProvider` variant) — no real employee SSO/eHerkenning.
- New capability checks (e.g. `canBeoordelen`) are computed backend-side and exposed only
  as decision flags, never a permission matrix shipped to a frontend (ADR-0001 discipline,
  reaffirmed by ADR-0002 §3).

## Files

- `Domain/Authorization/CallerIdentity.cs` (extend to the union)
- `Domain/Authorization/StubIdentityProvider.cs` (medewerker variant)
- `Domain/Authorization/Authz.cs` (medewerker capability checks)
- Tests

## Steps

1. Extend `CallerIdentity` to the two-actor-kind union.
2. Extend the stub identity provider to produce a `medewerker` identity from a
   header/config, alongside the existing zorgverlener stub.
3. Add capability checks a backoffice caller needs (start with `canBeoordelen`; extend as
   WP-65 needs more).
4. Unit tests for both identity kinds and the new capability checks — no consumer exists
   yet (WP-64+ will call this).

## Acceptance criteria

- [ ] `CallerIdentity` represents both actor kinds without breaking any existing
      zorgverlener call site (WP-53's tests still green).
- [ ] A stub medewerker identity resolves from a request header, mirroring the existing
      citizen stub.
- [ ] At least one capability flag (`canBeoordelen`) computable for a medewerker
      identity, unit-tested.

## Verification

`cd backend && dotnet test` (existing WP-53 tests unaffected + new medewerker tests
green).

## Out of scope

Any actual backoffice endpoint using this (WP-64+); real employee SSO/eHerkenning.

## Risks

If the union is modeled as a bolt-on rather than replacing the flat type, existing
zorgverlener call sites could break — mitigated by keeping WP-53's existing tests as a
regression gate.