Skip to content

spike(identity): prototype secure cross-server identity brokerage #1508

Description

@hmans

Goal

Build an adversarial protocol proof of concept for user-mediated cross-server
identity brokerage without persistent user-held keys.

The PoC should establish whether multiple Chatto accounts can form a portable
identity group using mutually signed server certificates and disposable client
ceremony secrets, while preventing one malicious existing server from adding a
new member without another current group member's approval.

Scope

  • Implement a focused Go protocol package and HTTP-based multi-server harness.
  • Create a two-server genesis identity group.
  • Add subsequent members with approval from the target server and two current
    member servers.
  • Bind all offers and certificates to exact origins, opaque user IDs, group IDs,
    nonces, expiry, and a disposable client ceremony proof.
  • Verify certificates from a clean client with no retained secret state.
  • Cover tampering, replay, expiry, idempotency, partial completion, revocation,
    and a synthetic 20-server group.
  • Document the security properties, trust boundary, and production integration
    questions discovered by the PoC.

Deliberate exclusions

  • No production ConnectRPC or realtime API commitment.
  • No persisted core protobuf/event schema yet.
  • No frontend/profile UI.
  • No production server signing-key storage or rotation design.
  • No final recovery policy.

Acceptance criteria

  • Twenty accounts require linear membership certificates rather than a
    pairwise mesh.
  • A clean verifier reconstructs the same identity group from public
    certificates.
  • Modifying any bound account, origin, group, nonce, or expiry invalidates the
    certificate.
  • Replayed or expired ceremony artifacts are rejected.
  • One malicious current member server cannot add an attacker-controlled account
    without a second current member approval.
  • The PoC has focused tests and a concise design report describing what would
    move into RUNTIME_STATE and EVT in a production implementation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions