@openvtc/trust-tasks 0.19.5 → 0.19.7

package/dist/vtc/registry/sync-jobs/retry/0.1/payload.js

@@ -0,0 +1,269 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/vtc/registry/sync-jobs/retry/0.1/payload.schema.json
+ */
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/vtc/registry/sync-jobs/retry/0.1";
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/vtc/registry/sync-jobs/retry/0.1#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/vtc/registry/sync-jobs/retry/0.1",
+    "title": "VTC Registry Sync Jobs Retry — payload",
+    "description": "Requeue an abandoned trust-registry reconciliation job so the community's reconciler dispatches it again.",
+    "type": "object",
+    "additionalProperties": false,
+    "oneOf": [
+        {
+            "required": [
+                "jobId"
+            ],
+            "not": {
+                "required": [
+                    "allFailed"
+                ]
+            }
+        },
+        {
+            "required": [
+                "allFailed"
+            ],
+            "not": {
+                "required": [
+                    "jobId"
+                ]
+            }
+        }
+    ],
+    "properties": {
+        "jobId": {
+            "type": "string",
+            "minLength": 1,
+            "description": "The single job to requeue, from `vtc/registry/sync-jobs/list`."
+        },
+        "allFailed": {
+            "type": "boolean",
+            "const": true,
+            "description": "Requeue every job in the terminal `failed` state. Spelled as its own member rather than an absent `jobId` so that a client bug which drops the identifier cannot silently become a bulk operation."
+        },
+        "ext": {
+            "$ref": "#/$defs/Ext"
+        }
+    },
+    "$defs": {
+        "Requeued": {
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "jobId"
+            ],
+            "properties": {
+                "jobId": {
+                    "type": "string",
+                    "minLength": 1
+                },
+                "memberDid": {
+                    "type": "string",
+                    "minLength": 1,
+                    "description": "The member whose record the requeued job carries."
+                },
+                "ext": {
+                    "$ref": "#/$defs/Ext"
+                }
+            }
+        },
+        "Skipped": {
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "jobId",
+                "reason"
+            ],
+            "properties": {
+                "jobId": {
+                    "type": "string",
+                    "minLength": 1
+                },
+                "reason": {
+                    "type": "string",
+                    "enum": [
+                        "notFailed",
+                        "notFound"
+                    ],
+                    "description": "`notFailed` — the reconciler still owns the job, so requeueing it would dispatch the same mutation twice. `notFound` — no such job; it may already have been retried, discarded, or swept."
+                },
+                "ext": {
+                    "$ref": "#/$defs/Ext"
+                }
+            }
+        },
+        "Response": {
+            "$anchor": "response",
+            "title": "VTC Registry Sync Jobs Retry — response payload",
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "requeued",
+                "skipped"
+            ],
+            "properties": {
+                "requeued": {
+                    "type": "array",
+                    "items": {
+                        "$ref": "#/$defs/Requeued"
+                    },
+                    "description": "Jobs now scheduled for dispatch. Empty is a valid answer and is not an error."
+                },
+                "skipped": {
+                    "type": "array",
+                    "items": {
+                        "$ref": "#/$defs/Skipped"
+                    },
+                    "description": "Jobs the maintainer declined to requeue, each with why. Reported rather than failing the task, so a bulk retry is not defeated by one ineligible row."
+                },
+                "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 {@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": {
+        "Requeued": {
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "jobId"
+            ],
+            "properties": {
+                "jobId": {
+                    "type": "string",
+                    "minLength": 1
+                },
+                "memberDid": {
+                    "type": "string",
+                    "minLength": 1,
+                    "description": "The member whose record the requeued job carries."
+                },
+                "ext": {
+                    "$ref": "#/$defs/Ext"
+                }
+            }
+        },
+        "Skipped": {
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "jobId",
+                "reason"
+            ],
+            "properties": {
+                "jobId": {
+                    "type": "string",
+                    "minLength": 1
+                },
+                "reason": {
+                    "type": "string",
+                    "enum": [
+                        "notFailed",
+                        "notFound"
+                    ],
+                    "description": "`notFailed` — the reconciler still owns the job, so requeueing it would dispatch the same mutation twice. `notFound` — no such job; it may already have been retried, discarded, or swept."
+                },
+                "ext": {
+                    "$ref": "#/$defs/Ext"
+                }
+            }
+        },
+        "Response": {
+            "$anchor": "response",
+            "title": "VTC Registry Sync Jobs Retry — response payload",
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "requeued",
+                "skipped"
+            ],
+            "properties": {
+                "requeued": {
+                    "type": "array",
+                    "items": {
+                        "$ref": "#/$defs/Requeued"
+                    },
+                    "description": "Jobs now scheduled for dispatch. Empty is a valid answer and is not an error."
+                },
+                "skipped": {
+                    "type": "array",
+                    "items": {
+                        "$ref": "#/$defs/Skipped"
+                    },
+                    "description": "Jobs the maintainer declined to requeue, each with why. Reported rather than failing the task, so a bulk retry is not defeated by one ineligible row."
+                },
+                "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-]+)+$"
+            }
+        }
+    }
+};
+/**
+ * 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: true,
+    isRecipientRequired: true,
+    isIssuedAtRequired: true,
+    payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+};
+//# sourceMappingURL=payload.js.map

package/dist/vtc/registry/sync-jobs/retry/0.1/payload.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../../src/vtc/registry/sync-jobs/retry/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAqDH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,8DAAuE,CAAC;AAKhG,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,uEAAgF,CAAC;AAKlH;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,cAAc,GAAG;IAC5B,SAAS,EAAE,8CAA8C;IACzD,KAAK,EAAE,8DAA8D;IACrE,OAAO,EAAE,wCAAwC;IACjD,aAAa,EAAE,2GAA2G;IAC1H,MAAM,EAAE,QAAQ;IAChB,sBAAsB,EAAE,KAAK;IAC7B,OAAO,EAAE;QACP;YACE,UAAU,EAAE;gBACV,OAAO;aACR;YACD,KAAK,EAAE;gBACL,UAAU,EAAE;oBACV,WAAW;iBACZ;aACF;SACF;QACD;YACE,UAAU,EAAE;gBACV,WAAW;aACZ;YACD,KAAK,EAAE;gBACL,UAAU,EAAE;oBACV,OAAO;iBACR;aACF;SACF;KACF;IACD,YAAY,EAAE;QACZ,OAAO,EAAE;YACP,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,CAAC;YACd,aAAa,EAAE,gEAAgE;SAChF;QACD,WAAW,EAAE;YACX,MAAM,EAAE,SAAS;YACjB,OAAO,EAAE,IAAI;YACb,aAAa,EAAE,oMAAoM;SACpN;QACD,KAAK,EAAE;YACL,MAAM,EAAE,aAAa;SACtB;KACF;IACD,OAAO,EAAE;QACP,UAAU,EAAE;YACV,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,OAAO;aACR;YACD,YAAY,EAAE;gBACZ,OAAO,EAAE;oBACP,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,mDAAmD;iBACnE;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,SAAS,EAAE;YACT,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,OAAO;gBACP,QAAQ;aACT;YACD,YAAY,EAAE;gBACZ,OAAO,EAAE;oBACP,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,QAAQ,EAAE;oBACR,MAAM,EAAE,QAAQ;oBAChB,MAAM,EAAE;wBACN,WAAW;wBACX,UAAU;qBACX;oBACD,aAAa,EAAE,4LAA4L;iBAC5M;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,iDAAiD;YAC1D,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,UAAU;gBACV,SAAS;aACV;YACD,YAAY,EAAE;gBACZ,UAAU,EAAE;oBACV,MAAM,EAAE,OAAO;oBACf,OAAO,EAAE;wBACP,MAAM,EAAE,kBAAkB;qBAC3B;oBACD,aAAa,EAAE,+EAA+E;iBAC/F;gBACD,SAAS,EAAE;oBACT,MAAM,EAAE,OAAO;oBACf,OAAO,EAAE;wBACP,MAAM,EAAE,iBAAiB;qBAC1B;oBACD,aAAa,EAAE,uJAAuJ;iBACvK;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;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;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,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,OAAO;aACR;YACD,YAAY,EAAE;gBACZ,OAAO,EAAE;oBACP,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,mDAAmD;iBACnE;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,SAAS,EAAE;YACT,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,OAAO;gBACP,QAAQ;aACT;YACD,YAAY,EAAE;gBACZ,OAAO,EAAE;oBACP,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,QAAQ,EAAE;oBACR,MAAM,EAAE,QAAQ;oBAChB,MAAM,EAAE;wBACN,WAAW;wBACX,UAAU;qBACX;oBACD,aAAa,EAAE,4LAA4L;iBAC5M;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,iDAAiD;YAC1D,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,UAAU;gBACV,SAAS;aACV;YACD,YAAY,EAAE;gBACZ,UAAU,EAAE;oBACV,MAAM,EAAE,OAAO;oBACf,OAAO,EAAE;wBACP,MAAM,EAAE,kBAAkB;qBAC3B;oBACD,aAAa,EAAE,+EAA+E;iBAC/F;gBACD,SAAS,EAAE;oBACT,MAAM,EAAE,OAAO;oBACf,OAAO,EAAE;wBACP,MAAM,EAAE,iBAAiB;qBAC1B;oBACD,aAAa,EAAE,uJAAuJ;iBACvK;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;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;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,IAAI;IACrB,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.5",
+  "version": "0.19.7",
   "description": "Generated TypeScript bindings for the Trust Tasks framework registry.",
   "type": "module",
   "main": "./dist/index.js",

package/src/_shared/components.ts

@@ -210,9 +210,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 +459,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.
  */

package/src/index.ts

@@ -492,6 +492,10 @@ export * as VtcMembersVmc_v0_1 from "./vtc/members/vmc/0.1/payload.js";
 export * as VtcPoliciesTest_v0_1 from "./vtc/policies/test/0.1/payload.js";
 export * as VtcRecognitionCheck_v0_1 from "./vtc/recognition/check/0.1/payload.js";
 export * as VtcRegistryDiagnostics_v0_1 from "./vtc/registry/diagnostics/0.1/payload.js";
+export * as VtcRegistryRecordsList_v0_1 from "./vtc/registry/records/list/0.1/payload.js";
+export * as VtcRegistrySyncJobsDiscard_v0_1 from "./vtc/registry/sync-jobs/discard/0.1/payload.js";
+export * as VtcRegistrySyncJobsList_v0_1 from "./vtc/registry/sync-jobs/list/0.1/payload.js";
+export * as VtcRegistrySyncJobsRetry_v0_1 from "./vtc/registry/sync-jobs/retry/0.1/payload.js";
 export * as VtcRelationshipsGraph_v0_1 from "./vtc/relationships/graph/0.1/payload.js";
 export * as VtcRelationshipsGraph_v0_2 from "./vtc/relationships/graph/0.2/payload.js";
 export * as VtcRelationshipsList_v0_1 from "./vtc/relationships/list/0.1/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",

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

@@ -260,9 +260,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;
@@ -396,9 +398,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/list/0.1/payload.ts

@@ -251,9 +251,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;
@@ -408,9 +410,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/set-exportability/0.1/payload.ts

@@ -191,9 +191,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",
@@ -324,9 +326,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",

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

@@ -203,9 +203,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;
@@ -346,9 +348,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/sign/0.1/payload.ts

@@ -138,9 +138,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."
     }
   }
 } as const;
@@ -193,9 +195,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."
     }
   }
 } as const;