@openvtc/trust-tasks 0.8.1 → 0.9.0

package/dist/witness/session/0.1/payload.js

@@ -6,16 +6,134 @@
 export const TYPE_URI = "https://trusttasks.org/spec/witness/session/0.1";
 /** Trust Task response type URI (request type URI + "#response"). */
 export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/witness/session/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/witness/session/0.1",
+    "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 {@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-]+)+$"
+            }
+        }
+    }
+};
 /**
  * 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.
+ * 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,
+    payloadSchema: PAYLOAD_SCHEMA,
 };
 /**
  * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
@@ -27,5 +145,6 @@ export const RESPONSE_SPEC = {
     isBearer: false,
     isProofRequired: true,
     isRecipientRequired: true,
+    payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
 };
 //# sourceMappingURL=payload.js.map

package/dist/witness/session/0.1/payload.js.map

@@ -1 +1 @@
-{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../src/witness/session/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAoCH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,iDAA0D,CAAC;AAKnF,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,0DAAmE,CAAC;AAKrG;;;;GAIG;AACH,MAAM,CAAC,MAAM,IAAI,GAAG;IAClB,OAAO,EAAE,QAAQ;IACjB,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,KAAK;IACtB,mBAAmB,EAAE,IAAI;CACjB,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;CACjB,CAAC"}
+{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../src/witness/session/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAoCH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,iDAA0D,CAAC;AAKnF,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,0DAAmE,CAAC;AAKrG;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,cAAc,GAAG;IAC5B,SAAS,EAAE,8CAA8C;IACzD,KAAK,EAAE,iDAAiD;IACxD,OAAO,EAAE,2BAA2B;IACpC,aAAa,EAAE,2YAA2Y;IAC1Z,MAAM,EAAE,QAAQ;IAChB,sBAAsB,EAAE,KAAK;IAC7B,UAAU,EAAE;QACV,SAAS;KACV;IACD,YAAY,EAAE;QACZ,SAAS,EAAE;YACT,MAAM,EAAE,OAAO;YACf,UAAU,EAAE,CAAC;YACb,UAAU,EAAE,CAAC;YACb,OAAO,EAAE;gBACP,MAAM,EAAE,QAAQ;gBAChB,SAAS,EAAE,OAAO;aACnB;YACD,aAAa,EAAE,mIAAmI;SACnJ;QACD,KAAK,EAAE;YACL,MAAM,EAAE,aAAa;SACtB;KACF;IACD,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,oCAAoC;YAC7C,aAAa,EAAE,iOAAiO;YAChP,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,WAAW;gBACX,QAAQ;aACT;YACD,YAAY,EAAE;gBACZ,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,EAAE;oBACf,aAAa,EAAE,4RAA4R;iBAC5S;gBACD,QAAQ,EAAE;oBACR,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,6GAA6G;iBAC7H;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,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,oCAAoC;YAC7C,aAAa,EAAE,iOAAiO;YAChP,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,WAAW;gBACX,QAAQ;aACT;YACD,YAAY,EAAE;gBACZ,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,EAAE;oBACf,aAAa,EAAE,4RAA4R;iBAC5S;gBACD,QAAQ,EAAE;oBACR,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,6GAA6G;iBAC7H;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,KAAK;IACtB,mBAAmB,EAAE,IAAI;IACzB,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,aAAa,EAAE,uBAAuB;CAC9B,CAAC"}

package/dist/witness/session/submit/0.1/payload.d.ts

@@ -3,7 +3,7 @@
  * Source: specs/witness/session/submit/0.1/payload.schema.json
  */
 /**
- * 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.
+ * 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.
  */
 export type DigestMultibase = string;
 /**
@@ -27,7 +27,7 @@ export interface Ext {
  */
 export interface WitnessSessionSubmitResponsePayload {
     /**
-     * A signed Verifiable Witness Credential (opaque here; its schema belongs to DTG Core Credentials). 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).
+     * A signed Verifiable Witness Credential (opaque here; its schema belongs to DTG Core Credentials). 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: {};
     vwcDigestMultibase: DigestMultibase;
@@ -41,16 +41,190 @@ export type Payload = WitnessSessionSubmitPayload;
 export declare const RESPONSE_TYPE_URI: "https://trusttasks.org/spec/witness/session/submit/0.1#response";
 /** 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 declare const PAYLOAD_SCHEMA: {
+    readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+    readonly $id: "https://trusttasks.org/spec/witness/session/submit/0.1";
+    readonly title: "Witness Session Submit — payload";
+    readonly description: "A participating party submits its presentation 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.";
+    readonly type: "object";
+    readonly additionalProperties: false;
+    readonly required: readonly ["vp"];
+    readonly properties: {
+        readonly vp: {
+            readonly type: "object";
+            readonly 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.";
+        };
+        readonly ext: {
+            readonly $ref: "#/$defs/Ext";
+        };
+    };
+    readonly $defs: {
+        readonly Response: {
+            readonly $anchor: "response";
+            readonly title: "Witness Session Submit — response payload";
+            readonly 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.";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["vwc", "vwcDigestMultibase"];
+            readonly properties: {
+                readonly vwc: {
+                    readonly type: "object";
+                    readonly description: "A signed Verifiable Witness Credential (opaque here; its schema belongs to DTG Core Credentials). 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.";
+                };
+                readonly vwcDigestMultibase: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                    readonly 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.";
+                };
+                readonly ext: {
+                    readonly $ref: "#/$defs/Ext";
+                };
+            };
+        };
+        readonly Ext: {
+            readonly title: "Ext";
+            readonly 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.";
+            readonly type: "object";
+            readonly minProperties: 1;
+            readonly additionalProperties: true;
+            readonly propertyNames: {
+                readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+            };
+        };
+        readonly DigestMultibase: {
+            readonly title: "DigestMultibase";
+            readonly 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`.";
+            readonly type: "string";
+            readonly minLength: 16;
+            readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+            readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+        };
+    };
+};
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export declare const RESPONSE_PAYLOAD_SCHEMA: {
+    readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+    readonly $ref: "#/$defs/Response";
+    readonly $defs: {
+        readonly Response: {
+            readonly $anchor: "response";
+            readonly title: "Witness Session Submit — response payload";
+            readonly 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.";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["vwc", "vwcDigestMultibase"];
+            readonly properties: {
+                readonly vwc: {
+                    readonly type: "object";
+                    readonly description: "A signed Verifiable Witness Credential (opaque here; its schema belongs to DTG Core Credentials). 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.";
+                };
+                readonly vwcDigestMultibase: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                    readonly 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.";
+                };
+                readonly ext: {
+                    readonly $ref: "#/$defs/Ext";
+                };
+            };
+        };
+        readonly Ext: {
+            readonly title: "Ext";
+            readonly 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.";
+            readonly type: "object";
+            readonly minProperties: 1;
+            readonly additionalProperties: true;
+            readonly propertyNames: {
+                readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+            };
+        };
+        readonly DigestMultibase: {
+            readonly title: "DigestMultibase";
+            readonly 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`.";
+            readonly type: "string";
+            readonly minLength: 16;
+            readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+            readonly examples: readonly ["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.
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
  */
 export declare const SPEC: {
     readonly typeUri: "https://trusttasks.org/spec/witness/session/submit/0.1";
     readonly isBearer: false;
     readonly isProofRequired: true;
     readonly isRecipientRequired: true;
+    readonly payloadSchema: {
+        readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+        readonly $id: "https://trusttasks.org/spec/witness/session/submit/0.1";
+        readonly title: "Witness Session Submit — payload";
+        readonly description: "A participating party submits its presentation 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.";
+        readonly type: "object";
+        readonly additionalProperties: false;
+        readonly required: readonly ["vp"];
+        readonly properties: {
+            readonly vp: {
+                readonly type: "object";
+                readonly 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.";
+            };
+            readonly ext: {
+                readonly $ref: "#/$defs/Ext";
+            };
+        };
+        readonly $defs: {
+            readonly Response: {
+                readonly $anchor: "response";
+                readonly title: "Witness Session Submit — response payload";
+                readonly 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.";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["vwc", "vwcDigestMultibase"];
+                readonly properties: {
+                    readonly vwc: {
+                        readonly type: "object";
+                        readonly description: "A signed Verifiable Witness Credential (opaque here; its schema belongs to DTG Core Credentials). 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.";
+                    };
+                    readonly vwcDigestMultibase: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                        readonly 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.";
+                    };
+                    readonly ext: {
+                        readonly $ref: "#/$defs/Ext";
+                    };
+                };
+            };
+            readonly Ext: {
+                readonly title: "Ext";
+                readonly 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.";
+                readonly type: "object";
+                readonly minProperties: 1;
+                readonly additionalProperties: true;
+                readonly propertyNames: {
+                    readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+                };
+            };
+            readonly DigestMultibase: {
+                readonly title: "DigestMultibase";
+                readonly 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`.";
+                readonly type: "string";
+                readonly minLength: 16;
+                readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+                readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+            };
+        };
+    };
 };
 /**
  * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
@@ -62,5 +236,50 @@ export declare const RESPONSE_SPEC: {
     readonly isBearer: false;
     readonly isProofRequired: true;
     readonly isRecipientRequired: true;
+    readonly payloadSchema: {
+        readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+        readonly $ref: "#/$defs/Response";
+        readonly $defs: {
+            readonly Response: {
+                readonly $anchor: "response";
+                readonly title: "Witness Session Submit — response payload";
+                readonly 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.";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["vwc", "vwcDigestMultibase"];
+                readonly properties: {
+                    readonly vwc: {
+                        readonly type: "object";
+                        readonly description: "A signed Verifiable Witness Credential (opaque here; its schema belongs to DTG Core Credentials). 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.";
+                    };
+                    readonly vwcDigestMultibase: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                        readonly 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.";
+                    };
+                    readonly ext: {
+                        readonly $ref: "#/$defs/Ext";
+                    };
+                };
+            };
+            readonly Ext: {
+                readonly title: "Ext";
+                readonly 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.";
+                readonly type: "object";
+                readonly minProperties: 1;
+                readonly additionalProperties: true;
+                readonly propertyNames: {
+                    readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+                };
+            };
+            readonly DigestMultibase: {
+                readonly title: "DigestMultibase";
+                readonly 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`.";
+                readonly type: "string";
+                readonly minLength: 16;
+                readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+                readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+            };
+        };
+    };
 };
 //# sourceMappingURL=payload.d.ts.map

package/dist/witness/session/submit/0.1/payload.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../src/witness/session/submit/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,MAAM,eAAe,GAAG,MAAM,CAAC;AAErC;;GAEG;AACH,MAAM,WAAW,2BAA2B;IAC1C;;OAEG;IACH,EAAE,EAAE,EAAE,CAAC;IACP,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,GAAG;IAClB,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC;AACD;;GAEG;AACH,MAAM,WAAW,mCAAmC;IAClD;;OAEG;IACH,GAAG,EAAE,EAAE,CAAC;IACR,kBAAkB,EAAE,eAAe,CAAC;IACpC,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AAED,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,wDAAiE,CAAC;AAE1F,mEAAmE;AACnE,MAAM,MAAM,OAAO,GAAG,2BAA2B,CAAC;AAElD,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,iEAA0E,CAAC;AAE5G,4EAA4E;AAC5E,MAAM,MAAM,QAAQ,GAAG,mCAAmC,CAAC;AAE3D;;;;GAIG;AACH,eAAO,MAAM,IAAI;;;;;CAKP,CAAC;AAEX;;;;GAIG;AACH,eAAO,MAAM,aAAa;;;;;CAKhB,CAAC"}
+{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../src/witness/session/submit/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,MAAM,eAAe,GAAG,MAAM,CAAC;AAErC;;GAEG;AACH,MAAM,WAAW,2BAA2B;IAC1C;;OAEG;IACH,EAAE,EAAE,EAAE,CAAC;IACP,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,GAAG;IAClB,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC;AACD;;GAEG;AACH,MAAM,WAAW,mCAAmC;IAClD;;OAEG;IACH,GAAG,EAAE,EAAE,CAAC;IACR,kBAAkB,EAAE,eAAe,CAAC;IACpC,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AAED,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,wDAAiE,CAAC;AAE1F,mEAAmE;AACnE,MAAM,MAAM,OAAO,GAAG,2BAA2B,CAAC;AAElD,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,iEAA0E,CAAC;AAE5G,4EAA4E;AAC5E,MAAM,MAAM,QAAQ,GAAG,mCAAmC,CAAC;AAE3D;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiEjB,CAAC;AAEX,mEAAmE;AACnE,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiD1B,CAAC;AAEX;;;;;GAKG;AACH,eAAO,MAAM,IAAI;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMP,CAAC;AAEX;;;;GAIG;AACH,eAAO,MAAM,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMhB,CAAC"}

package/dist/witness/session/submit/0.1/payload.js

@@ -6,16 +6,144 @@
 export const TYPE_URI = "https://trusttasks.org/spec/witness/session/submit/0.1";
 /** Trust Task response type URI (request type URI + "#response"). */
 export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/witness/session/submit/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/witness/session/submit/0.1",
+    "title": "Witness Session Submit — payload",
+    "description": "A participating party submits its presentation 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."
+        },
+        "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 (opaque here; its schema belongs to DTG Core Credentials). 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 {@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 (opaque here; its schema belongs to DTG Core Credentials). 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"
+            ]
+        }
+    }
+};
 /**
  * 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.
+ * 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,
+    payloadSchema: PAYLOAD_SCHEMA,
 };
 /**
  * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
@@ -27,5 +155,6 @@ export const RESPONSE_SPEC = {
     isBearer: false,
     isProofRequired: true,
     isRecipientRequired: true,
+    payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
 };
 //# sourceMappingURL=payload.js.map

package/dist/witness/session/submit/0.1/payload.js.map

@@ -1 +1 @@
-{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../src/witness/session/submit/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAmCH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,wDAAiE,CAAC;AAK1F,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,iEAA0E,CAAC;AAK5G;;;;GAIG;AACH,MAAM,CAAC,MAAM,IAAI,GAAG;IAClB,OAAO,EAAE,QAAQ;IACjB,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,IAAI;CACjB,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;CACjB,CAAC"}
+{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../src/witness/session/submit/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAmCH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,wDAAiE,CAAC;AAK1F,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,iEAA0E,CAAC;AAK5G;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,cAAc,GAAG;IAC5B,SAAS,EAAE,8CAA8C;IACzD,KAAK,EAAE,wDAAwD;IAC/D,OAAO,EAAE,kCAAkC;IAC3C,aAAa,EAAE,+OAA+O;IAC9P,MAAM,EAAE,QAAQ;IAChB,sBAAsB,EAAE,KAAK;IAC7B,UAAU,EAAE;QACV,IAAI;KACL;IACD,YAAY,EAAE;QACZ,IAAI,EAAE;YACJ,MAAM,EAAE,QAAQ;YAChB,aAAa,EAAE,8PAA8P;SAC9Q;QACD,KAAK,EAAE;YACL,MAAM,EAAE,aAAa;SACtB;KACF;IACD,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,2CAA2C;YACpD,aAAa,EAAE,mMAAmM;YAClN,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,KAAK;gBACL,oBAAoB;aACrB;YACD,YAAY,EAAE;gBACZ,KAAK,EAAE;oBACL,MAAM,EAAE,QAAQ;oBAChB,aAAa,EAAE,6cAA6c;iBAC7d;gBACD,oBAAoB,EAAE;oBACpB,MAAM,EAAE,yBAAyB;oBACjC,aAAa,EAAE,qpBAAqpB;iBACrqB;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;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,2CAA2C;YACpD,aAAa,EAAE,mMAAmM;YAClN,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,KAAK;gBACL,oBAAoB;aACrB;YACD,YAAY,EAAE;gBACZ,KAAK,EAAE;oBACL,MAAM,EAAE,QAAQ;oBAChB,aAAa,EAAE,6cAA6c;iBAC7d;gBACD,oBAAoB,EAAE;oBACpB,MAAM,EAAE,yBAAyB;oBACjC,aAAa,EAAE,qpBAAqpB;iBACrqB;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;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,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,aAAa,EAAE,uBAAuB;CAC9B,CAAC"}

package/package.json

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