HeiKyu/Rendezvous
2
0
Fork 0
Code Issues 27 Pull Requests Actions Packages Projects Releases Wiki Activity

Implement game/environment provisioning, principals, and signing-key lifecycle #5

New Issue
Open
opened 2026-07-15 10:04:14 +02:00 by Kyuubi · 2 comments
Kyuubi commented 2026-07-15 10:04:14 +02:00
Owner
Copy Link
Copy Source

Parent: #1
Depends on: #2, #4

Outcome

Give every game/environment an isolated policy and trustworthy credential/key boundary.

Scope

  • Add a GamePolicy registry for allowed environments, protocol versions, metadata schema/limits, quotas, regions, visibility modes, and fallback policy.
  • Implement the publisher trust modes approved in #2: provisioned dedicated credentials and the chosen player-host assertion or explicitly lower-trust mode.
  • Derive game/environment scope from the authenticated principal instead of trusting request fields.
  • Add signing/verification keys with key IDs, overlap rotation, revocation, expiry, and a replaceable secret-provider abstraction.
  • Separate operator principals from game/server principals.
  • Ensure a game-wide secret is never shipped in the public Client package or examples.

Acceptance criteria

  • Unknown or disabled game/environment combinations fail closed.
  • Cross-game/environment credential use, wrong audience/issuer, expiry, revocation, and scope escalation are tested.
  • Key rotation preserves intentionally still-valid tickets during the configured overlap and rejects retired keys afterward.
  • Secrets and reusable credentials never appear in responses, logs, metrics, exceptions, or diagnostic dumps.
  • Per-game policy can constrain protocol compatibility, metadata, quotas, and features.
  • Startup fails clearly when required production key material is absent.
Parent: #1 Depends on: #2, #4 ## Outcome Give every game/environment an isolated policy and trustworthy credential/key boundary. ## Scope - Add a `GamePolicy` registry for allowed environments, protocol versions, metadata schema/limits, quotas, regions, visibility modes, and fallback policy. - Implement the publisher trust modes approved in #2: provisioned dedicated credentials and the chosen player-host assertion or explicitly lower-trust mode. - Derive game/environment scope from the authenticated principal instead of trusting request fields. - Add signing/verification keys with key IDs, overlap rotation, revocation, expiry, and a replaceable secret-provider abstraction. - Separate operator principals from game/server principals. - Ensure a game-wide secret is never shipped in the public Client package or examples. ## Acceptance criteria - Unknown or disabled game/environment combinations fail closed. - Cross-game/environment credential use, wrong audience/issuer, expiry, revocation, and scope escalation are tested. - Key rotation preserves intentionally still-valid tickets during the configured overlap and rejects retired keys afterward. - Secrets and reusable credentials never appear in responses, logs, metrics, exceptions, or diagnostic dumps. - Per-game policy can constrain protocol compatibility, metadata, quotas, and features. - Startup fails clearly when required production key material is absent.
Kyuubi self-assigned this 2026-07-16 04:53:31 +02:00
Kyuubi commented 2026-07-16 04:53:31 +02:00
Author
Owner
Copy Link
Copy Source

Starting implementation on codex/issue-5-provisioning, stacked on the verified #2–#4 foundation. I’ll implement fail-closed game/environment policy, distinct principal types, credential scope derivation, key lifecycle/rotation/revocation, a replaceable secret provider, production startup validation, and adversarial tests for cross-scope, issuer/audience, expiry, revocation, escalation, secret leakage, and overlap rotation.

Starting implementation on `codex/issue-5-provisioning`, stacked on the verified #2–#4 foundation. I’ll implement fail-closed game/environment policy, distinct principal types, credential scope derivation, key lifecycle/rotation/revocation, a replaceable secret provider, production startup validation, and adversarial tests for cross-scope, issuer/audience, expiry, revocation, escalation, secret leakage, and overlap rotation.
Kyuubi commented 2026-07-16 05:14:04 +02:00
Author
Owner
Copy Link
Copy Source

Implemented and pushed on codex/issue-5-provisioning at 47382dd.

Delivered:

  • fail-closed GamePolicy registry for game/environment, exact protocol versions, regions, visibility/trust modes, metadata schema/budgets, quotas, and fallback policy;
  • immutable, distinct dedicated-publisher, player-host-grant, anonymous-unlisted, and operator principals;
  • publisher authorization that rechecks expiry and derives authoritative scope from the principal, rejecting request-field scope escalation;
  • compact HMAC-SHA256 principal credentials with exact issuer/audience/version, bounded parsing, fixed-time signature checks, typed validation failures, and key-lifetime consistency;
  • signing keys bound to credential kinds and exactly one game/environment (or operator-only), preventing a compromised grant issuer from minting cross-game/operator claims;
  • replaceable secret-provider abstraction, env: production provider, random in-memory development provider, overlap rotation, configured/runtime revocation, and secure key cleanup;
  • production startup and readiness gates requiring active key material plus matching active publisher keys for every enabled policy;
  • development-only policy/key profile with no committed secret material and provisioning/key-custody documentation.

Verification:

  • locked restore, formatter, Release solution build, generated OpenAPI drift check, and 56/56 tests passed;
  • adversarial tests cover unknown/disabled policy, protocol/metadata/feature constraints, cross-game/environment use, malicious valid-signature scope escalation, wrong issuer/audience, expiry, tampering, configured/runtime revocation, rotation overlap/retirement, operator separation, per-policy key coverage, missing key material, and diagnostic/public-package secret leakage;
  • real Development process bound ephemeral UDP and reported ready;
  • unprovisioned Production process failed before binding with the explicit missing-production-key diagnostic;
  • completion and multi-lens branch audits found no remaining actionable findings.

The issue remains open until the stacked branch is landed.

Implemented and pushed on `codex/issue-5-provisioning` at `47382dd`. Delivered: - fail-closed `GamePolicy` registry for game/environment, exact protocol versions, regions, visibility/trust modes, metadata schema/budgets, quotas, and fallback policy; - immutable, distinct dedicated-publisher, player-host-grant, anonymous-unlisted, and operator principals; - publisher authorization that rechecks expiry and derives authoritative scope from the principal, rejecting request-field scope escalation; - compact HMAC-SHA256 principal credentials with exact issuer/audience/version, bounded parsing, fixed-time signature checks, typed validation failures, and key-lifetime consistency; - signing keys bound to credential kinds and exactly one game/environment (or operator-only), preventing a compromised grant issuer from minting cross-game/operator claims; - replaceable secret-provider abstraction, `env:` production provider, random in-memory development provider, overlap rotation, configured/runtime revocation, and secure key cleanup; - production startup and readiness gates requiring active key material plus matching active publisher keys for every enabled policy; - development-only policy/key profile with no committed secret material and provisioning/key-custody documentation. Verification: - locked restore, formatter, Release solution build, generated OpenAPI drift check, and 56/56 tests passed; - adversarial tests cover unknown/disabled policy, protocol/metadata/feature constraints, cross-game/environment use, malicious valid-signature scope escalation, wrong issuer/audience, expiry, tampering, configured/runtime revocation, rotation overlap/retirement, operator separation, per-policy key coverage, missing key material, and diagnostic/public-package secret leakage; - real Development process bound ephemeral UDP and reported ready; - unprovisioned Production process failed before binding with the explicit missing-production-key diagnostic; - completion and multi-lens branch audits found no remaining actionable findings. The issue remains open until the stacked branch is landed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Kyuubi schmidt.florian (Florian Schmidt)
No Assignees Kyuubi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: HeiKyu/Rendezvous#5
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?