Skip to content

MEMBERS-IDENTITY-001 — Define authoritative membership and external-account state #81

Description

@daliu

Officer impact: Officers will have one plain-language source for whether a person is a current member and what access should follow. No officer workflow becomes available from this design ticket alone.

Officer documentation: Update OFFICER_START_HERE.md, docs/officers/EVENTS_SHOP_MEMBERS.md, docs/officers/ACCESS_CONTINUITY.md, and docs/officers/SYSTEM_MAPS.md with the approved contract and text alternative when implementation lands.

Deployment evidence: None at issue update. Closure must distinguish contract/source changes, tests, merge, website publication, Firebase deployment, provider configuration, and production verification; no green workflow alone proves live membership behavior.

Problem

Website roles, dues/roster membership, Google access, WhatsApp access, and Strava connections can drift. Treating any external channel as a peer membership authority would create accidental access and discount grants.

Invariant

Firebase UID plus a server-verified current MPRC membership record is the only membership authority. Google, WhatsApp, and Strava are desired/observed projections and never grant membership, prices, or privileges.

Scope

  • Define membership states and transitions for approval, renewal, expiry, suspension, reactivation, household/nonresident cases, and offboarding.
  • Define an additive provider-link contract with non-secret metadata, restricted identifiers/tokens, consent, desired state, observed state, last reconciliation, error, and stable command ID.
  • Define collision handling for duplicate email, changed email, Google credential already linked elsewhere, duplicate WhatsApp number, and duplicate Strava athlete.
  • Define minimization, consent, retention, deletion, and access-revocation SLA.
  • Define pure idempotent transition rules and migration from current role-only records.

Acceptance criteria

  • No provider connection or matching email automatically grants club membership.
  • Custom claims contain authorization only, not provider IDs, phone/profile data, or rosters.
  • Duplicate, out-of-order, lapse, renewal, relink, disconnect, and partial-failure transitions are specified and tested.
  • Other integration tickets consume this contract rather than inventing provider-specific membership logic.
  • Migration is additive, dry-runnable, and preserves existing accounts.

Dependencies and sequencing

SEC-001 (#100) and the remaining AUTH-001 verified-email/claim protections are prerequisites for implementation. This issue defines the authoritative membership contract consumed by AUTH-002/AUTH-002A (#117), #114, and #115; those downstream issues are not prerequisites for defining or completing this contract. Align with AUTH-003 capability design before implementation.

Coordination

Parent: #79

Do not begin implementation until dependencies are complete, this issue is assigned, and a timestamped CLAIMED comment naming the agent and branch is posted. Creation of this ticket is not a claim. Preserve the parallel agent work tracked by stable IDs in GITHUB_ISSUES.md.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:authAuthentication and authorizationarea:firebaseFirebase services and dataarea:membershipMembership lifecycle and reconciliationpriority:P0Launch blocker or urgent security risksize:SSmall focused issuestatus:proposedDesigned but dependencies or decisions remaintype:architectureArchitecture and contract design

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions