@openvtc/trust-tasks 0.26.11 → 0.26.12

package/src/witness/session/0.2/payload.ts

@@ -0,0 +1,197 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/witness/session/0.2/payload.schema.json
+ */
+
+import type { Ext } from "../../../_shared/components.js";
+
+
+/**
+ * Opens one participating party's witness session as its own exchange, nested in a relationship exchange via parentThreadId. A session is bilateral — a witnessed exchange between two parties runs two sessions with the same witness, each naming the same parties pair. The response issues the session challenge; the request document's id is the value that party's VWC later carries as taskContext.
+ */
+export interface WitnessSessionPayload {
+  /**
+   * The relationship DIDs of the exchange to be witnessed — the pairwise values the relationship proposal exchanged, in either order.
+   *
+   * @minItems 2
+   * @maxItems 2
+   */
+  parties: [string, string];
+  ext?: Ext;
+}
+/**
+ * The session challenge, issued under the REQUIRED proof. The presentation under witness/session/submit binds to {challenge, domain}. It reaches only the party that opened this session — which is why each party opens its own.
+ */
+export interface WitnessSessionResponsePayload {
+  /**
+   * A fresh, unpredictable, single-use value this session's presentation binds to. A witness MUST NOT reuse a challenge across sessions — including across the two sessions of one witnessed exchange, where a shared value would let either party's presentation satisfy the other's session.
+   */
+  challenge: string;
+  /**
+   * The domain the presentations bind alongside the challenge, identifying this witness's verification context.
+   */
+  domain: string;
+  ext?: Ext;
+}
+
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { Ext };
+
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/witness/session/0.2" as const;
+
+/** Stable alias for this specification's request payload shape. */
+export type Payload = WitnessSessionPayload;
+
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/witness/session/0.2#response" as const;
+
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = WitnessSessionResponsePayload;
+
+/**
+ * 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/witness/session/0.2",
+  "title": "Witness Session — payload",
+  "description": "Opens one participating party's witness session as its own exchange, nested in a relationship exchange via parentThreadId. A session is bilateral — a witnessed exchange between two parties runs two sessions with the same witness, each naming the same parties pair. The response issues the session challenge; the request document's id is the value that party's VWC later carries as taskContext.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "parties"
+  ],
+  "properties": {
+    "parties": {
+      "type": "array",
+      "minItems": 2,
+      "maxItems": 2,
+      "items": {
+        "type": "string",
+        "pattern": "^did:"
+      },
+      "description": "The relationship DIDs of the exchange to be witnessed — the pairwise values the relationship proposal exchanged, in either order."
+    },
+    "ext": {
+      "$ref": "#/$defs/Ext"
+    }
+  },
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Witness Session — response payload",
+      "description": "The session challenge, issued under the REQUIRED proof. The presentation under witness/session/submit binds to {challenge, domain}. It reaches only the party that opened this session — which is why each party opens its own.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "challenge",
+        "domain"
+      ],
+      "properties": {
+        "challenge": {
+          "type": "string",
+          "minLength": 16,
+          "description": "A fresh, unpredictable, single-use value this session's presentation binds to. A witness MUST NOT reuse a challenge across sessions — including across the two sessions of one witnessed exchange, where a shared value would let either party's presentation satisfy the other's session."
+        },
+        "domain": {
+          "type": "string",
+          "minLength": 1,
+          "description": "The domain the presentations bind alongside the challenge, identifying this witness's verification context."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Witness Session — response payload",
+      "description": "The session challenge, issued under the REQUIRED proof. The presentation under witness/session/submit binds to {challenge, domain}. It reaches only the party that opened this session — which is why each party opens its own.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "challenge",
+        "domain"
+      ],
+      "properties": {
+        "challenge": {
+          "type": "string",
+          "minLength": 16,
+          "description": "A fresh, unpredictable, single-use value this session's presentation binds to. A witness MUST NOT reuse a challenge across sessions — including across the two sessions of one witnessed exchange, where a shared value would let either party's presentation satisfy the other's session."
+        },
+        "domain": {
+          "type": "string",
+          "minLength": 1,
+          "description": "The domain the presentations bind alongside the challenge, identifying this witness's verification context."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the request variant, from this specification's
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
+ */
+export const SPEC = {
+  typeUri: TYPE_URI,
+  isBearer: false,
+  isProofRequired: false,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: PAYLOAD_SCHEMA,
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export const RESPONSE_SPEC = {
+  typeUri: RESPONSE_TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+} as const;

package/src/witness/session/submit/0.2/payload.ts

@@ -0,0 +1,212 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/witness/session/submit/0.2/payload.schema.json
+ */
+
+import type { DigestMultibase, Ext } from "../../../../_shared/components.js";
+
+
+/**
+ * A participating party submits its presentation — and, optionally, a member presentation by its member DID — bound to its session challenge; the witness's mandatory response delivers the Verifiable Witness Credential and its digest. The response is the outcome evidence a VWC presentation must ship.
+ */
+export interface WitnessSessionSubmitPayload {
+  /**
+   * A W3C Verifiable Presentation of the submitting party's own relationship credential material (opaque here), bound to the session's challenge and domain. A presentation not bound to this session is rejected with witness/session/submit:challengeMismatch.
+   */
+  vp: {};
+  /**
+   * OPTIONAL. A W3C Verifiable Presentation (opaque here) whose holder is the member DID — neither of the session's parties, and not the witness — under a proof by that DID for authentication covering the session's challenge and domain, as vp's does, and carrying the credentials that show the member eligible under the witness's policy, typically a membership credential naming the member DID. It links the pairwise relationship DID to the member DID at the witness, which must keep neither it nor the member DID. A witness that relies on it and finds it failing any check answers witness/session/submit:presentationInvalid.
+   */
+  memberPresentation?: {};
+  ext?: Ext;
+}
+/**
+ * The Verifiable Witness Credential and its digest, delivered under the REQUIRED proof. This document is the session's terminal success form and the outcome evidence a VWC presentation must ship.
+ */
+export interface WitnessSessionSubmitResponsePayload {
+  /**
+   * A signed Verifiable Witness Credential: a DTG Verifiable Statement Credential (`type` including `StatementCredential`) under the predicate `https://registry.trustoverip.org/dtg/vsc/witnessed/1` (opaque here; its schema belongs to the DTG Credentials Core Specification). Its issuer is the witness, with `issuerScope` `directed` or `public`; its `credentialSubject.id` is the submitting party, the issuer of the relationship credential the witness observed; and its `credentialSubject.object.digestMultibase` is that credential's digest. Its taskContext MUST equal the id of the witness/session document that opened this session — the innermost exchange that attests the witnessing (SPEC.md §4.9.1) — and its taskDigestMultibase MUST be that document's task digest (SPEC.md §4.9.3). The id locates the session document; the digest binds it, because an id is a name anyone can reuse on a counterfeit.
+   */
+  vwc: {};
+  /**
+   * Digest over the RFC 8785 canonicalization of the delivered credential, computed by the witness. It binds this evidence to one specific credential rather than to the session alone, so a verifier pairing a presented VWC with this response can check it is the credential this session issued and not another the same witness signed. This covers the credential whole, proof included — unlike the task digest of SPEC.md §4.9.3, which excludes the top-level proof of the Trust Task document it names. The inputs differ because the questions do: this value identifies one delivered artifact, a task digest identifies what a document says whether or not it was signed.
+   */
+  vwcDigestMultibase: DigestMultibase;
+  ext?: Ext;
+}
+
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { DigestMultibase, Ext };
+
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/witness/session/submit/0.2" as const;
+
+/** Stable alias for this specification's request payload shape. */
+export type Payload = WitnessSessionSubmitPayload;
+
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/witness/session/submit/0.2#response" as const;
+
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = WitnessSessionSubmitResponsePayload;
+
+/**
+ * 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/witness/session/submit/0.2",
+  "title": "Witness Session Submit — payload",
+  "description": "A participating party submits its presentation — and, optionally, a member presentation by its member DID — bound to its session challenge; the witness's mandatory response delivers the Verifiable Witness Credential and its digest. The response is the outcome evidence a VWC presentation must ship.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "vp"
+  ],
+  "properties": {
+    "vp": {
+      "type": "object",
+      "description": "A W3C Verifiable Presentation of the submitting party's own relationship credential material (opaque here), bound to the session's challenge and domain. A presentation not bound to this session is rejected with witness/session/submit:challengeMismatch."
+    },
+    "memberPresentation": {
+      "type": "object",
+      "description": "OPTIONAL. A W3C Verifiable Presentation (opaque here) whose holder is the member DID — neither of the session's parties, and not the witness — under a proof by that DID for authentication covering the session's challenge and domain, as vp's does, and carrying the credentials that show the member eligible under the witness's policy, typically a membership credential naming the member DID. It links the pairwise relationship DID to the member DID at the witness, which must keep neither it nor the member DID. A witness that relies on it and finds it failing any check answers witness/session/submit:presentationInvalid."
+    },
+    "ext": {
+      "$ref": "#/$defs/Ext"
+    }
+  },
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Witness Session Submit — response payload",
+      "description": "The Verifiable Witness Credential and its digest, delivered under the REQUIRED proof. This document is the session's terminal success form and the outcome evidence a VWC presentation must ship.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "vwc",
+        "vwcDigestMultibase"
+      ],
+      "properties": {
+        "vwc": {
+          "type": "object",
+          "description": "A signed Verifiable Witness Credential: a DTG Verifiable Statement Credential (`type` including `StatementCredential`) under the predicate `https://registry.trustoverip.org/dtg/vsc/witnessed/1` (opaque here; its schema belongs to the DTG Credentials Core Specification). Its issuer is the witness, with `issuerScope` `directed` or `public`; its `credentialSubject.id` is the submitting party, the issuer of the relationship credential the witness observed; and its `credentialSubject.object.digestMultibase` is that credential's digest. Its taskContext MUST equal the id of the witness/session document that opened this session — the innermost exchange that attests the witnessing (SPEC.md §4.9.1) — and its taskDigestMultibase MUST be that document's task digest (SPEC.md §4.9.3). The id locates the session document; the digest binds it, because an id is a name anyone can reuse on a counterfeit."
+        },
+        "vwcDigestMultibase": {
+          "$ref": "#/$defs/DigestMultibase",
+          "description": "Digest over the RFC 8785 canonicalization of the delivered credential, computed by the witness. It binds this evidence to one specific credential rather than to the session alone, so a verifier pairing a presented VWC with this response can check it is the credential this session issued and not another the same witness signed. This covers the credential whole, proof included — unlike the task digest of SPEC.md §4.9.3, which excludes the top-level proof of the Trust Task document it names. The inputs differ because the questions do: this value identifies one delivered artifact, a task digest identifies what a document says whether or not it was signed."
+        },
+        "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-]+)+$"
+      }
+    },
+    "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 const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Witness Session Submit — response payload",
+      "description": "The Verifiable Witness Credential and its digest, delivered under the REQUIRED proof. This document is the session's terminal success form and the outcome evidence a VWC presentation must ship.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "vwc",
+        "vwcDigestMultibase"
+      ],
+      "properties": {
+        "vwc": {
+          "type": "object",
+          "description": "A signed Verifiable Witness Credential: a DTG Verifiable Statement Credential (`type` including `StatementCredential`) under the predicate `https://registry.trustoverip.org/dtg/vsc/witnessed/1` (opaque here; its schema belongs to the DTG Credentials Core Specification). Its issuer is the witness, with `issuerScope` `directed` or `public`; its `credentialSubject.id` is the submitting party, the issuer of the relationship credential the witness observed; and its `credentialSubject.object.digestMultibase` is that credential's digest. Its taskContext MUST equal the id of the witness/session document that opened this session — the innermost exchange that attests the witnessing (SPEC.md §4.9.1) — and its taskDigestMultibase MUST be that document's task digest (SPEC.md §4.9.3). The id locates the session document; the digest binds it, because an id is a name anyone can reuse on a counterfeit."
+        },
+        "vwcDigestMultibase": {
+          "$ref": "#/$defs/DigestMultibase",
+          "description": "Digest over the RFC 8785 canonicalization of the delivered credential, computed by the witness. It binds this evidence to one specific credential rather than to the session alone, so a verifier pairing a presented VWC with this response can check it is the credential this session issued and not another the same witness signed. This covers the credential whole, proof included — unlike the task digest of SPEC.md §4.9.3, which excludes the top-level proof of the Trust Task document it names. The inputs differ because the questions do: this value identifies one delivered artifact, a task digest identifies what a document says whether or not it was signed."
+        },
+        "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-]+)+$"
+      }
+    },
+    "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 const;
+
+/**
+ * SPEC.md §7.2 policy for the request variant, from this specification's
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
+ */
+export const SPEC = {
+  typeUri: TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: PAYLOAD_SCHEMA,
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export const RESPONSE_SPEC = {
+  typeUri: RESPONSE_TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+} as const;