PlayerPal Identity

PlayerPal stores one private loyalty identity per Account, many audience-scoped aliases, and no player PII.

Language

Player: The private loyalty identity represented by one players row. One natural person may hold several Players when later links do not unify them. Avoid: User (for this concept)

Account: Product and UX synonym for the same Player row, the portable loyalty account created at first successful registration or link. Never means an IAM login or a partner's external account. Avoid: User, IAM account, authentication account. Those are different.

Party: An organisation or configured integration in the network: operator, provider, affiliate, reward partner stored as MERCHANT, brand, application, or integration. Players are not Parties. Avoid: Treating a Player as a Party; pp_party_...

Reward partner: Canonical name for a partner that fulfils or funds rewards. Stored as party type MERCHANT until the enum is renamed. Avoid: Merchant in prose, unless referring to the DB enum

Brand: A Party type only. Never an alias audience. Avoid: Issuing a player alias for a brand

Application: A Party type placeholder. Not an active alias audience until a concrete receiver exists. Prefix pp_plr_app_... is reserved only. Avoid: Treating Application as a live alias audience in product copy or APIs

Audience (alias scope): Who may see and use a given player alias. Active kinds: operator, provider, affiliate, reward partner. Qualify as alias audience when needed. For provider, the default audience entity is the provider-operator integration. A provider-global audience is allowed only under contract, ADR 0014. Audience entity for affiliate and reward partner, party alone vs further axes, is undecided. Do not invent scope rules or mint those aliases until decided. Avoid: Conflating with portal audience, the URL-isolated portals and separate OAuth clients that share the word but not the concept, ADR 0018

Provider (as alias audience): By default the audience is the provider-operator integration. One pp_int_... maps to one pp_plr_prv_... per integration. A provider-global alias, one value across operators, is allowed only under an explicit contract or exception. The default remains integration-scoped, ADR 0014. Avoid: Taking operator scope from an untrusted provider payload

Pairwise alias: A PlayerPal-issued, cryptographically random player identifier scoped to one alias Audience. Never derived from the internal UUID or PII. Created at completed link or consent for audiences listed on that intent, not at passive first exposure or Activity ingest, and only once the audience entity for that kind is defined. Integrations enabled after the original link mint through explicit resolve (spec §37.5, ADR 0027). Reserved player-alias prefixes:

• pp_plr_opr_..., operator, active
• pp_plr_prv_..., provider, active, integration-scoped by default
• pp_plr_aff_..., affiliate, reserved, scope undecided
• pp_plr_rwd_..., reward partner, reserved, scope undecided
• pp_plr_app_..., application, reserved, not an active alias audience yet Avoid: Using pp_plr_..., pp_opr_..., or pp_prv_... as a partner-facing player alias

Player-visible PlayerPal ID pp_plr_...: The identifier the Player may see for their own Account. Never sent to an operator, provider, affiliate, or reward partner. Avoid: Partner alias, external ID

Analytics subject pp_anl_...: PlayerPal-only clustering key for processed Activity, minted at Account activation. Random, not derived from UUID or pp_plr_..., and never returned to a Player or partner. Avoid: Partner alias; exposing it on /v1/me, link exchange, activity ingest, or studio reads

Studio analytics: Provider-Party numeric views: per-alias lookup with a pp_plr_prv_... that provider was issued, and a cohort of distinct Accounts. Integration ingest is a different plane. Avoid: Building studio KPIs by summing per-alias rows; treating a cohort as a provider-global alias (ADR 0014); returning UUID, pp_plr_..., another Audience’s alias, or the analytics subject

External identity: A partner-issued identifier such as user_123, scoped to the partner that owns it. Not a PlayerPal alias.

Link intent: Short-lived operator or provider ceremony to connect a Player to an Audience. The machine client creates it with a signed operator assertion. The Player completes it once. The machine exchanges a result code for Pairwise aliases. Interface verbs: create, complete, exchange. See ADR 0009 and ADR 0017. Avoid: Treating create alone as a completed link; putting the assertion in a URL

Provider launch session: A short-lived gameplay bootstrap owned jointly by an operator-provider integration. The operator requests it from the provider using their existing authenticated integration. The provider uses it to launch and authenticate the game without calling PlayerPal. PlayerPal may contribute an already-provisioned Pairwise alias to launch metadata. PlayerPal never creates or validates the session. Avoid: PlayerPal launch session; calling PlayerPal during game launch; putting access tokens or signed assertions in the launch URL

Provider play session: A longer-lived in-memory credential issued when a Provider launch session bootstrap is consumed. The game client holds it only in process memory, Authorization header, to create and recover Provider rounds. It is never placed in URLs or durable browser storage. Avoid: Reusing a consumed bootstrap; treating the play session as a PlayerPal session; storing the token in localStorage or sessionStorage

PlayerPal widget: Optional PlayerPal-controlled linking and loyalty-status UI, distributed as a versioned PlayerPal artifact and embedded by a partner page. It has no authority over provider gameplay, wagering, settlement, or Provider launch sessions. Its failure never blocks play. Avoid: Provider-owned widget build; game launcher; settlement module

Link broker: The embedding partner backend the PlayerPal widget calls to discover link status and, when that partner leads linking, to start a Link intent and complete the result exchange without exposing machine credentials to browser code. Provider-led linking uses the provider's broker. Operator-led linking completes independently before game launch. The provider only receives its permitted Pairwise alias in launch metadata. Avoid: Provider-to-operator linking callbacks; browser-held machine credentials; widget-owned integration scope; returning operator aliases to a provider page

Linking mode: The configured route by which an alias reaches a Provider launch session. Supported modes:

• pre-linked: an existing alias is supplied
• operator-led: the operator completes linking before launch
• provider-led: the provider's Link broker completes linking after launch The mode never changes the Audience or alias scope. Avoid: Player-selected linking mode; provider fallback to operator-led linking; treating mode as authorization scope

Provider round: A provider-authoritative gameplay cycle from accepted wager through generated outcome to final settlement. Its cash or play-money result exists independently of PlayerPal. Only after settlement may the provider record a corresponding Activity event in its asynchronous outbox. Avoid: PlayerPal round; letting PlayerPal determine or block a game outcome; treating Activity acceptance as game settlement

Seamless wallet: An operator-authoritative balance integration. The provider requests authenticated wager debits and result credits while retaining authority over the Provider round. Provider retries are idempotent by round and transaction reference. PlayerPal has no role in wallet authorization or settlement. Avoid: Provider-owned cash balance; using a PlayerPal alias as wallet authorization; coupling wallet success to Activity ingestion

Activity event: A factual gameplay or partner event submitted for a Pairwise alias. Example fields for round_settled: bet, win, game_ref, round_ref, occurred_at. PlayerPal calculates Points from eligible events. Unlinked play may still settle at the operator; later Activity for a revoked Audience does not earn Points. Avoid: Calling partner-submitted reward amounts "points earned"; treating unlinked play as loyalty accrual; blocking gameplay because PlayerPal is unavailable

Points: Loyalty units calculated by PlayerPal from eligible Activity events and recorded on the player's ledger. Partners never authoritatively submit PlayerPal point totals. Avoid: Partner-calculated rewards as ledger authority; treating operator cash, bet or win currency, as the same concept as Points

Unlink: Revocation of one consented Audience from the Account. Operator-led Unlink is that operator Party and the provider-operator integrations for that operator. Provider-led Unlink is that provider-operator integration only and never the operator Party. The Player performs it on the PlayerPal Account. Partner shells may deep-link there; the widget may grow the same verb later. Avoid: Delete Account; anonymisation as a player verb; treating Unlink as partner erasure; hosting Unlink as a casino setting; Unlink of a provider row as Unlink of the operator Party

Delete Account: Erasure of the identity graph for that Account. Gameplay facts may remain without identity keys; anonymisation is the retention method, not a third player verb. The Player performs it on the PlayerPal Account, not on a partner shell. Avoid: Unlink; crypto-shredding; commanding a partner to erase their own player record

Authentication identity: An IAM or social proof of issuer plus opaque subject, mapped by PlayerPal to a Player. Not the Player itself. The opaque IAM subject may also be stored for reverse lookup on password sign-in. It is not player PII. Avoid: Account, Player, User. Prefer this term or "IAM subject".