Provide a longer-lived dedicated-server credential kind or server-driven refresh #32

New Issue

2026-08-22T23:28:43+02:00

Kyuubi commented

2026-08-22 23:28:43 +02:00

Parent: #1
Identified by: SpaceGame v1.0.0 evaluation (SpaceGame docs/rendezvous-eval.md @ 8eb5607) — named as the biggest integration friction.

Classification

Post-v1. The current 600 s DedicatedPublisher credential works and stays the right default for player-hosted and low-trust paths; this adds an explicitly higher-trust option for operated dedicated servers.

Problem

A plain-console dedicated server with no secret boundary must be handed a fresh publisher credential every ≤10 minutes by an external orchestrator. For evaluation the test server's mint helper now accepts a TTL override (60–21600 s), but that is a deployment workaround, not a product answer: long-lived bearer-style credentials on hosts with no secret boundary trade away exactly the replay/compromise properties the short TTL exists for.

Outcome

Either (or both), decided at design time:

A distinct credential kind for provisioned dedicated servers with an operator-set lifetime and first-class revocation, documented as requiring a real secret boundary on the host; or
A refresh flow the running server can drive itself: present the current (short-lived) credential before expiry to obtain its successor over the existing authenticated channel, so the effective session lifetime is long while every individual credential stays short and replay-resistant.

Acceptance criteria

Compromise/revocation story explicit for whichever mechanism lands; revocation takes effect within one lease interval.
Refresh (if chosen) cannot extend scope: same game/environment/subject/kind, and a revoked or expired chain cannot self-renew.
Existing 600 s issuance path unchanged for all other callers; contracts change is additive.
Integration guide gains a dedicated-server credential lifecycle section; the SpaceGame/Unscouted pilots' friction note is resolved by documented flow, not by defaulting to long TTLs.

Parent: #1 Identified by: SpaceGame v1.0.0 evaluation (SpaceGame `docs/rendezvous-eval.md` @ 8eb5607) — named as the biggest integration friction. ## Classification Post-v1. The current 600 s DedicatedPublisher credential works and stays the right default for player-hosted and low-trust paths; this adds an explicitly higher-trust option for operated dedicated servers. ## Problem A plain-console dedicated server with no secret boundary must be handed a fresh publisher credential every ≤10 minutes by an external orchestrator. For evaluation the test server's mint helper now accepts a TTL override (60–21600 s), but that is a deployment workaround, not a product answer: long-lived bearer-style credentials on hosts with no secret boundary trade away exactly the replay/compromise properties the short TTL exists for. ## Outcome Either (or both), decided at design time: 1. A distinct credential kind for provisioned dedicated servers with an operator-set lifetime and first-class revocation, documented as requiring a real secret boundary on the host; or 2. A refresh flow the running server can drive itself: present the current (short-lived) credential before expiry to obtain its successor over the existing authenticated channel, so the effective session lifetime is long while every individual credential stays short and replay-resistant. ## Acceptance criteria - Compromise/revocation story explicit for whichever mechanism lands; revocation takes effect within one lease interval. - Refresh (if chosen) cannot extend scope: same game/environment/subject/kind, and a revoked or expired chain cannot self-renew. - Existing 600 s issuance path unchanged for all other callers; contracts change is additive. - Integration guide gains a dedicated-server credential lifecycle section; the SpaceGame/Unscouted pilots' friction note is resolved by documented flow, not by defaulting to long TTLs.

Kyuubi referenced this issue

2026-08-22 23:31:29 +02:00

Roadmap: ship the Rendezvous connection control plane #1

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: HeiKyu/Rendezvous#32