@openvtc/trust-tasks 0.17.5 → 0.17.7

package/src/rooms/keys/seal/0.1/payload.ts

@@ -0,0 +1,246 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/rooms/keys/seal/0.1/payload.schema.json
+ */
+
+import type { Ext, SealedRecord } from "../../../../_shared/components.js";
+
+
+export interface RoomsKeysSealPayload {
+  /**
+   * The room to seal for. The recipient MUST hold group state for it.
+   */
+  roomId: string;
+  /**
+   * The record key this will be stored under. Bound into the associated data, so a record sealed for one key does not open under another. On a sealed tier keys MUST be opaque — a descriptive key defeats the encryption beside it, and structured naming belongs inside the sealed body.
+   */
+  key: string;
+  /**
+   * The version the writer INTENDS the record to take, bound into the associated data before the host assigns it. A caller that lets the host assign a different one will find the record does not open, which is the correct failure: accepting whatever came back would mean the binding commits to nothing. The shape that works is a create-only write (`expectedVersion: 0`) or a read of the current version before a rewrite.
+   */
+  version: number;
+  /**
+   * The record body to seal, base64url. Sealed whole rather than field by field: splitting it would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.
+   */
+  plaintext: string;
+  /**
+   * Ecosystem-defined extension members per SPEC.md §4.5.1.
+   */
+  ext?: Ext;
+}
+/**
+ * Success response to rooms/keys/seal. Type https://trusttasks.org/spec/rooms/keys/seal/0.1#response. The sealed record, ready to hand to a host with rooms/records/put.
+ */
+export interface RoomsKeysSealResponsePayload {
+  sealed: SealedRecord;
+  ext?: Ext;
+}
+
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { Ext, SealedRecord };
+
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/rooms/keys/seal/0.1" as const;
+
+/** Stable alias for this specification's request payload shape. */
+export type Payload = RoomsKeysSealPayload;
+
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/rooms/keys/seal/0.1#response" as const;
+
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = RoomsKeysSealResponsePayload;
+
+/**
+ * This specification's payload schema, as a value.
+ *
+ * SPEC.md §7.2 item 2 is performed against this. It is shipped as data
+ * rather than only as a `.json` file because TypeScript types are erased
+ * at runtime: without a schema a consumer has nothing to validate, and
+ * every REQUIRED payload member is optional in practice. Cross-file
+ * `$ref`s are already inlined, so it needs no resolver.
+ */
+export const PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://trusttasks.org/spec/rooms/keys/seal/0.1",
+  "title": "Rooms Keys Seal — payload",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "roomId",
+    "key",
+    "version",
+    "plaintext"
+  ],
+  "properties": {
+    "roomId": {
+      "type": "string",
+      "description": "The room to seal for. The recipient MUST hold group state for it."
+    },
+    "key": {
+      "type": "string",
+      "maxLength": 512,
+      "description": "The record key this will be stored under. Bound into the associated data, so a record sealed for one key does not open under another. On a sealed tier keys MUST be opaque — a descriptive key defeats the encryption beside it, and structured naming belongs inside the sealed body."
+    },
+    "version": {
+      "type": "integer",
+      "minimum": 0,
+      "description": "The version the writer INTENDS the record to take, bound into the associated data before the host assigns it. A caller that lets the host assign a different one will find the record does not open, which is the correct failure: accepting whatever came back would mean the binding commits to nothing. The shape that works is a create-only write (`expectedVersion: 0`) or a read of the current version before a rewrite."
+    },
+    "plaintext": {
+      "type": "string",
+      "description": "The record body to seal, base64url. Sealed whole rather than field by field: splitting it would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way."
+    },
+    "ext": {
+      "$ref": "#/$defs/Ext",
+      "description": "Ecosystem-defined extension members per SPEC.md §4.5.1."
+    }
+  },
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Rooms Keys Seal — response payload",
+      "description": "Success response to rooms/keys/seal. Type https://trusttasks.org/spec/rooms/keys/seal/0.1#response. The sealed record, ready to hand to a host with rooms/records/put.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "sealed"
+      ],
+      "properties": {
+        "sealed": {
+          "$ref": "#/$defs/SealedRecord"
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    },
+    "SealedRecord": {
+      "title": "SealedRecord",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "ciphertext",
+        "nonce",
+        "epoch"
+      ],
+      "description": "A record as a host stores it on an `attributed` or `private` room. Title, description, body, author and tags are sealed together in one blob rather than separately: splitting them would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.",
+      "properties": {
+        "ciphertext": {
+          "type": "string",
+          "description": "The sealed record, base64url. Bound by AEAD associated data to `roomId`, `key`, `version` and `epoch`, so a host that relocates it to another key, version, epoch or room produces a mismatch and the open fails. The record cannot be moved undetected even though the host holds every byte of it."
+        },
+        "nonce": {
+          "type": "string",
+          "description": "AEAD nonce, base64url."
+        },
+        "epoch": {
+          "type": "integer",
+          "minimum": 1,
+          "description": "The key epoch this record was sealed under. Cleartext because the host must serve the right ciphertext, and bound into the associated data so that relabelling it fails authentication rather than causing a reader to try the wrong key."
+        }
+      }
+    }
+  }
+} as const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Rooms Keys Seal — response payload",
+      "description": "Success response to rooms/keys/seal. Type https://trusttasks.org/spec/rooms/keys/seal/0.1#response. The sealed record, ready to hand to a host with rooms/records/put.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "sealed"
+      ],
+      "properties": {
+        "sealed": {
+          "$ref": "#/$defs/SealedRecord"
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    },
+    "SealedRecord": {
+      "title": "SealedRecord",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "ciphertext",
+        "nonce",
+        "epoch"
+      ],
+      "description": "A record as a host stores it on an `attributed` or `private` room. Title, description, body, author and tags are sealed together in one blob rather than separately: splitting them would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.",
+      "properties": {
+        "ciphertext": {
+          "type": "string",
+          "description": "The sealed record, base64url. Bound by AEAD associated data to `roomId`, `key`, `version` and `epoch`, so a host that relocates it to another key, version, epoch or room produces a mismatch and the open fails. The record cannot be moved undetected even though the host holds every byte of it."
+        },
+        "nonce": {
+          "type": "string",
+          "description": "AEAD nonce, base64url."
+        },
+        "epoch": {
+          "type": "integer",
+          "minimum": 1,
+          "description": "The key epoch this record was sealed under. Cleartext because the host must serve the right ciphertext, and bound into the associated data so that relabelling it fails authentication rather than causing a reader to try the wrong key."
+        }
+      }
+    }
+  }
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the request variant, from this specification's
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
+ */
+export const SPEC = {
+  typeUri: TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: PAYLOAD_SCHEMA,
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export const RESPONSE_SPEC = {
+  typeUri: RESPONSE_TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+} as const;

package/src/rooms/owner/invite/0.1/payload.ts

@@ -0,0 +1,212 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/rooms/owner/invite/0.1/payload.schema.json
+ */
+
+import type { Ext } from "../../../../_shared/components.js";
+
+
+export interface RoomsOwnerInvitePayload {
+  /**
+   * The room whose identity issues this credential. The recipient MUST hold a signing key for it — it is signing AS the room, not as itself.
+   */
+  roomId: string;
+  /**
+   * Which held key signs. Named explicitly rather than looked up from `roomId`, because nothing maps a DID to a key it was minted with and inventing that mapping would add a lifecycle to get wrong. A key that is not the room's produces a credential that fails to verify against the room's DID document — loud, and at the first use rather than later.
+   */
+  signingKeyId: string;
+  /**
+   * Ecosystem-defined extension members per SPEC.md §4.5.1.
+   */
+  ext?: Ext;
+  /**
+   * The party being invited. Named in the credential, which is why a VIC is single-use and why it is not presented on every access: presenting one would disclose the member.
+   */
+  subject: string;
+  /**
+   * When the invitation expires. An invitation that never expires is a standing right to enter, held by whoever ends up with the bytes.
+   */
+  validUntil?: string;
+}
+/**
+ * Success response to rooms/owner/invite. Type https://trusttasks.org/spec/rooms/owner/invite/0.1#response. The signed VIC, for delivery to the invitee.
+ */
+export interface RoomsOwnerInviteResponsePayload {
+  /**
+   * The signed Verifiable Invitation Credential, serialised.
+   */
+  credential: string;
+  /**
+   * Its `id`. The owner tracks consumption by this on a `private` room, where a host-side invitation store would hand the host the membership at invite time.
+   */
+  credentialId: string;
+  ext?: Ext;
+}
+
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { Ext };
+
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/rooms/owner/invite/0.1" as const;
+
+/** Stable alias for this specification's request payload shape. */
+export type Payload = RoomsOwnerInvitePayload;
+
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/rooms/owner/invite/0.1#response" as const;
+
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = RoomsOwnerInviteResponsePayload;
+
+/**
+ * This specification's payload schema, as a value.
+ *
+ * SPEC.md §7.2 item 2 is performed against this. It is shipped as data
+ * rather than only as a `.json` file because TypeScript types are erased
+ * at runtime: without a schema a consumer has nothing to validate, and
+ * every REQUIRED payload member is optional in practice. Cross-file
+ * `$ref`s are already inlined, so it needs no resolver.
+ */
+export const PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://trusttasks.org/spec/rooms/owner/invite/0.1",
+  "title": "Rooms Owner Invite — payload",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "roomId",
+    "signingKeyId",
+    "subject"
+  ],
+  "properties": {
+    "roomId": {
+      "type": "string",
+      "description": "The room whose identity issues this credential. The recipient MUST hold a signing key for it — it is signing AS the room, not as itself."
+    },
+    "signingKeyId": {
+      "type": "string",
+      "maxLength": 256,
+      "description": "Which held key signs. Named explicitly rather than looked up from `roomId`, because nothing maps a DID to a key it was minted with and inventing that mapping would add a lifecycle to get wrong. A key that is not the room's produces a credential that fails to verify against the room's DID document — loud, and at the first use rather than later."
+    },
+    "ext": {
+      "$ref": "#/$defs/Ext",
+      "description": "Ecosystem-defined extension members per SPEC.md §4.5.1."
+    },
+    "subject": {
+      "type": "string",
+      "description": "The party being invited. Named in the credential, which is why a VIC is single-use and why it is not presented on every access: presenting one would disclose the member."
+    },
+    "validUntil": {
+      "type": "string",
+      "format": "date-time",
+      "description": "When the invitation expires. An invitation that never expires is a standing right to enter, held by whoever ends up with the bytes."
+    }
+  },
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Rooms Owner Invite — response payload",
+      "description": "Success response to rooms/owner/invite. Type https://trusttasks.org/spec/rooms/owner/invite/0.1#response. The signed VIC, for delivery to the invitee.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "credential",
+        "credentialId"
+      ],
+      "properties": {
+        "credential": {
+          "type": "string",
+          "description": "The signed Verifiable Invitation Credential, serialised."
+        },
+        "credentialId": {
+          "type": "string",
+          "description": "Its `id`. The owner tracks consumption by this on a `private` room, where a host-side invitation store would hand the host the membership at invite time."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Rooms Owner Invite — response payload",
+      "description": "Success response to rooms/owner/invite. Type https://trusttasks.org/spec/rooms/owner/invite/0.1#response. The signed VIC, for delivery to the invitee.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "credential",
+        "credentialId"
+      ],
+      "properties": {
+        "credential": {
+          "type": "string",
+          "description": "The signed Verifiable Invitation Credential, serialised."
+        },
+        "credentialId": {
+          "type": "string",
+          "description": "Its `id`. The owner tracks consumption by this on a `private` room, where a host-side invitation store would hand the host the membership at invite time."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the request variant, from this specification's
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
+ */
+export const SPEC = {
+  typeUri: TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: PAYLOAD_SCHEMA,
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export const RESPONSE_SPEC = {
+  typeUri: RESPONSE_TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+} as const;