Proposal: game-scoped session signer — promptless host signing as a user-scoped identity (//candidate)

[peetzweg]

Pre-RFC / discussion-opener from the DIM2 (Jollity) web product team. Full write-up (with alternatives, security, migration, and the long-run direction): https://github.com/paritytech/dim2-spa-fable/blob/main/docs/proposals/game-scoped-session-signer.md — issue refs like #23/#16/#26 below are in the dim2-spa-fable repo.

The gap

DIM2 runs sandboxed under the Host API and follows the no-keys model (product addresses accounts, host holds keys). But the Game pallet requires the statement signer to BE the registered player — the //candidate account (a hard derivation of the user's root), which sign-up registers and grants a PlayerStatementLimit statement-store allowance.

//candidate (sr25519) must sign on two surfaces during a game:

• Statements — the signaling stream (high-frequency): every SDP offer/answer, each ICE candidate, and the request/ACK handshake is a statement whose proof is signed by //candidate — dozens per minute, continuously. Must be promptless.
• Extrinsics (a handful/game): Game.report at end (in the web product, mid-session), plus sign_up (can be native/phone) and occasional offboard.

What hosts offer today doesn't fit — the gap is which identity signs, not whether the host can sign promptlessly:

• create_proof_authorized (RFC-0010): promptless, but signs with the host's session/allowance account — not //candidate, and it has no PlayerStatementLimit allowance, so the Game pallet rejects it.
• Product accounts: soft-derived, product-scoped; the runtime doesn't recognize them as players.
• sign_payload / create_transaction: per-signature confirmation — fine for ~2 extrinsics, unusable for a signaling stream.
• Entropy.derive (RFC-0007): derived bytes for product-held keys — the opposite of what's needed.

The product must never see key material, so there's no product-side workaround that isn't a custody regression.

The ask (one new capability)

A session-scoped, promptless signer bound to a specific user-scoped, host-owned derivation, under an explicit bounded scope:

open_scoped_session({
  identity: Derivation("pop-candidate") | IdentityRef([u8;32]),  // which host-owned key
  scope: {
    statements: { topics, channels, max_per_minute },           // promptless within scope
    calls: ["Game.report"],                                      // tiny extrinsic allowlist
    expires_at,
  },
}) -> { session_id, public_key }
// then: session_sign_statement / session_create_transaction (promptless, in-scope only)
//       close_scoped_session (visible + revocable)

One consent sheet at open; everything in-scope then promptless; out-of-scope is a typed error, never a silent fallback. Framed as a generalization of create_proof_authorized/RFC-0010 along the identity axis — not a new signing engine. Mobile hosts already do exactly this natively (the native game signs statements + report with //candidate); this exposes existing behavior as a wire capability so hosted web/desktop products reach parity.

Long-run context (opens a second discussion)

This is deliberately the identity primitive. Orthogonally, we think the transport should eventually become a host primitive too — connect(peer) → media tracks + native call UI, never touching WebRTC (the ext.media direction). The two compose: even a fully host-owned connection would still need to sign DIM2's signaling as //candidate, because those statements are the on-chain player record. Generic 1:1 calling apps would use only the connection primitive; personhood/on-chain apps like DIM2 use both. Tracked separately (dim2-spa-fable#26); the ext.media blocker for us is a product-facing data channel + an identity hook (this proposal's IdentitySelector).

Open questions for the host-sdk / truapi team

1. Identity selector: RFC-vetted named-derivation registry vs opaque identity_ref minted by a prior host flow (e.g. native sign-up)?
2. Home: new trait, extension of Signing, or a new RFC-0010 allowance kind under ResourceAllocation?
3. dotli cross-device: the keystore is the paired phone — does the phone hold the session (relay latency per statement?) or delegate a session key to the web host for the scope?
4. Statement-scope vocabulary: topics/channels, or reference the on-chain PlayerStatementLimit?
5. Consent copy ownership: host heuristics vs RFC-registered use-case strings?
6. Contract of record: truapi RFC first, or prototype as a useragent-kit/host-container extension and graduate?

Happy to prototype the product side against @parity/host-api-test-sdk and be the first consumer — our M5 is blocked on the direction chosen here.

[peetzweg]

Related prior art / active work (cross-linking so owners of adjacent work can weigh in — this proposal should coordinate with, not cut across, the ongoing signing/account reshaping):

• Drop dotNsIdentifier from account/signing methods and add permissioned external-account access #243 (drop dotNsIdentifier from account/signing methods + permissioned external-account access) — the closest neighbor. Our IdentitySelector is the same mechanism shape: a product reaching an account beyond its own product account, under host permission. Worth aligning the shape.
• Post-W3F API changes: signWithAccount, getPrimaryDotNsName, certifications, product keys #222 (post-W3F: signWithAccount, getPrimaryDotNsName, certifications, product keys) — generalizes signing to any UA-returned AccountId and adds proof-of-common-control. Our //candidate identity story should slot into this rather than parallel it.
• cli host #264 (headless pairing + signing hosts) — a phone-less signing host that pairs over the real paseo-next-v2 statement store and signs with a mnemonic. A natural vehicle to prototype/test this capability without a phone.
• Lineage: generalizes RFC-0010 (allowance / create_proof_authorized) along the identity axis; adjacent to RFC-0020 (create_transaction); boundaries per RFC-0008 (statement store) and RFC-0007 (derive-entropy).

Flagging early so we align the identity-selector shape with #243/#222 instead of designing in parallel. Happy to prototype against #264.

[peetzweg]

Update from the DIM2 web product team (2026-07-20)

Short version: we unblocked hosted play without this capability, using RFC-0007 deriveEntropy. So the specific "game-scoped session signer bound to //candidate" ask here is largely superseded for us. The promptless, no-keys end-state we still want maps onto RFC-0010 product-account signing (product keys), so that is where we would like to pick this up later.

What changed

• We dropped the assumption that the player must be //candidate. The Game pallet is origin agnostic: sign_up_with_account (and the invite and alias variants) accept any signed account, and the PlayerStatementLimit allowance is granted to whoever signs up. //candidate was only a client convention, not a runtime requirement.
• So the product now derives its own player key in-product from deriveEntropy (RFC-0007): an sr25519 key for the player account and a P-256 scalar for the signaling encryption, each from a fixed context string. It signs up that account and signs its own statements and its report. The signer already is the registered player, so nothing needs the host to sign as //candidate.
• Same wallet gives the same player on every host, with no phone round-trip after the one login. This shipped, and we have run full cross-client games: a hosted self-custody player and a standalone mnemonic player connecting over WebRTC, with signaling on the host statement store.
• One host-behavior caveat worth flagging: on dotli the product must call requestLogin on a hosted boot before deriving. That prompts pairing and also makes the host initialize its statement store (its lazy initAuth). Without it, signaling submits fail with "Statement store not initialized" even though sign-up and report over the raw chain connection still work.

Worth noting: Entropy.derive is listed in the issue as "the opposite of what's needed." It turned out to be exactly what unblocked us, once we stopped requiring the identity to be //candidate and let the product pick its own account.

The trade-off

The product now holds a real private key in sandboxed JS (the entropy-derived account plus its deposit). That is a step away from the no-keys model, accepted for now on testnets.

What we still want (why not just close this yet)

The custody-clean end-state where the product signs nothing and a host-owned, product-scoped account signs promptlessly. That is the RFC-0010 AutoSigning / product-keys direction (cf #222). When it lands we would like to move the signing identity to a host-held product account and keep only the encryption scalar on deriveEntropy (RFC-0007 and RFC-0010 compose, neither replaces the other). At that point the bespoke game-scoped signer proposed here is mostly subsumed by product-account signing.

Suggestion

Treat this as largely superseded and fold it into the RFC-0010 product-keys discussion as a concrete use case (high-frequency statement signing as a stable per-user, per-product identity), rather than a separate new capability. Happy to close it, or keep it open as an input to that work, whichever the truapi owners prefer.

[peetzweg]

Closing as superseded (details in the update above). DIM2 unblocked hosted play with RFC-0007 deriveEntropy self-custody, so the game-scoped //candidate signer proposed here is no longer needed to play. The promptless, no-keys end-state we still want is the RFC-0010 AutoSigning / product-account keys direction, tracked in #222 — please treat this proposal as a use case for that work (high-frequency statement signing as a stable per-user, per-product identity). Happy to reopen or prototype if that discussion wants a first consumer.