Skip to content

Core sync: DID identity — challenge–response token issuance, DID entityIds in config and discovery (core #49) #42

Description

@cuibonobo

Server side of haverstack/core#49 (RFC: entityId becomes a DID, did:key floor). Big rock on its own clock per the review's sequencing; filing now so the server-shaped work is visible.

What changes here

  1. Bootstrap. ENTITY_ID env var (an arbitrary string today, src/config.ts:31) becomes a DID — or better, the generated-key flow core Polish batch: dead BASE_URL config, /records/query auth doc mismatch, fabricated token createdAt, unvalidated token entityId, silent ENTITY_ID mismatch, shutdown timeout #49 sketches: initialize() generates/accepts a keypair, derives the owner DID, creates the owner _entity record. The server's first-run path (src/stack.ts:13-18) and README/.env.example follow whatever core lands.
  2. Token issuance stops being an out-of-band secret handoff. New endpoints per the core Polish batch: dead BASE_URL config, /records/query auth doc mismatch, fabricated token createdAt, unvalidated token entityId, silent ENTITY_ID mismatch, shutdown timeout #49 sketch: server issues a nonce; requester signs it with the key their DID encodes; server verifies (no lookup needed for did:key) and issues a session token via the existing StackTokenStore. POST /tokens (owner-manual issuance, src/routes/tokens.ts) can remain as the owner's escape hatch, but its entityId input becomes a validated DID.
  3. Discovery entityId becomes a DID string (src/routes/wellknown.ts:11).
  4. OWNER_TOKEN stays as transport-level owner auth or gets subsumed by the same challenge–response — decide with the owner when the core RFC firms up the wire sketch.
  5. Per a core Polish batch: dead BASE_URL config, /records/query auth doc mismatch, fabricated token createdAt, unvalidated token entityId, silent ENTITY_ID mismatch, shutdown timeout #49 open question: verified-but-ungranted DIDs should be distinguishable from anonymous in server logs/errors — cheap to do in the auth middleware once verification exists.

Sequencing

Blocked on core #49 (DID validation helpers, bootstrap, wire sketch). The open key-custody question (who may act as a group — core #49/#58) is deferred upstream and must not be foreclosed here.

Work items

Refs haverstack/core#49, haverstack/core#46 (StackTokenStore), haverstack/core#58, #33.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions