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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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