# Authorization

IAM roles may name broad personas. PlayerPal permissions name business operations. Fine-grained authorization stays server-side.

Long-form: spec §5.3, §17. v1 is application-native Nest checks
([ADR 0029](decisions/0029-application-native-authorization.md)). A policy
engine waits until a second service shares the same PlayerPal permissions
or non-engineers must author those rules.

## Personas (IAM)

```text
player
operator_admin
provider_admin
affiliate_admin
playerpal_support
playerpal_platform_admin
```

These are not the complete authorization model. Never treat IAM roles as sufficient for alias, ledger or report access.

## Permissions (PlayerPal)

```text
loyalty.self.read
operator.player.loyalty.read
operator.player.alias.issue
provider.activity.write
provider.batch.status.read
reports.aggregate.read
reports.player.read
campaign.read
campaign.manage
integration.read
integration.manage
identity.connection.revoke
support.session.create
```

Every decision must evaluate principal, organisation, integration, audience, resource owner, permission, data-sharing agreement, and any support or delegated-access context.

## Rules

- Partners may only use aliases issued to their audience. Cross-audience attempts return the same response as an unknown alias (spec §37).
- Provider/operator scope comes from authenticated integration configuration, credentials, certificate or upload location, not a free-text payload field (ADR 0014).
- Support impersonation and cross-operator access are explicit, audited capabilities, not UI tricks.
- Portal UI hiding a nav item is not enforcement.

Capability gating by assurance level (A0-A3) is described in [linking-and-bootstrap.md](linking-and-bootstrap.md) and ADR 0020.