@openvtc/trust-tasks 0.28.3 → 0.28.4

package/dist/peer-check/ask/0.1/payload.d.ts

@@ -0,0 +1,397 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/peer-check/ask/0.1/payload.schema.json
+ */
+import type { DigestMultibase } from "../../../_shared/components.js";
+/**
+ * The request payload of peer-check/ask: a short yes-or-no question one party puts to another, with an unguessable challenge. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3. The asker is the `issuer`, the party being asked is the `recipient`, and the payload MUST carry `expiresAt`, the deadline for the answer. The envelope `expiresAt` keeps its framework meaning (SPEC §4.2): after it the responder does not prompt for the request.
+ */
+export interface PeerCheckAskPayload {
+    /**
+     * An unguessable value the asker generates for this one question: at least 128 bits from a cryptographically secure random source, encoded base64url without padding (22 to 86 characters). The responder echoes it unchanged in its answer.
+     */
+    challenge: string;
+    /**
+     * What the asker wants confirmed, in one short sentence, for example "Did you just ask me to send you a one-time code?". It is asker-authored text the responder's device displays attributed to the asker, never as a statement the device itself vouches for.
+     */
+    question: string;
+    /**
+     * OPTIONAL extra context from the asker. It is UNTRUSTED display text: the responder's device MUST render it as plain text, attributed to the asker and visually distinct from anything the device itself asserts, and MUST NOT interpret it as markup, a link, or an instruction.
+     */
+    note?: string;
+    /**
+     * The answer deadline. After this instant the pending question lapses: the responder does not prompt for it and the asker accepts no answer. It is the task's own deadline (SPEC §7.3 item 16); the envelope `expiresAt` bounds only acceptance of the request document.
+     */
+    expiresAt: string;
+}
+/**
+ * The success-response payload: the responder's answer, signed by the responder. Failures use trust-task-error, not this shape. A responder that declines because it does not recognize the question answers with `decision: notConfirmed`; an error is for a document the responder could not act on at all.
+ */
+export interface PeerCheckAskResponsePayload {
+    /**
+     * The `challenge` of the request, echoed unchanged. The asker rejects an answer whose challenge it did not issue, or has already consumed.
+     */
+    challenge: string;
+    /**
+     * The task digest (SPEC §4.9.3) of the request document this answers: multibase(multihash(H(JCS(request without its top-level proof)))). It binds the answer to the exact question, challenge, note, parties and deadline the responder was shown, so a yes given to one ask cannot be presented as a yes to another.
+     */
+    requestDigest: DigestMultibase;
+    /**
+     * The responder's answer. `confirmed` means yes to the question as asked; `notConfirmed` means no.
+     */
+    decision: "confirmed" | "notConfirmed";
+    /**
+     * When the responder gave the answer, RFC 3339. Informational for the asker; freshness is judged against the request's `payload.expiresAt` and the asker's own clock. It is the time of the user's answer; the envelope `issuedAt` is when the responder signed the document, which may be later.
+     */
+    respondedAt: string;
+    /**
+     * OPTIONAL, and only with `decision: notConfirmed`, which the schema enforces; a document carrying it beside `confirmed` is invalid. `notRecognized` — the responder does not recognize what the question describes; `declined` — the responder recognizes it and says no; `other` — anything else. An enumeration rather than prose, so an asker never renders responder-authored text.
+     */
+    notConfirmedReason?: "notRecognized" | "declined" | "other";
+}
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { DigestMultibase };
+/** Trust Task type URI. */
+export declare const TYPE_URI: "https://trusttasks.org/spec/peer-check/ask/0.1";
+/**
+ * The earlier version of this specification that this one declares it
+ * extends (front matter `extends`, SPEC §5.2 "Declared extension"), or
+ * `null`. Only the direct declaration — follow the chain with
+ * `extendsChain` / `readForSpec`.
+ */
+export declare const EXTENDS: string | null;
+/**
+ * Why this version is deprecated, or `null` while it is current. A
+ * superseded or retired version is still supported, and is withdrawn from
+ * this package in a later scheduled batch (SPEC "Superseded and Withdrawn
+ * Versions").
+ */
+export declare const DEPRECATION: string | null;
+/** Stable alias for this specification's request payload shape. */
+export type Payload = PeerCheckAskPayload;
+/** Trust Task response type URI (request type URI + "#response"). */
+export declare const RESPONSE_TYPE_URI: "https://trusttasks.org/spec/peer-check/ask/0.1#response";
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = PeerCheckAskResponsePayload;
+/**
+ * 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/peer-check/ask/0.1";
+    readonly title: "Peer Check — Ask — payload";
+    readonly description: "The request payload of peer-check/ask: a short yes-or-no question one party puts to another, with an unguessable challenge. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3. The asker is the `issuer`, the party being asked is the `recipient`, and the payload MUST carry `expiresAt`, the deadline for the answer. The envelope `expiresAt` keeps its framework meaning (SPEC §4.2): after it the responder does not prompt for the request.";
+    readonly type: "object";
+    readonly additionalProperties: false;
+    readonly required: readonly ["challenge", "question", "expiresAt"];
+    readonly properties: {
+        readonly challenge: {
+            readonly type: "string";
+            readonly pattern: "^[A-Za-z0-9_-]{22,86}$";
+            readonly description: "An unguessable value the asker generates for this one question: at least 128 bits from a cryptographically secure random source, encoded base64url without padding (22 to 86 characters). The responder echoes it unchanged in its answer.";
+        };
+        readonly question: {
+            readonly type: "string";
+            readonly minLength: 1;
+            readonly maxLength: 200;
+            readonly description: "What the asker wants confirmed, in one short sentence, for example \"Did you just ask me to send you a one-time code?\". It is asker-authored text the responder's device displays attributed to the asker, never as a statement the device itself vouches for.";
+        };
+        readonly note: {
+            readonly type: "string";
+            readonly minLength: 1;
+            readonly maxLength: 500;
+            readonly description: "OPTIONAL extra context from the asker. It is UNTRUSTED display text: the responder's device MUST render it as plain text, attributed to the asker and visually distinct from anything the device itself asserts, and MUST NOT interpret it as markup, a link, or an instruction.";
+        };
+        readonly expiresAt: {
+            readonly type: "string";
+            readonly format: "date-time";
+            readonly description: "The answer deadline. After this instant the pending question lapses: the responder does not prompt for it and the asker accepts no answer. It is the task's own deadline (SPEC §7.3 item 16); the envelope `expiresAt` bounds only acceptance of the request document.";
+        };
+    };
+    readonly $defs: {
+        readonly Response: {
+            readonly $anchor: "response";
+            readonly title: "Peer Check Ask Response Payload";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["challenge", "requestDigest", "decision", "respondedAt"];
+            readonly description: "The success-response payload: the responder's answer, signed by the responder. Failures use trust-task-error, not this shape. A responder that declines because it does not recognize the question answers with `decision: notConfirmed`; an error is for a document the responder could not act on at all.";
+            readonly dependentSchemas: {
+                readonly notConfirmedReason: {
+                    readonly properties: {
+                        readonly decision: {
+                            readonly const: "notConfirmed";
+                        };
+                    };
+                };
+            };
+            readonly properties: {
+                readonly challenge: {
+                    readonly type: "string";
+                    readonly pattern: "^[A-Za-z0-9_-]{22,86}$";
+                    readonly description: "The `challenge` of the request, echoed unchanged. The asker rejects an answer whose challenge it did not issue, or has already consumed.";
+                };
+                readonly requestDigest: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                    readonly description: "The task digest (SPEC §4.9.3) of the request document this answers: multibase(multihash(H(JCS(request without its top-level proof)))). It binds the answer to the exact question, challenge, note, parties and deadline the responder was shown, so a yes given to one ask cannot be presented as a yes to another.";
+                };
+                readonly decision: {
+                    readonly type: "string";
+                    readonly enum: readonly ["confirmed", "notConfirmed"];
+                    readonly description: "The responder's answer. `confirmed` means yes to the question as asked; `notConfirmed` means no.";
+                };
+                readonly respondedAt: {
+                    readonly type: "string";
+                    readonly format: "date-time";
+                    readonly description: "When the responder gave the answer, RFC 3339. Informational for the asker; freshness is judged against the request's `payload.expiresAt` and the asker's own clock. It is the time of the user's answer; the envelope `issuedAt` is when the responder signed the document, which may be later.";
+                };
+                readonly notConfirmedReason: {
+                    readonly type: "string";
+                    readonly enum: readonly ["notRecognized", "declined", "other"];
+                    readonly description: "OPTIONAL, and only with `decision: notConfirmed`, which the schema enforces; a document carrying it beside `confirmed` is invalid. `notRecognized` — the responder does not recognize what the question describes; `declined` — the responder recognizes it and says no; `other` — anything else. An enumeration rather than prose, so an asker never renders responder-authored text.";
+                };
+            };
+        };
+        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: "Peer Check Ask Response Payload";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["challenge", "requestDigest", "decision", "respondedAt"];
+            readonly description: "The success-response payload: the responder's answer, signed by the responder. Failures use trust-task-error, not this shape. A responder that declines because it does not recognize the question answers with `decision: notConfirmed`; an error is for a document the responder could not act on at all.";
+            readonly dependentSchemas: {
+                readonly notConfirmedReason: {
+                    readonly properties: {
+                        readonly decision: {
+                            readonly const: "notConfirmed";
+                        };
+                    };
+                };
+            };
+            readonly properties: {
+                readonly challenge: {
+                    readonly type: "string";
+                    readonly pattern: "^[A-Za-z0-9_-]{22,86}$";
+                    readonly description: "The `challenge` of the request, echoed unchanged. The asker rejects an answer whose challenge it did not issue, or has already consumed.";
+                };
+                readonly requestDigest: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                    readonly description: "The task digest (SPEC §4.9.3) of the request document this answers: multibase(multihash(H(JCS(request without its top-level proof)))). It binds the answer to the exact question, challenge, note, parties and deadline the responder was shown, so a yes given to one ask cannot be presented as a yes to another.";
+                };
+                readonly decision: {
+                    readonly type: "string";
+                    readonly enum: readonly ["confirmed", "notConfirmed"];
+                    readonly description: "The responder's answer. `confirmed` means yes to the question as asked; `notConfirmed` means no.";
+                };
+                readonly respondedAt: {
+                    readonly type: "string";
+                    readonly format: "date-time";
+                    readonly description: "When the responder gave the answer, RFC 3339. Informational for the asker; freshness is judged against the request's `payload.expiresAt` and the asker's own clock. It is the time of the user's answer; the envelope `issuedAt` is when the responder signed the document, which may be later.";
+                };
+                readonly notConfirmedReason: {
+                    readonly type: "string";
+                    readonly enum: readonly ["notRecognized", "declined", "other"];
+                    readonly description: "OPTIONAL, and only with `decision: notConfirmed`, which the schema enforces; a document carrying it beside `confirmed` is invalid. `notRecognized` — the responder does not recognize what the question describes; `declined` — the responder recognizes it and says no; `other` — anything else. An enumeration rather than prose, so an asker never renders responder-authored text.";
+                };
+            };
+        };
+        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, and
+ * item 2 needs the schema this carries.
+ */
+export declare const SPEC: {
+    readonly typeUri: "https://trusttasks.org/spec/peer-check/ask/0.1";
+    readonly isBearer: false;
+    readonly isProofRequired: true;
+    readonly isRecipientRequired: true;
+    readonly isIssuedAtRequired: true;
+    readonly payloadSchema: {
+        readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+        readonly $id: "https://trusttasks.org/spec/peer-check/ask/0.1";
+        readonly title: "Peer Check — Ask — payload";
+        readonly description: "The request payload of peer-check/ask: a short yes-or-no question one party puts to another, with an unguessable challenge. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3. The asker is the `issuer`, the party being asked is the `recipient`, and the payload MUST carry `expiresAt`, the deadline for the answer. The envelope `expiresAt` keeps its framework meaning (SPEC §4.2): after it the responder does not prompt for the request.";
+        readonly type: "object";
+        readonly additionalProperties: false;
+        readonly required: readonly ["challenge", "question", "expiresAt"];
+        readonly properties: {
+            readonly challenge: {
+                readonly type: "string";
+                readonly pattern: "^[A-Za-z0-9_-]{22,86}$";
+                readonly description: "An unguessable value the asker generates for this one question: at least 128 bits from a cryptographically secure random source, encoded base64url without padding (22 to 86 characters). The responder echoes it unchanged in its answer.";
+            };
+            readonly question: {
+                readonly type: "string";
+                readonly minLength: 1;
+                readonly maxLength: 200;
+                readonly description: "What the asker wants confirmed, in one short sentence, for example \"Did you just ask me to send you a one-time code?\". It is asker-authored text the responder's device displays attributed to the asker, never as a statement the device itself vouches for.";
+            };
+            readonly note: {
+                readonly type: "string";
+                readonly minLength: 1;
+                readonly maxLength: 500;
+                readonly description: "OPTIONAL extra context from the asker. It is UNTRUSTED display text: the responder's device MUST render it as plain text, attributed to the asker and visually distinct from anything the device itself asserts, and MUST NOT interpret it as markup, a link, or an instruction.";
+            };
+            readonly expiresAt: {
+                readonly type: "string";
+                readonly format: "date-time";
+                readonly description: "The answer deadline. After this instant the pending question lapses: the responder does not prompt for it and the asker accepts no answer. It is the task's own deadline (SPEC §7.3 item 16); the envelope `expiresAt` bounds only acceptance of the request document.";
+            };
+        };
+        readonly $defs: {
+            readonly Response: {
+                readonly $anchor: "response";
+                readonly title: "Peer Check Ask Response Payload";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["challenge", "requestDigest", "decision", "respondedAt"];
+                readonly description: "The success-response payload: the responder's answer, signed by the responder. Failures use trust-task-error, not this shape. A responder that declines because it does not recognize the question answers with `decision: notConfirmed`; an error is for a document the responder could not act on at all.";
+                readonly dependentSchemas: {
+                    readonly notConfirmedReason: {
+                        readonly properties: {
+                            readonly decision: {
+                                readonly const: "notConfirmed";
+                            };
+                        };
+                    };
+                };
+                readonly properties: {
+                    readonly challenge: {
+                        readonly type: "string";
+                        readonly pattern: "^[A-Za-z0-9_-]{22,86}$";
+                        readonly description: "The `challenge` of the request, echoed unchanged. The asker rejects an answer whose challenge it did not issue, or has already consumed.";
+                    };
+                    readonly requestDigest: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                        readonly description: "The task digest (SPEC §4.9.3) of the request document this answers: multibase(multihash(H(JCS(request without its top-level proof)))). It binds the answer to the exact question, challenge, note, parties and deadline the responder was shown, so a yes given to one ask cannot be presented as a yes to another.";
+                    };
+                    readonly decision: {
+                        readonly type: "string";
+                        readonly enum: readonly ["confirmed", "notConfirmed"];
+                        readonly description: "The responder's answer. `confirmed` means yes to the question as asked; `notConfirmed` means no.";
+                    };
+                    readonly respondedAt: {
+                        readonly type: "string";
+                        readonly format: "date-time";
+                        readonly description: "When the responder gave the answer, RFC 3339. Informational for the asker; freshness is judged against the request's `payload.expiresAt` and the asker's own clock. It is the time of the user's answer; the envelope `issuedAt` is when the responder signed the document, which may be later.";
+                    };
+                    readonly notConfirmedReason: {
+                        readonly type: "string";
+                        readonly enum: readonly ["notRecognized", "declined", "other"];
+                        readonly description: "OPTIONAL, and only with `decision: notConfirmed`, which the schema enforces; a document carrying it beside `confirmed` is invalid. `notRecognized` — the responder does not recognize what the question describes; `declined` — the responder recognizes it and says no; `other` — anything else. An enumeration rather than prose, so an asker never renders responder-authored text.";
+                    };
+                };
+            };
+            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`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export declare const RESPONSE_SPEC: {
+    readonly typeUri: "https://trusttasks.org/spec/peer-check/ask/0.1#response";
+    readonly isBearer: false;
+    readonly isProofRequired: true;
+    readonly isRecipientRequired: true;
+    readonly isIssuedAtRequired: 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: "Peer Check Ask Response Payload";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["challenge", "requestDigest", "decision", "respondedAt"];
+                readonly description: "The success-response payload: the responder's answer, signed by the responder. Failures use trust-task-error, not this shape. A responder that declines because it does not recognize the question answers with `decision: notConfirmed`; an error is for a document the responder could not act on at all.";
+                readonly dependentSchemas: {
+                    readonly notConfirmedReason: {
+                        readonly properties: {
+                            readonly decision: {
+                                readonly const: "notConfirmed";
+                            };
+                        };
+                    };
+                };
+                readonly properties: {
+                    readonly challenge: {
+                        readonly type: "string";
+                        readonly pattern: "^[A-Za-z0-9_-]{22,86}$";
+                        readonly description: "The `challenge` of the request, echoed unchanged. The asker rejects an answer whose challenge it did not issue, or has already consumed.";
+                    };
+                    readonly requestDigest: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                        readonly description: "The task digest (SPEC §4.9.3) of the request document this answers: multibase(multihash(H(JCS(request without its top-level proof)))). It binds the answer to the exact question, challenge, note, parties and deadline the responder was shown, so a yes given to one ask cannot be presented as a yes to another.";
+                    };
+                    readonly decision: {
+                        readonly type: "string";
+                        readonly enum: readonly ["confirmed", "notConfirmed"];
+                        readonly description: "The responder's answer. `confirmed` means yes to the question as asked; `notConfirmed` means no.";
+                    };
+                    readonly respondedAt: {
+                        readonly type: "string";
+                        readonly format: "date-time";
+                        readonly description: "When the responder gave the answer, RFC 3339. Informational for the asker; freshness is judged against the request's `payload.expiresAt` and the asker's own clock. It is the time of the user's answer; the envelope `issuedAt` is when the responder signed the document, which may be later.";
+                    };
+                    readonly notConfirmedReason: {
+                        readonly type: "string";
+                        readonly enum: readonly ["notRecognized", "declined", "other"];
+                        readonly description: "OPTIONAL, and only with `decision: notConfirmed`, which the schema enforces; a document carrying it beside `confirmed` is invalid. `notRecognized` — the responder does not recognize what the question describes; `declined` — the responder recognizes it and says no; `other` — anything else. An enumeration rather than prose, so an asker never renders responder-authored text.";
+                    };
+                };
+            };
+            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/peer-check/ask/0.1/payload.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../src/peer-check/ask/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,gCAAgC,CAAC;AAGtE;;GAEG;AACH,MAAM,WAAW,mBAAmB;IAClC;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;IAClB;;OAEG;IACH,QAAQ,EAAE,MAAM,CAAC;IACjB;;OAEG;IACH,IAAI,CAAC,EAAE,MAAM,CAAC;IACd;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;CACnB;AACD;;GAEG;AACH,MAAM,WAAW,2BAA2B;IAC1C;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;IAClB;;OAEG;IACH,aAAa,EAAE,eAAe,CAAC;IAC/B;;OAEG;IACH,QAAQ,EAAE,WAAW,GAAG,cAAc,CAAC;IACvC;;OAEG;IACH,WAAW,EAAE,MAAM,CAAC;IACpB;;OAEG;IACH,kBAAkB,CAAC,EAAE,eAAe,GAAG,UAAU,GAAG,OAAO,CAAC;CAC7D;AAED,kHAAkH;AAClH,YAAY,EAAE,eAAe,EAAE,CAAC;AAEhC,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,gDAAyD,CAAC;AAElF;;;;;GAKG;AACH,eAAO,MAAM,OAAO,EAAE,MAAM,GAAG,IAAW,CAAC;AAE3C;;;;;GAKG;AACH,eAAO,MAAM,WAAW,EAAE,MAAM,GAAG,IAAW,CAAC;AAE/C,mEAAmE;AACnE,MAAM,MAAM,OAAO,GAAG,mBAAmB,CAAC;AAE1C,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,yDAAkE,CAAC;AAEpG,4EAA4E;AAC5E,MAAM,MAAM,QAAQ,GAAG,2BAA2B,CAAC;AAEnD;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAuGjB,CAAC;AAEX,mEAAmE;AACnE,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsE1B,CAAC;AAEX;;;;;GAKG;AACH,eAAO,MAAM,IAAI;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAOP,CAAC;AAEX;;;;GAIG;AACH,eAAO,MAAM,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAOhB,CAAC"}