@openvtc/trust-tasks 0.19.6 → 0.19.8

package/dist/vta/backup/put-chunk/1.0/payload.js

@@ -0,0 +1,265 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/vta/backup/put-chunk/1.0/payload.schema.json
+ */
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/vta/backup/put-chunk/1.0";
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/vta/backup/put-chunk/1.0#response";
+/**
+ * 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/vta/backup/put-chunk/1.0",
+    "title": "VTA Backup — Put Chunk — payload",
+    "description": "Writes one chunk of a `chunkedTrustTask` import bundle, by index, into a slot opened by initiate-import. Idempotent for identical bytes; bytes that do not match the pre-committed manifest are refused. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3.",
+    "type": "object",
+    "additionalProperties": false,
+    "required": [
+        "bundleId",
+        "index",
+        "digestMultibase",
+        "data"
+    ],
+    "properties": {
+        "bundleId": {
+            "$ref": "#/$defs/BundleId",
+            "description": "Handle from the initiate-import descriptor. Opaque: a producer quotes what it was given and must not derive, guess or enumerate one."
+        },
+        "index": {
+            "$ref": "#/$defs/ChunkIndex",
+            "description": "Which chunk. Zero-based, below the manifest's chunkCount."
+        },
+        "digestMultibase": {
+            "$ref": "#/$defs/DigestMultibase",
+            "description": "Digest of this chunk's raw bytes, restating the manifest entry for `index`. Restated so that a chunk sent to the wrong index is refused as a mismatch against the manifest at the index it names, rather than surviving until reassembly — the recipient checks this member against the manifest and `data` against both."
+        },
+        "data": {
+            "$ref": "#/$defs/ChunkData"
+        },
+        "ext": {
+            "$ref": "#/$defs/Ext",
+            "description": "Ecosystem-defined extension members per SPEC.md §4.5.1."
+        }
+    },
+    "$defs": {
+        "Response": {
+            "$anchor": "response",
+            "title": "VTA Backup Put Chunk — response payload",
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "bundleId",
+                "index",
+                "stored",
+                "remainingCount",
+                "expiresAt"
+            ],
+            "properties": {
+                "bundleId": {
+                    "$ref": "#/$defs/BundleId",
+                    "description": "Echoed so the response stands alone as the acknowledgement of one write."
+                },
+                "index": {
+                    "$ref": "#/$defs/ChunkIndex",
+                    "description": "Echoed, so an acknowledgement arriving out of order is attributable to its write."
+                },
+                "stored": {
+                    "type": "boolean",
+                    "description": "Whether this request is what stored the chunk. False means the recipient already held identical bytes at this index — a success, not a failure, and the reason a write can be retried safely. Required rather than optional: an absent member on an idempotent repeat would be indistinguishable from a first write."
+                },
+                "remainingCount": {
+                    "type": "integer",
+                    "minimum": 0,
+                    "maximum": 4095,
+                    "description": "How many indices the slot still lacks after this write. Zero means the upload is complete and finalize-import can be sent."
+                },
+                "expiresAt": {
+                    "$ref": "#/$defs/ExpiresAt",
+                    "description": "The slot's current expiry, after any extension this write earned."
+                },
+                "ext": {
+                    "$ref": "#/$defs/Ext",
+                    "description": "Ecosystem-defined extension members per SPEC.md §4.5.1."
+                }
+            }
+        },
+        "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-]+)+$"
+            }
+        },
+        "ExpiresAt": {
+            "title": "ExpiresAt",
+            "description": "After which the bundle is collected: staged bytes discarded, tokens and chunk requests refused. Short by design. For a chunked transfer a recipient may move it later as chunks are exchanged, never past its own ceiling — each chunk response reports the current value.",
+            "type": "string",
+            "format": "date-time"
+        },
+        "ChunkIndex": {
+            "title": "ChunkIndex",
+            "description": "Zero-based position of a chunk within its bundle. Valid values are 0 to chunkCount − 1; an index outside that range is refused with chunkOutOfRange rather than validated here, because the bound depends on the bundle.",
+            "type": "integer",
+            "minimum": 0,
+            "maximum": 4095
+        },
+        "BundleId": {
+            "title": "BundleId",
+            "description": "Handle for a bundle across its whole lifecycle. Recipient-generated and unguessable, which is what lets an unauthorized reference be answered as not-found without confirming existence. Opaque: a producer quotes what it was given and must not derive, guess or enumerate one.",
+            "type": "string",
+            "pattern": "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$"
+        },
+        "ChunkData": {
+            "title": "ChunkData",
+            "description": "The chunk's bytes, base64url-encoded without padding (RFC 4648 §5). Bounded at 349526 characters, the unpadded encoding of a 262144-byte chunk. These are bytes of the encrypted bundle, so a chunk read in isolation reveals nothing of the agent's state — but a complete set of chunks is the export, and is to be handled as such.",
+            "type": "string",
+            "minLength": 2,
+            "maxLength": 349526,
+            "pattern": "^[A-Za-z0-9_-]+$"
+        },
+        "DigestMultibase": {
+            "title": "DigestMultibase",
+            "description": "A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.\n\nMultihash carries the hash algorithm in-band, so the value is self-describing and the wire format survives an algorithm change without a schema revision; multibase does the same for the base encoding, so a verifier never infers base58 from base64url by context. A bare hex string or a `sha-256:`-style prefix hard-codes one algorithm into the wire contract and is non-conforming here.\n\nThis definition constrains the *encoding only*. What the digest is computed over is stated by each referencing field, because it differs legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS) canonicalization, while a digest over an opaque artifact is taken over its bytes. A field whose input is a JSON document and which does not name a canonicalization is not reproducible.\n\nRestricted to the two multibase headers W3C Controlled Identifiers 1.0 §2.4 normatively requires — `z` (base58btc) and `u` (base64url-no-pad). CID permits others but states that \"interoperability is not guaranteed between implementations using such values\", and a registry whose purpose is interoperability should not mint digests a conforming verifier may be unable to read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I and l, and an earlier permissive pattern let three published examples carry digests that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with `did:key` and `did:webvh`.",
+            "type": "string",
+            "minLength": 16,
+            "pattern": "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$",
+            "examples": [
+                "zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"
+            ]
+        }
+    }
+};
+/** 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": "VTA Backup Put Chunk — response payload",
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "bundleId",
+                "index",
+                "stored",
+                "remainingCount",
+                "expiresAt"
+            ],
+            "properties": {
+                "bundleId": {
+                    "$ref": "#/$defs/BundleId",
+                    "description": "Echoed so the response stands alone as the acknowledgement of one write."
+                },
+                "index": {
+                    "$ref": "#/$defs/ChunkIndex",
+                    "description": "Echoed, so an acknowledgement arriving out of order is attributable to its write."
+                },
+                "stored": {
+                    "type": "boolean",
+                    "description": "Whether this request is what stored the chunk. False means the recipient already held identical bytes at this index — a success, not a failure, and the reason a write can be retried safely. Required rather than optional: an absent member on an idempotent repeat would be indistinguishable from a first write."
+                },
+                "remainingCount": {
+                    "type": "integer",
+                    "minimum": 0,
+                    "maximum": 4095,
+                    "description": "How many indices the slot still lacks after this write. Zero means the upload is complete and finalize-import can be sent."
+                },
+                "expiresAt": {
+                    "$ref": "#/$defs/ExpiresAt",
+                    "description": "The slot's current expiry, after any extension this write earned."
+                },
+                "ext": {
+                    "$ref": "#/$defs/Ext",
+                    "description": "Ecosystem-defined extension members per SPEC.md §4.5.1."
+                }
+            }
+        },
+        "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-]+)+$"
+            }
+        },
+        "ExpiresAt": {
+            "title": "ExpiresAt",
+            "description": "After which the bundle is collected: staged bytes discarded, tokens and chunk requests refused. Short by design. For a chunked transfer a recipient may move it later as chunks are exchanged, never past its own ceiling — each chunk response reports the current value.",
+            "type": "string",
+            "format": "date-time"
+        },
+        "ChunkIndex": {
+            "title": "ChunkIndex",
+            "description": "Zero-based position of a chunk within its bundle. Valid values are 0 to chunkCount − 1; an index outside that range is refused with chunkOutOfRange rather than validated here, because the bound depends on the bundle.",
+            "type": "integer",
+            "minimum": 0,
+            "maximum": 4095
+        },
+        "BundleId": {
+            "title": "BundleId",
+            "description": "Handle for a bundle across its whole lifecycle. Recipient-generated and unguessable, which is what lets an unauthorized reference be answered as not-found without confirming existence. Opaque: a producer quotes what it was given and must not derive, guess or enumerate one.",
+            "type": "string",
+            "pattern": "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$"
+        },
+        "ChunkData": {
+            "title": "ChunkData",
+            "description": "The chunk's bytes, base64url-encoded without padding (RFC 4648 §5). Bounded at 349526 characters, the unpadded encoding of a 262144-byte chunk. These are bytes of the encrypted bundle, so a chunk read in isolation reveals nothing of the agent's state — but a complete set of chunks is the export, and is to be handled as such.",
+            "type": "string",
+            "minLength": 2,
+            "maxLength": 349526,
+            "pattern": "^[A-Za-z0-9_-]+$"
+        },
+        "DigestMultibase": {
+            "title": "DigestMultibase",
+            "description": "A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.\n\nMultihash carries the hash algorithm in-band, so the value is self-describing and the wire format survives an algorithm change without a schema revision; multibase does the same for the base encoding, so a verifier never infers base58 from base64url by context. A bare hex string or a `sha-256:`-style prefix hard-codes one algorithm into the wire contract and is non-conforming here.\n\nThis definition constrains the *encoding only*. What the digest is computed over is stated by each referencing field, because it differs legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS) canonicalization, while a digest over an opaque artifact is taken over its bytes. A field whose input is a JSON document and which does not name a canonicalization is not reproducible.\n\nRestricted to the two multibase headers W3C Controlled Identifiers 1.0 §2.4 normatively requires — `z` (base58btc) and `u` (base64url-no-pad). CID permits others but states that \"interoperability is not guaranteed between implementations using such values\", and a registry whose purpose is interoperability should not mint digests a conforming verifier may be unable to read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I and l, and an earlier permissive pattern let three published examples carry digests that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with `did:key` and `did:webvh`.",
+            "type": "string",
+            "minLength": 16,
+            "pattern": "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$",
+            "examples": [
+                "zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"
+            ]
+        }
+    }
+};
+/**
+ * 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,
+};
+/**
+ * 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: false,
+    isRecipientRequired: true,
+    isIssuedAtRequired: true,
+    payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+};
+//# sourceMappingURL=payload.js.map

package/dist/vta/backup/put-chunk/1.0/payload.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../src/vta/backup/put-chunk/1.0/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAyDH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,sDAA+D,CAAC;AAKxF,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,+DAAwE,CAAC;AAK1G;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,cAAc,GAAG;IAC5B,SAAS,EAAE,8CAA8C;IACzD,KAAK,EAAE,sDAAsD;IAC7D,OAAO,EAAE,kCAAkC;IAC3C,aAAa,EAAE,uUAAuU;IACtV,MAAM,EAAE,QAAQ;IAChB,sBAAsB,EAAE,KAAK;IAC7B,UAAU,EAAE;QACV,UAAU;QACV,OAAO;QACP,iBAAiB;QACjB,MAAM;KACP;IACD,YAAY,EAAE;QACZ,UAAU,EAAE;YACV,MAAM,EAAE,kBAAkB;YAC1B,aAAa,EAAE,sIAAsI;SACtJ;QACD,OAAO,EAAE;YACP,MAAM,EAAE,oBAAoB;YAC5B,aAAa,EAAE,2DAA2D;SAC3E;QACD,iBAAiB,EAAE;YACjB,MAAM,EAAE,yBAAyB;YACjC,aAAa,EAAE,2TAA2T;SAC3U;QACD,MAAM,EAAE;YACN,MAAM,EAAE,mBAAmB;SAC5B;QACD,KAAK,EAAE;YACL,MAAM,EAAE,aAAa;YACrB,aAAa,EAAE,yDAAyD;SACzE;KACF;IACD,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,yCAAyC;YAClD,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,UAAU;gBACV,OAAO;gBACP,QAAQ;gBACR,gBAAgB;gBAChB,WAAW;aACZ;YACD,YAAY,EAAE;gBACZ,UAAU,EAAE;oBACV,MAAM,EAAE,kBAAkB;oBAC1B,aAAa,EAAE,0EAA0E;iBAC1F;gBACD,OAAO,EAAE;oBACP,MAAM,EAAE,oBAAoB;oBAC5B,aAAa,EAAE,mFAAmF;iBACnG;gBACD,QAAQ,EAAE;oBACR,MAAM,EAAE,SAAS;oBACjB,aAAa,EAAE,sTAAsT;iBACtU;gBACD,gBAAgB,EAAE;oBAChB,MAAM,EAAE,SAAS;oBACjB,SAAS,EAAE,CAAC;oBACZ,SAAS,EAAE,IAAI;oBACf,aAAa,EAAE,4HAA4H;iBAC5I;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,mBAAmB;oBAC3B,aAAa,EAAE,mEAAmE;iBACnF;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;oBACrB,aAAa,EAAE,yDAAyD;iBACzE;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;QACD,WAAW,EAAE;YACX,OAAO,EAAE,WAAW;YACpB,aAAa,EAAE,4QAA4Q;YAC3R,MAAM,EAAE,QAAQ;YAChB,QAAQ,EAAE,WAAW;SACtB;QACD,YAAY,EAAE;YACZ,OAAO,EAAE,YAAY;YACrB,aAAa,EAAE,0NAA0N;YACzO,MAAM,EAAE,SAAS;YACjB,SAAS,EAAE,CAAC;YACZ,SAAS,EAAE,IAAI;SAChB;QACD,UAAU,EAAE;YACV,OAAO,EAAE,UAAU;YACnB,aAAa,EAAE,mRAAmR;YAClS,MAAM,EAAE,QAAQ;YAChB,SAAS,EAAE,+EAA+E;SAC3F;QACD,WAAW,EAAE;YACX,OAAO,EAAE,WAAW;YACpB,aAAa,EAAE,wUAAwU;YACvV,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,CAAC;YACd,WAAW,EAAE,MAAM;YACnB,SAAS,EAAE,kBAAkB;SAC9B;QACD,iBAAiB,EAAE;YACjB,OAAO,EAAE,iBAAiB;YAC1B,aAAa,EAAE,gnDAAgnD;YAC/nD,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,EAAE;YACf,SAAS,EAAE,4CAA4C;YACvD,UAAU,EAAE;gBACV,iDAAiD;aAClD;SACF;KACF;CACO,CAAC;AAEX,mEAAmE;AACnE,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACrC,SAAS,EAAE,8CAA8C;IACzD,MAAM,EAAE,kBAAkB;IAC1B,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,yCAAyC;YAClD,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,UAAU;gBACV,OAAO;gBACP,QAAQ;gBACR,gBAAgB;gBAChB,WAAW;aACZ;YACD,YAAY,EAAE;gBACZ,UAAU,EAAE;oBACV,MAAM,EAAE,kBAAkB;oBAC1B,aAAa,EAAE,0EAA0E;iBAC1F;gBACD,OAAO,EAAE;oBACP,MAAM,EAAE,oBAAoB;oBAC5B,aAAa,EAAE,mFAAmF;iBACnG;gBACD,QAAQ,EAAE;oBACR,MAAM,EAAE,SAAS;oBACjB,aAAa,EAAE,sTAAsT;iBACtU;gBACD,gBAAgB,EAAE;oBAChB,MAAM,EAAE,SAAS;oBACjB,SAAS,EAAE,CAAC;oBACZ,SAAS,EAAE,IAAI;oBACf,aAAa,EAAE,4HAA4H;iBAC5I;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,mBAAmB;oBAC3B,aAAa,EAAE,mEAAmE;iBACnF;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;oBACrB,aAAa,EAAE,yDAAyD;iBACzE;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;QACD,WAAW,EAAE;YACX,OAAO,EAAE,WAAW;YACpB,aAAa,EAAE,4QAA4Q;YAC3R,MAAM,EAAE,QAAQ;YAChB,QAAQ,EAAE,WAAW;SACtB;QACD,YAAY,EAAE;YACZ,OAAO,EAAE,YAAY;YACrB,aAAa,EAAE,0NAA0N;YACzO,MAAM,EAAE,SAAS;YACjB,SAAS,EAAE,CAAC;YACZ,SAAS,EAAE,IAAI;SAChB;QACD,UAAU,EAAE;YACV,OAAO,EAAE,UAAU;YACnB,aAAa,EAAE,mRAAmR;YAClS,MAAM,EAAE,QAAQ;YAChB,SAAS,EAAE,+EAA+E;SAC3F;QACD,WAAW,EAAE;YACX,OAAO,EAAE,WAAW;YACpB,aAAa,EAAE,wUAAwU;YACvV,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,CAAC;YACd,WAAW,EAAE,MAAM;YACnB,SAAS,EAAE,kBAAkB;SAC9B;QACD,iBAAiB,EAAE;YACjB,OAAO,EAAE,iBAAiB;YAC1B,aAAa,EAAE,gnDAAgnD;YAC/nD,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,EAAE;YACf,SAAS,EAAE,4CAA4C;YACvD,UAAU,EAAE;gBACV,iDAAiD;aAClD;SACF;KACF;CACO,CAAC;AAEX;;;;;GAKG;AACH,MAAM,CAAC,MAAM,IAAI,GAAG;IAClB,OAAO,EAAE,QAAQ;IACjB,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,IAAI;IACzB,kBAAkB,EAAE,IAAI;IACxB,aAAa,EAAE,cAAc;CACrB,CAAC;AAEX;;;;GAIG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG;IAC3B,OAAO,EAAE,iBAAiB;IAC1B,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,KAAK;IACtB,mBAAmB,EAAE,IAAI;IACzB,kBAAkB,EAAE,IAAI;IACxB,aAAa,EAAE,uBAAuB;CAC9B,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openvtc/trust-tasks",
-  "version": "0.19.6",
+  "version": "0.19.8",
   "description": "Generated TypeScript bindings for the Trust Tasks framework registry.",
   "type": "module",
   "main": "./dist/index.js",

package/src/_shared/components.ts

@@ -42,6 +42,14 @@ export type AuditAction =
   | "accountChangeQueueLimits"
   | "adminAdd"
   | "adminStrip";
+/**
+ * The control-plane account of a bundle transfer: which algorithm, on what terms, until when. Exactly one of the two shapes — they are mutually exclusive, since StreamDescriptor requires `transportUrl` and `transportToken` and forbids `chunks`, and ChunkedDescriptor requires `chunks` and forbids both.
+ */
+export type BundleDescriptor = StreamDescriptor | ChunkedDescriptor;
+/**
+ * Handle for a bundle across its whole lifecycle. Recipient-generated and unguessable, which is what lets an unauthorized reference be answered as not-found without confirming existence. Opaque: a producer quotes what it was given and must not derive, guess or enumerate one.
+ */
+export type BundleId = string;
 /**
  * A calendar date, `YYYY-MM-DD` (RFC 3339 full-date), with no time or zone. Compared as a UTC date.
  */
@@ -82,6 +90,22 @@ export type Capability_DeviceV0_2 =
   | "memoryWrite"
   | "roomPresent"
   | "roomOpen";
+/**
+ * Number of chunks in the bundle, equal to ceil(expectedSizeBytes / chunkSize). Bounded at 4096 so that the manifest itself — one digest per chunk — fits in the single document that carries it under the same message-size reasoning as a chunk.
+ */
+export type ChunkCount = number;
+/**
+ * The chunk's bytes, base64url-encoded without padding (RFC 4648 §5). Bounded at 349526 characters, the unpadded encoding of a 262144-byte chunk. These are bytes of the encrypted bundle, so a chunk read in isolation reveals nothing of the agent's state — but a complete set of chunks is the export, and is to be handled as such.
+ */
+export type ChunkData = string;
+/**
+ * Zero-based position of a chunk within its bundle. Valid values are 0 to chunkCount − 1; an index outside that range is refused with chunkOutOfRange rather than validated here, because the bound depends on the bundle.
+ */
+export type ChunkIndex = number;
+/**
+ * Size in bytes of every chunk except the last, which carries the remainder and is between 1 and this value inclusive. The ceiling of 262144 (256 KiB) is normative and is derived in `vta/backup/initiate-export/1.1` under Chunked transfer: it is the largest power of two whose `get-chunk` or `put-chunk` document still fits a 1 MiB mediator message after base64url encoding of `data`, DIDComm authcrypt encoding, and two nested forward wrappers. The floor of 16384 keeps a 1 GiB bundle within `ChunkCount`'s ceiling at sizes a constrained transport can still choose.
+ */
+export type ChunkSize = number;
 /**
  * The vocabulary token naming what a value IS — `name.legal`, `phone.mobile`, `address.postal`, `person.birthDate`. Dotted, most-general segment first, so that a consumer with no knowledge of the specific token can still group by its prefix.
  *
@@ -165,6 +189,14 @@ export type DigestMultibase = string;
  * Whether the subject is permitted. The ABSENCE of any grant is treated as `deny` (default-deny).
  */
 export type Effect_ConsentV0_1 = "allow" | "deny";
+/**
+ * Lowercase hex SHA-256 of the whole bundle's bytes. Kept in the hex form the 1.0 descriptor published rather than moved to DigestMultibase, because it is an unchanged member of an existing descriptor and re-encoding it would break every stream producer for no gain in what it checks. For a chunked transfer it is the check over the reassembled bundle, applied after every chunk has verified individually, so that a correct set of chunks assembled in the wrong order is still caught.
+ */
+export type ExpectedSha256 = string;
+/**
+ * Total byte count of the bundle. A zero-length bundle is not a degenerate success — nothing was serialized — so the floor is 1.
+ */
+export type ExpectedSizeBytes = number;
 /**
  * Optimistic-concurrency precondition. A positive value requires the record's current `version` to equal it exactly; zero means create-only and applies only when no live record exists at the address.
  */
@@ -173,6 +205,10 @@ export type ExpectedVersion_PersonaV0_1 = number;
  * Optimistic-concurrency precondition on a write. A positive value requires that the record's current `version` equals it exactly. Zero means "create only" — the write applies only if no LIVE record exists at the address, which is what makes lease acquisition safe: without it two instances can each read "absent", each write, and each believe it won. A tombstone is not a live record, so `expectedVersion: 0` succeeds over one; the created record takes the namespace's next counter value, which is necessarily greater than the tombstone's.
  */
 export type ExpectedVersion_VtaV0_1 = number;
+/**
+ * After which the bundle is collected: staged bytes discarded, tokens and chunk requests refused. Short by design. For a chunked transfer a recipient may move it later as chunks are exchanged, never past its own ceiling — each chunk response reports the current value.
+ */
+export type ExpiresAt = string;
 /**
  * A colour **name**, resolved by each consumer against its own palette — never a hex value or any other literal. Two reasons, and both are about the consumer rather than the holder. A literal cannot be legible in a terminal, in a light theme and in a dark one at once, so a stored `#8B0000` is a colour that is wrong somewhere and the holder has no way to know where. And a consumer that reserves colours to mean something — an error, a warning, an irreversible act — must be able to keep a holder's decorative choice out of that channel; it cannot do that with an arbitrary value, and it can do it trivially with a closed set it maps itself. The eight members are chosen to be distinguishable from one another and deliberately carry no status connotation: none is named for success, warning or danger.
  */
@@ -210,9 +246,9 @@ export type KeyOrigin = "derived" | "imported" | "internal";
  */
 export type KeyStatus = "active" | "revoked";
 /**
- * Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256).
+ * Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256), and `mldsa44` and `mldsa65` sign with the post-quantum ML-DSA scheme of US NIST FIPS 204. The set is expected to grow as algorithms are standardised, and growing it is a MINOR change under SPEC.md §5.2: `keyType` selects no schema branch, so adding a value relaxes a constraint rather than narrowing one, and the generated libraries mark this enumeration non-exhaustive so that a consumer absorbs a new value rather than failing to compile. Two ML-DSA parameter sets are carried because two specifications require different ones — W3C Quantum-Resistant Cryptosuites defines Data Integrity suites only for ML-DSA-44, while Trust Spanning Protocol Rev 3 §8.1 mandates ML-DSA-65 — so the parameter set is chosen by whatever consumes the key and the two are not redundant. A consumer that does not implement a value it receives MUST refuse the document rather than substitute one it does support.
  */
-export type KeyType = "ed25519" | "x25519" | "p256";
+export type KeyType = "ed25519" | "x25519" | "p256" | "mldsa44" | "mldsa65";
 /**
  * The interaction kind: a 1:1 direct message, a multi-party group, or a broadcast channel.
  */
@@ -459,9 +495,9 @@ export type Sensitivity = "normal" | "high";
  */
 export type ServiceKind = "didcomm" | "rest" | "tsp" | "webauthn";
 /**
- * `EdDSA` pairs with an `ed25519` key; `ES256` pairs with a `p256` key. An `x25519` key performs key agreement and can sign nothing, so no algorithm here is valid for one. The enumeration is closed: an unrecognised algorithm is refused rather than silently substituted with a supported one.
+ * `EdDSA` pairs with an `ed25519` key; `ES256` pairs with a `p256` key; `ML-DSA-44` and `ML-DSA-65` pair with `mldsa44` and `mldsa65` keys respectively. An `x25519` key performs key agreement and can sign nothing, so no algorithm here is valid for one. These are JOSE algorithm identifiers, externally owned, so they are carried verbatim and never re-cased (SPEC.md §4.10 rule 5); the ML-DSA names are those RFC 9964 registers in the JOSE Web Signature and Encryption Algorithms registry, which is why their hyphenated casing differs from the `keyType` values beside them — those are specification-defined. The set is expected to grow as algorithms are registered. The enumeration remains closed: an unrecognised algorithm is refused rather than silently substituted with a supported one.
  */
-export type SignAlgorithm = "EdDSA" | "ES256";
+export type SignAlgorithm = "EdDSA" | "ES256" | "ML-DSA-44" | "ML-DSA-65";
 /**
  * A single binding target for a vault entry. Tagged union over the discriminator `kind`. A VaultEntry's `targets` array MAY mix any number of these.
  */
@@ -1249,6 +1285,36 @@ export interface CapabilityManifest {
   configSchema?: string;
   ext?: Ext;
 }
+/**
+ * The terms of a `chunkedTrustTask` transfer, committed before any chunk moves. On export the recipient states them in the descriptor; on import the producer pre-commits them in the request and the recipient echoes them. Either way the manifest arrives in a document whose proof is REQUIRED, so the per-chunk digests are authenticated by the party that computed them and each chunk can be verified — and a single bad chunk re-fetched or refused — on arrival rather than only after reassembly.
+ *
+ * Consistency rules JSON Schema cannot state: `chunkCount` MUST equal ceil(expectedSizeBytes / chunkSize) for the bundle the manifest describes, and `chunkDigests` MUST have exactly `chunkCount` items. A party receiving a manifest violating either MUST refuse it.
+ */
+export interface ChunkManifest {
+  chunkSize: ChunkSize;
+  chunkCount: ChunkCount;
+  /**
+   * Digest of each chunk's raw bytes (not of its base64url encoding), in index order. Compared as decoded multihash bytes, never as encoded strings. sha2-256 is RECOMMENDED and MUST be implemented by every party; a party that does not implement the hash a digest names MUST treat the manifest as unverifiable rather than skip the check.
+   *
+   * @minItems 1
+   * @maxItems 4096
+   */
+  chunkDigests: [DigestMultibase, ...DigestMultibase[]];
+}
+/**
+ * A descriptor for the `chunkedTrustTask` algorithm. Carries no address and no bearer token: every chunk moves in a Trust Task document whose sender the transport authenticates, so possession of a token would add nothing and would be one more secret to leak.
+ */
+export interface ChunkedDescriptor {
+  bundleId: BundleId;
+  /**
+   * Discriminates this shape from StreamDescriptor.
+   */
+  algorithm: "chunkedTrustTask";
+  chunks: ChunkManifest;
+  expectedSha256: ExpectedSha256;
+  expectedSizeBytes: ExpectedSizeBytes;
+  expiresAt: ExpiresAt;
+}
 /**
  * A community profile as a portable export carries it — the mutable profile members plus the immutable identity they belong to.
  *
@@ -3445,6 +3511,27 @@ export interface StepUpProof_VaultV0_2 {
    */
   challengeId: string;
 }
+/**
+ * A descriptor for a transfer that happens outside Trust Task documents, at an address the recipient publishes — the `stream` algorithm, and any other algorithm a recipient offers that is shaped as an address plus a bearer credential. Identical in members to the `vta/backup/* /1.0` descriptor.
+ */
+export interface StreamDescriptor {
+  bundleId: BundleId;
+  /**
+   * The mechanism in use. Never `chunkedTrustTask`, which has its own descriptor shape; a descriptor naming it with a transport address is malformed.
+   */
+  algorithm: string;
+  /**
+   * Where to fetch (export) or write (import) the bytes. A recipient with no address at which it is reachable cannot produce this and refuses with transportUnavailable rather than returning an unusable one. An import address is write-only: staged bytes are never served back from it.
+   */
+  transportUrl: string;
+  /**
+   * Bearer credential for transportUrl, presented in the X-Backup-Token header. Minted per bundle and never reused. A recipient should store only a hash of it, and should accept an export token once.
+   */
+  transportToken: string;
+  expectedSha256: ExpectedSha256;
+  expectedSizeBytes: ExpectedSizeBytes;
+  expiresAt: ExpiresAt;
+}
 /**
  * An access token (typically short-lived JWT) paired with an optional refresh token (typically long-lived opaque string). The shapes follow OAuth 2.0 (RFC 6749 §5.1) conventions but are not coupled to any particular OAuth profile.
  */

package/src/index.ts

@@ -335,6 +335,7 @@ export * as VettingSession_v0_1 from "./vetting/session/0.1/payload.js";
 export * as VrcRelationshipsIssue_v0_1 from "./vrc/relationships/issue/0.1/payload.js";
 export * as VrcRelationshipsPropose_v0_1 from "./vrc/relationships/propose/0.1/payload.js";
 export * as AppStateRecordShared_v0_1 from "./vta/_shared/0.1/app-state-record.js";
+export * as BackupTransferShared_v0_1 from "./vta/_shared/0.1/backup-transfer.js";
 export * as ContextShared_v0_1 from "./vta/_shared/0.1/context.js";
 export * as DidTemplateShared_v0_1 from "./vta/_shared/0.1/did-template.js";
 export * as PasskeyVmShared_v0_1 from "./vta/_shared/0.1/passkey-vm.js";
@@ -349,8 +350,13 @@ export * as VtaAppStatePut_v1_0 from "./vta/app-state/put/1.0/payload.js";
 export * as VtaBackupAbort_v1_0 from "./vta/backup/abort/1.0/payload.js";
 export * as VtaBackupCompleteExport_v1_0 from "./vta/backup/complete-export/1.0/payload.js";
 export * as VtaBackupFinalizeImport_v1_0 from "./vta/backup/finalize-import/1.0/payload.js";
+export * as VtaBackupFinalizeImport_v1_1 from "./vta/backup/finalize-import/1.1/payload.js";
+export * as VtaBackupGetChunk_v1_0 from "./vta/backup/get-chunk/1.0/payload.js";
 export * as VtaBackupInitiateExport_v1_0 from "./vta/backup/initiate-export/1.0/payload.js";
+export * as VtaBackupInitiateExport_v1_1 from "./vta/backup/initiate-export/1.1/payload.js";
 export * as VtaBackupInitiateImport_v1_0 from "./vta/backup/initiate-import/1.0/payload.js";
+export * as VtaBackupInitiateImport_v1_1 from "./vta/backup/initiate-import/1.1/payload.js";
+export * as VtaBackupPutChunk_v1_0 from "./vta/backup/put-chunk/1.0/payload.js";
 export * as VtaContextsCreate_v1_0 from "./vta/contexts/create/1.0/payload.js";
 export * as VtaContextsDelete_v1_0 from "./vta/contexts/delete/1.0/payload.js";
 export * as VtaContextsDidTemplatesCreate_v1_0 from "./vta/contexts/did-templates/create/1.0/payload.js";

package/src/keys/create/0.1/payload.ts

@@ -247,9 +247,11 @@ export const PAYLOAD_SCHEMA = {
       "enum": [
         "ed25519",
         "x25519",
-        "p256"
+        "p256",
+        "mldsa44",
+        "mldsa65"
       ],
-      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256)."
+      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256), and `mldsa44` and `mldsa65` sign with the post-quantum ML-DSA scheme of US NIST FIPS 204. The set is expected to grow as algorithms are standardised, and growing it is a MINOR change under SPEC.md §5.2: `keyType` selects no schema branch, so adding a value relaxes a constraint rather than narrowing one, and the generated libraries mark this enumeration non-exhaustive so that a consumer absorbs a new value rather than failing to compile. Two ML-DSA parameter sets are carried because two specifications require different ones — W3C Quantum-Resistant Cryptosuites defines Data Integrity suites only for ML-DSA-44, while Trust Spanning Protocol Rev 3 §8.1 mandates ML-DSA-65 — so the parameter set is chosen by whatever consumes the key and the two are not redundant. A consumer that does not implement a value it receives MUST refuse the document rather than substitute one it does support."
     }
   }
 } as const;
@@ -383,9 +385,11 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
       "enum": [
         "ed25519",
         "x25519",
-        "p256"
+        "p256",
+        "mldsa44",
+        "mldsa65"
       ],
-      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256)."
+      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256), and `mldsa44` and `mldsa65` sign with the post-quantum ML-DSA scheme of US NIST FIPS 204. The set is expected to grow as algorithms are standardised, and growing it is a MINOR change under SPEC.md §5.2: `keyType` selects no schema branch, so adding a value relaxes a constraint rather than narrowing one, and the generated libraries mark this enumeration non-exhaustive so that a consumer absorbs a new value rather than failing to compile. Two ML-DSA parameter sets are carried because two specifications require different ones — W3C Quantum-Resistant Cryptosuites defines Data Integrity suites only for ML-DSA-44, while Trust Spanning Protocol Rev 3 §8.1 mandates ML-DSA-65 — so the parameter set is chosen by whatever consumes the key and the two are not redundant. A consumer that does not implement a value it receives MUST refuse the document rather than substitute one it does support."
     }
   }
 } as const;

package/src/keys/derive-and-sign/0.1/payload.ts

@@ -151,9 +151,11 @@ export const PAYLOAD_SCHEMA = {
       "type": "string",
       "enum": [
         "EdDSA",
-        "ES256"
+        "ES256",
+        "ML-DSA-44",
+        "ML-DSA-65"
       ],
-      "description": "`EdDSA` pairs with an `ed25519` key; `ES256` pairs with a `p256` key. An `x25519` key performs key agreement and can sign nothing, so no algorithm here is valid for one. The enumeration is closed: an unrecognised algorithm is refused rather than silently substituted with a supported one."
+      "description": "`EdDSA` pairs with an `ed25519` key; `ES256` pairs with a `p256` key; `ML-DSA-44` and `ML-DSA-65` pair with `mldsa44` and `mldsa65` keys respectively. An `x25519` key performs key agreement and can sign nothing, so no algorithm here is valid for one. These are JOSE algorithm identifiers, externally owned, so they are carried verbatim and never re-cased (SPEC.md §4.10 rule 5); the ML-DSA names are those RFC 9964 registers in the JOSE Web Signature and Encryption Algorithms registry, which is why their hyphenated casing differs from the `keyType` values beside them — those are specification-defined. The set is expected to grow as algorithms are registered. The enumeration remains closed: an unrecognised algorithm is refused rather than silently substituted with a supported one."
     },
     "KeyType": {
       "title": "KeyType",
@@ -161,9 +163,11 @@ export const PAYLOAD_SCHEMA = {
       "enum": [
         "ed25519",
         "x25519",
-        "p256"
+        "p256",
+        "mldsa44",
+        "mldsa65"
       ],
-      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256)."
+      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256), and `mldsa44` and `mldsa65` sign with the post-quantum ML-DSA scheme of US NIST FIPS 204. The set is expected to grow as algorithms are standardised, and growing it is a MINOR change under SPEC.md §5.2: `keyType` selects no schema branch, so adding a value relaxes a constraint rather than narrowing one, and the generated libraries mark this enumeration non-exhaustive so that a consumer absorbs a new value rather than failing to compile. Two ML-DSA parameter sets are carried because two specifications require different ones — W3C Quantum-Resistant Cryptosuites defines Data Integrity suites only for ML-DSA-44, while Trust Spanning Protocol Rev 3 §8.1 mandates ML-DSA-65 — so the parameter set is chosen by whatever consumes the key and the two are not redundant. A consumer that does not implement a value it receives MUST refuse the document rather than substitute one it does support."
     }
   }
 } as const;
@@ -216,9 +220,11 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
       "type": "string",
       "enum": [
         "EdDSA",
-        "ES256"
+        "ES256",
+        "ML-DSA-44",
+        "ML-DSA-65"
       ],
-      "description": "`EdDSA` pairs with an `ed25519` key; `ES256` pairs with a `p256` key. An `x25519` key performs key agreement and can sign nothing, so no algorithm here is valid for one. The enumeration is closed: an unrecognised algorithm is refused rather than silently substituted with a supported one."
+      "description": "`EdDSA` pairs with an `ed25519` key; `ES256` pairs with a `p256` key; `ML-DSA-44` and `ML-DSA-65` pair with `mldsa44` and `mldsa65` keys respectively. An `x25519` key performs key agreement and can sign nothing, so no algorithm here is valid for one. These are JOSE algorithm identifiers, externally owned, so they are carried verbatim and never re-cased (SPEC.md §4.10 rule 5); the ML-DSA names are those RFC 9964 registers in the JOSE Web Signature and Encryption Algorithms registry, which is why their hyphenated casing differs from the `keyType` values beside them — those are specification-defined. The set is expected to grow as algorithms are registered. The enumeration remains closed: an unrecognised algorithm is refused rather than silently substituted with a supported one."
     },
     "KeyType": {
       "title": "KeyType",
@@ -226,9 +232,11 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
       "enum": [
         "ed25519",
         "x25519",
-        "p256"
+        "p256",
+        "mldsa44",
+        "mldsa65"
       ],
-      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256)."
+      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256), and `mldsa44` and `mldsa65` sign with the post-quantum ML-DSA scheme of US NIST FIPS 204. The set is expected to grow as algorithms are standardised, and growing it is a MINOR change under SPEC.md §5.2: `keyType` selects no schema branch, so adding a value relaxes a constraint rather than narrowing one, and the generated libraries mark this enumeration non-exhaustive so that a consumer absorbs a new value rather than failing to compile. Two ML-DSA parameter sets are carried because two specifications require different ones — W3C Quantum-Resistant Cryptosuites defines Data Integrity suites only for ML-DSA-44, while Trust Spanning Protocol Rev 3 §8.1 mandates ML-DSA-65 — so the parameter set is chosen by whatever consumes the key and the two are not redundant. A consumer that does not implement a value it receives MUST refuse the document rather than substitute one it does support."
     }
   }
 } as const;

package/src/keys/derive-and-sign-document/0.1/payload.ts

@@ -147,9 +147,11 @@ export const PAYLOAD_SCHEMA = {
       "enum": [
         "ed25519",
         "x25519",
-        "p256"
+        "p256",
+        "mldsa44",
+        "mldsa65"
       ],
-      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256)."
+      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256), and `mldsa44` and `mldsa65` sign with the post-quantum ML-DSA scheme of US NIST FIPS 204. The set is expected to grow as algorithms are standardised, and growing it is a MINOR change under SPEC.md §5.2: `keyType` selects no schema branch, so adding a value relaxes a constraint rather than narrowing one, and the generated libraries mark this enumeration non-exhaustive so that a consumer absorbs a new value rather than failing to compile. Two ML-DSA parameter sets are carried because two specifications require different ones — W3C Quantum-Resistant Cryptosuites defines Data Integrity suites only for ML-DSA-44, while Trust Spanning Protocol Rev 3 §8.1 mandates ML-DSA-65 — so the parameter set is chosen by whatever consumes the key and the two are not redundant. A consumer that does not implement a value it receives MUST refuse the document rather than substitute one it does support."
     }
   }
 } as const;
@@ -199,9 +201,11 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
       "enum": [
         "ed25519",
         "x25519",
-        "p256"
+        "p256",
+        "mldsa44",
+        "mldsa65"
       ],
-      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256)."
+      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256), and `mldsa44` and `mldsa65` sign with the post-quantum ML-DSA scheme of US NIST FIPS 204. The set is expected to grow as algorithms are standardised, and growing it is a MINOR change under SPEC.md §5.2: `keyType` selects no schema branch, so adding a value relaxes a constraint rather than narrowing one, and the generated libraries mark this enumeration non-exhaustive so that a consumer absorbs a new value rather than failing to compile. Two ML-DSA parameter sets are carried because two specifications require different ones — W3C Quantum-Resistant Cryptosuites defines Data Integrity suites only for ML-DSA-44, while Trust Spanning Protocol Rev 3 §8.1 mandates ML-DSA-65 — so the parameter set is chosen by whatever consumes the key and the two are not redundant. A consumer that does not implement a value it receives MUST refuse the document rather than substitute one it does support."
     }
   }
 } as const;

package/src/keys/export-secret/0.1/payload.ts

@@ -119,9 +119,11 @@ export const PAYLOAD_SCHEMA = {
       "enum": [
         "ed25519",
         "x25519",
-        "p256"
+        "p256",
+        "mldsa44",
+        "mldsa65"
       ],
-      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256)."
+      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256), and `mldsa44` and `mldsa65` sign with the post-quantum ML-DSA scheme of US NIST FIPS 204. The set is expected to grow as algorithms are standardised, and growing it is a MINOR change under SPEC.md §5.2: `keyType` selects no schema branch, so adding a value relaxes a constraint rather than narrowing one, and the generated libraries mark this enumeration non-exhaustive so that a consumer absorbs a new value rather than failing to compile. Two ML-DSA parameter sets are carried because two specifications require different ones — W3C Quantum-Resistant Cryptosuites defines Data Integrity suites only for ML-DSA-44, while Trust Spanning Protocol Rev 3 §8.1 mandates ML-DSA-65 — so the parameter set is chosen by whatever consumes the key and the two are not redundant. A consumer that does not implement a value it receives MUST refuse the document rather than substitute one it does support."
     },
     "Ext": {
       "title": "Ext",
@@ -180,9 +182,11 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
       "enum": [
         "ed25519",
         "x25519",
-        "p256"
+        "p256",
+        "mldsa44",
+        "mldsa65"
       ],
-      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256)."
+      "description": "Cryptographic algorithm the key material belongs to. `ed25519` signs (EdDSA), `x25519` performs key agreement and never signs, `p256` signs (ES256), and `mldsa44` and `mldsa65` sign with the post-quantum ML-DSA scheme of US NIST FIPS 204. The set is expected to grow as algorithms are standardised, and growing it is a MINOR change under SPEC.md §5.2: `keyType` selects no schema branch, so adding a value relaxes a constraint rather than narrowing one, and the generated libraries mark this enumeration non-exhaustive so that a consumer absorbs a new value rather than failing to compile. Two ML-DSA parameter sets are carried because two specifications require different ones — W3C Quantum-Resistant Cryptosuites defines Data Integrity suites only for ML-DSA-44, while Trust Spanning Protocol Rev 3 §8.1 mandates ML-DSA-65 — so the parameter set is chosen by whatever consumes the key and the two are not redundant. A consumer that does not implement a value it receives MUST refuse the document rather than substitute one it does support."
     },
     "Ext": {
       "title": "Ext",