@oxyhq/contracts 0.14.2 → 0.16.0

package/dist/esm/deviceBoot.js

@@ -1,10 +1,11 @@
 /**
  * First-party login result contract.
  *
- * SINGLE SOURCE OF TRUTH for the first-party password login result (2FA arm vs.
- * session arm). The API validates its OUTPUT against this schema; every consumer
- * (`@oxyhq/core`'s auth mixin) validates its INPUT against the same definition,
- * so producer and consumers cannot drift.
+ * SINGLE SOURCE OF TRUTH for the first-party login result (the session arm). The
+ * API validates its OUTPUT against this schema; every consumer (`@oxyhq/core`'s
+ * auth mixin) validates its INPUT against the same definition, so producer and
+ * consumers cannot drift. Sign-in is passkey (WebAuthn) or Commons handoff —
+ * password and 2FA were removed, so the only outcome is a completed session.
  *
  * The device transport is `deviceId` + `deviceSecret` + `POST /session/device/token`
  * (see `deviceSession.ts`). The legacy cookie/bootstrap/refresh-family lanes were
@@ -22,10 +23,6 @@
  * `require()`).
  */
 import { z } from 'zod';
-const loginTwoFactorRequiredSchema = z.object({
-    twoFactorRequired: z.literal(true),
-    loginToken: z.string(),
-});
 const securityAlertSchema = z.object({
     message: z.string(),
     anomalies: z.array(z.object({
@@ -47,7 +44,4 @@ const loginSessionResultSchema = z.object({
         avatar: z.string().optional(),
     }),
 });
-export const loginResultSchema = z.union([
-    loginTwoFactorRequiredSchema,
-    loginSessionResultSchema,
-]);
+export const loginResultSchema = loginSessionResultSchema;

package/dist/esm/identity.js

@@ -187,7 +187,7 @@ export const domainVerificationInstructionsSchema = z.object({
     }),
 });
 export const authMethodEntrySchema = z.object({
-    type: z.enum(['identity', 'password', 'google', 'apple', 'github', 'webauthn']),
+    type: z.enum(['identity', 'webauthn']),
     linkedAt: z.union([z.string(), z.date()]),
     verificationMethodId: z.string().optional(),
     credentialId: z.string().optional(),

package/dist/esm/index.js

@@ -43,6 +43,12 @@ export {
 // Schemas
 loginResultSchema, } from './deviceBoot.js';
 export { 
+// Schemas
+rotateKeyChallengeResponseSchema, rotateKeyCompleteRequestSchema, rotateKeyCompleteResponseSchema, } from './keyRotation.js';
+export { 
+// Schemas — encrypted off-device identity backup (b3 Feature 1)
+backupLookupIdSchema, encryptedBackupEnvelopeSchema, backupUploadRequestSchema, backupStatusResponseSchema, } from './keyRecovery.js';
+export { 
 // Shared primitives
 updatePlatformSchema, updateStatusSchema, updateAssetStatusSchema, sha256HexSchema, channelNameSchema, runtimeVersionSchema, rolloutPercentSchema, 
 // Assets: init + complete

package/dist/esm/keyRecovery.js

@@ -0,0 +1,88 @@
+/**
+ * Encrypted off-device identity backup contract (b3 Feature 1).
+ *
+ * SINGLE SOURCE OF TRUTH for the "encrypted identity backup" flow, where a
+ * client stores an encrypted copy of its self-custody identity key off-device so
+ * a lost/wiped device can be recovered from the recovery phrase ALONE — without
+ * the platform ever seeing the phrase, the derived encryption key, or the
+ * plaintext private key.
+ *
+ * Zero-knowledge design (mirrors the zero-cookie `DeviceSession.secretHash`
+ * pattern): the client derives, from the FULL 64-byte BIP-39 seed, both an
+ * encryption key (`backupKey`) and a locator (`lookupId`) via HKDF with
+ * domain-separated `info` labels. It uploads ONLY the XChaCha20-Poly1305
+ * ciphertext plus the raw `lookupId`; the server stores the ciphertext and
+ * `sha256(lookupId)` (never the raw `lookupId`). Restoration re-derives both
+ * from the phrase, fetches the envelope by `lookupId`, and decrypts locally.
+ *
+ * The server can neither locate a backup (it lacks the seed to compute the
+ * lookup id) nor decrypt one (it lacks the seed to compute the backup key) — a
+ * DB dump yields only opaque ciphertext keyed by an un-invertible hash.
+ *
+ * The producer (`@oxyhq/api`) validates its request/response against these
+ * schemas; the consumer (`@oxyhq/core` identity-backup mixin) validates its
+ * input against the same definitions, so the wire shape cannot drift.
+ *
+ * All shapes here are FLAT (no nested objects), so `z.infer<>` is safe under a
+ * consumer's node10 `moduleResolution`. Platform-agnostic — zod only, ESM-safe
+ * (no `require()`).
+ */
+import { z } from 'zod';
+/** 256-bit backup locator (32 bytes), lowercase/uppercase hex. */
+export const backupLookupIdSchema = z
+    .string()
+    .trim()
+    .regex(/^[0-9a-fA-F]{64}$/, 'lookupId must be 64 hex characters');
+/**
+ * The stored, self-describing encrypted backup as it lives at rest and travels
+ * on the public restore endpoint. Contains NO secret and NO locator: the
+ * `lookupId` is uploaded separately (see {@link backupUploadRequestSchema}) and
+ * only its hash is ever persisted.
+ *
+ * - `version`       — envelope/KDF version, so a future scheme migration is
+ *   distinguishable at rest.
+ * - `algorithm`     — the AEAD used. Pinned literal so a mismatched decryptor
+ *   fails loudly rather than silently.
+ * - `kdfInfo`       — the HKDF `info` label used to derive the encryption key
+ *   (domain-separation tag; documents exactly which context produced the key).
+ * - `nonce`         — the 24-byte XChaCha20-Poly1305 nonce, hex.
+ * - `ciphertext`    — the encrypted `{privateKey, publicKey, createdAt}` payload
+ *   with the appended Poly1305 tag, hex.
+ * - `publicKeyHint` — a short, non-sensitive prefix of the backed-up identity's
+ *   public key, so the owner can recognise WHICH identity a backup belongs to
+ *   without exposing the full key. Bound into the AEAD associated data.
+ * - `createdAt`     — ISO-8601 creation timestamp.
+ */
+export const encryptedBackupEnvelopeSchema = z.object({
+    version: z.number().int().positive(),
+    algorithm: z.literal('xchacha20poly1305'),
+    kdfInfo: z.string().min(1),
+    nonce: z.string().trim().min(1),
+    ciphertext: z.string().trim().min(1),
+    publicKeyHint: z.string().trim().min(1),
+    createdAt: z.string().trim().min(1),
+});
+/**
+ * Request body of `POST /identity/backup` — the envelope PLUS the raw
+ * `lookupId`. The server sha256-hashes `lookupId` before storing it (it never
+ * persists the raw value), and upserts by the authenticated user id so a
+ * re-upload REPLACES the prior backup rather than accumulating duplicates.
+ */
+export const backupUploadRequestSchema = encryptedBackupEnvelopeSchema.extend({
+    /**
+     * The raw 256-bit backup locator (hex), derived client-side from the seed
+     * with a domain-separated HKDF `info`. The server stores ONLY its sha256; a
+     * DB dump therefore cannot recompute a locator to enumerate backups.
+     */
+    lookupId: backupLookupIdSchema,
+});
+/**
+ * Response of `GET /identity/backup/status` (and the write/delete acks): whether
+ * the authenticated user has a stored backup, plus the non-sensitive hint +
+ * timestamp when one exists. Carries no ciphertext and no locator.
+ */
+export const backupStatusResponseSchema = z.object({
+    exists: z.boolean(),
+    publicKeyHint: z.string().optional(),
+    createdAt: z.string().optional(),
+});

package/dist/esm/keyRotation.js

@@ -0,0 +1,72 @@
+/**
+ * Key-rotation contract (b3 Feature 3 — key rotation + last-credential replacement).
+ *
+ * SINGLE SOURCE OF TRUTH for the atomic key-rotation flow:
+ *  - `POST /auth/rotate/challenge` — mint a single-use `rotate_key` challenge.
+ *  - `POST /auth/rotate/complete`  — prove control of the CURRENT (old) key and
+ *    atomically swap in the new one.
+ *
+ * Rotation is an atomic REPLACE of the single identity key, never a
+ * remove-then-add, so it never passes through a zero-auth-method state and is
+ * independent of the unlink guards. Because the client proves possession of the
+ * current key (from SecureStore OR a recovery-phrase re-derivation), the LAST
+ * remaining credential can be replaced — the server only cares that the
+ * signature validates against the current `publicKey`.
+ *
+ * The API validates its output against these schemas; `@oxyhq/core`'s identity
+ * mixin validates its input against the same definitions, so producer and
+ * consumer cannot drift.
+ *
+ * All shapes here are FLAT (no nested objects), so `z.infer<>` is safe under a
+ * consumer's node10 `moduleResolution` — no interface-pinning needed.
+ *
+ * Platform-agnostic — zod only, ESM-safe (no `require()`).
+ */
+import { z } from 'zod';
+/**
+ * Response of `POST /auth/rotate/challenge`: the single-use `rotate_key`
+ * challenge the client must sign with its CURRENT key, plus its expiry.
+ */
+export const rotateKeyChallengeResponseSchema = z.object({
+    challenge: z.string(),
+    /** ISO-8601 expiry timestamp. */
+    expiresAt: z.string(),
+});
+/**
+ * Request body of `POST /auth/rotate/complete`.
+ *
+ * Two proofs are required:
+ *  - `signature` — the CURRENT (old) key signs
+ *    `JSON.stringify({ action: 'rotate_key', userId, oldPublicKey, newPublicKey,
+ *    challenge, timestamp })` (proves control of the key being replaced).
+ *  - `newKeyProof` — the NEW key signs
+ *    `JSON.stringify({ action: 'rotate_key_new', userId, newPublicKey, challenge,
+ *    timestamp })` (proof-of-possession of the key being rotated IN; prevents an
+ *    attacker rotating their account to a re-encoding of someone else's key they
+ *    do not control).
+ *
+ * The request carries ONLY `newPublicKey` — `oldPublicKey` and `userId` are
+ * derived server-side from the authenticated user document (never
+ * client-supplied), so a caller cannot prove control of key X while rotating
+ * key Y.
+ */
+export const rotateKeyCompleteRequestSchema = z.object({
+    newPublicKey: z.string().trim().min(1),
+    challenge: z.string().trim().min(1),
+    signature: z.string().trim().min(1),
+    /** Proof-of-possession: the NEW key signs the rotate_key_new payload. */
+    newKeyProof: z.string().trim().min(1),
+    timestamp: z.number(),
+    /**
+     * When true, all OTHER active sessions for the account are revoked after a
+     * successful rotation (the rotating device stays signed in). Use it when the
+     * old key is presumed compromised.
+     */
+    signOutEverywhere: z.boolean().optional(),
+});
+/** Response of `POST /auth/rotate/complete`: the account's new (rotated) public key. */
+export const rotateKeyCompleteResponseSchema = z.object({
+    success: z.boolean(),
+    publicKey: z.string(),
+    message: z.string(),
+});