@openvtc/trust-tasks 0.24.0 → 0.24.1

package/dist/vtc/join-requests/wallet-session/start/0.1/payload.d.ts

@@ -0,0 +1,398 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/vtc/join-requests/wallet-session/start/0.1/payload.schema.json
+ */
+import type { DigestMultibase, Ext } from "../../../../../_shared/components.js";
+/**
+ * An applicant asks the community to open an OpenID4VP 1.0 presentation session for one of its join criteria, so that a wallet which cannot sign Trust Tasks can present credentials as evidence for the applicant's join. The applicant is the document proof's signer, not a payload member. The outer document members are owned by the framework — SPEC §6.3.
+ */
+export interface VTCJoinRequestsWalletSessionStartPayload {
+    /**
+     * The `requirementsDigest` of the criterion the applicant is gathering evidence for, as vtc/join-requests/manifest/0.3 published it — the same value vtc/join-requests/submit/0.3 carries as its `criterion`. Naming the version, not only the criterion, fixes the DCQL query the wallet is asked to satisfy to the one the applicant read.
+     */
+    criterion: DigestMultibase;
+    /**
+     * An existing join request of the applicant's to record the evidence on. Absent: the community holds the evidence, for a bounded period of its own policy, for the applicant's next vtc/join-requests/submit under the same criterion.
+     */
+    requestId?: string;
+    /**
+     * The OpenID4VP 1.0 client identifier prefix the community should identify itself to the wallet with — a DID (`decentralized_identifier`, as swiyu wallets expect) or an X.509 certificate (`x509_hash`, as EUDI wallets expect). Values are OpenID4VP's own and are carried verbatim. Absent: the community's default. A community holding no verifier identity of the requested kind refuses with `verifierNotConfigured`.
+     */
+    clientIdPrefix?: "decentralized_identifier" | "x509_hash";
+    ext?: Ext;
+}
+export interface VTCJoinRequestsWalletSessionStartResponsePayload {
+    /**
+     * Opaque, unguessable identifier of the session, carrying at least 128 bits of entropy. The applicant reads the outcome with vtc/join-requests/wallet-session/status under it.
+     */
+    sessionId: string;
+    /**
+     * The OpenID4VP invocation URI for this session, carrying `client_id` and `request_uri`, to be rendered as a QR code or opened as a deep link. Its scheme is the community's choice for the wallet ecosystem it serves — `openid4vp://`, `swiyu-verify://`, `haip-vp://` and others.
+     */
+    walletUri: string;
+    /**
+     * The full OpenID4VP client identifier the community presents to the wallet, prefix included (`decentralized_identifier:did:webvh:…`, `x509_hash:…`). It is the audience the wallet's key-binding JWT will name.
+     */
+    clientId: string;
+    /**
+     * The DCQL query (OpenID4VP 1.0 §6) the wallet will be asked to satisfy: the criterion's published query, unchanged. Opaque here; its members are DCQL's own and keep DCQL's snake_case names.
+     */
+    dcqlQuery: {};
+    /**
+     * When the session closes if no wallet has answered it. Minutes, not hours.
+     */
+    expiresAt: string;
+    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 declare const TYPE_URI: "https://trusttasks.org/spec/vtc/join-requests/wallet-session/start/0.1";
+/** Stable alias for this specification's request payload shape. */
+export type Payload = VTCJoinRequestsWalletSessionStartPayload;
+/** Trust Task response type URI (request type URI + "#response"). */
+export declare const RESPONSE_TYPE_URI: "https://trusttasks.org/spec/vtc/join-requests/wallet-session/start/0.1#response";
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = VTCJoinRequestsWalletSessionStartResponsePayload;
+/**
+ * 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/vtc/join-requests/wallet-session/start/0.1";
+    readonly title: "VTC Join-Requests Wallet Session Start — payload";
+    readonly description: "An applicant asks the community to open an OpenID4VP 1.0 presentation session for one of its join criteria, so that a wallet which cannot sign Trust Tasks can present credentials as evidence for the applicant's join. The applicant is the document proof's signer, not a payload member. The outer document members are owned by the framework — SPEC §6.3.";
+    readonly type: "object";
+    readonly additionalProperties: false;
+    readonly required: readonly ["criterion"];
+    readonly properties: {
+        readonly criterion: {
+            readonly $ref: "#/$defs/DigestMultibase";
+            readonly description: "The `requirementsDigest` of the criterion the applicant is gathering evidence for, as vtc/join-requests/manifest/0.3 published it — the same value vtc/join-requests/submit/0.3 carries as its `criterion`. Naming the version, not only the criterion, fixes the DCQL query the wallet is asked to satisfy to the one the applicant read.";
+        };
+        readonly requestId: {
+            readonly type: "string";
+            readonly minLength: 1;
+            readonly maxLength: 128;
+            readonly description: "An existing join request of the applicant's to record the evidence on. Absent: the community holds the evidence, for a bounded period of its own policy, for the applicant's next vtc/join-requests/submit under the same criterion.";
+        };
+        readonly clientIdPrefix: {
+            readonly type: "string";
+            readonly enum: readonly ["decentralized_identifier", "x509_hash"];
+            readonly description: "The OpenID4VP 1.0 client identifier prefix the community should identify itself to the wallet with — a DID (`decentralized_identifier`, as swiyu wallets expect) or an X.509 certificate (`x509_hash`, as EUDI wallets expect). Values are OpenID4VP's own and are carried verbatim. Absent: the community's default. A community holding no verifier identity of the requested kind refuses with `verifierNotConfigured`.";
+        };
+        readonly ext: {
+            readonly $ref: "#/$defs/Ext";
+        };
+    };
+    readonly $defs: {
+        readonly Response: {
+            readonly $anchor: "response";
+            readonly title: "VTC Join-Requests Wallet Session Start — response payload";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["sessionId", "walletUri", "clientId", "dcqlQuery", "expiresAt"];
+            readonly properties: {
+                readonly sessionId: {
+                    readonly type: "string";
+                    readonly minLength: 16;
+                    readonly maxLength: 128;
+                    readonly description: "Opaque, unguessable identifier of the session, carrying at least 128 bits of entropy. The applicant reads the outcome with vtc/join-requests/wallet-session/status under it.";
+                };
+                readonly walletUri: {
+                    readonly type: "string";
+                    readonly format: "uri";
+                    readonly minLength: 1;
+                    readonly maxLength: 4096;
+                    readonly description: "The OpenID4VP invocation URI for this session, carrying `client_id` and `request_uri`, to be rendered as a QR code or opened as a deep link. Its scheme is the community's choice for the wallet ecosystem it serves — `openid4vp://`, `swiyu-verify://`, `haip-vp://` and others.";
+                };
+                readonly clientId: {
+                    readonly type: "string";
+                    readonly minLength: 1;
+                    readonly maxLength: 2048;
+                    readonly description: "The full OpenID4VP client identifier the community presents to the wallet, prefix included (`decentralized_identifier:did:webvh:…`, `x509_hash:…`). It is the audience the wallet's key-binding JWT will name.";
+                };
+                readonly dcqlQuery: {
+                    readonly type: "object";
+                    readonly description: "The DCQL query (OpenID4VP 1.0 §6) the wallet will be asked to satisfy: the criterion's published query, unchanged. Opaque here; its members are DCQL's own and keep DCQL's snake_case names.";
+                };
+                readonly expiresAt: {
+                    readonly type: "string";
+                    readonly format: "date-time";
+                    readonly description: "When the session closes if no wallet has answered it. Minutes, not hours.";
+                };
+                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: "VTC Join-Requests Wallet Session Start — response payload";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["sessionId", "walletUri", "clientId", "dcqlQuery", "expiresAt"];
+            readonly properties: {
+                readonly sessionId: {
+                    readonly type: "string";
+                    readonly minLength: 16;
+                    readonly maxLength: 128;
+                    readonly description: "Opaque, unguessable identifier of the session, carrying at least 128 bits of entropy. The applicant reads the outcome with vtc/join-requests/wallet-session/status under it.";
+                };
+                readonly walletUri: {
+                    readonly type: "string";
+                    readonly format: "uri";
+                    readonly minLength: 1;
+                    readonly maxLength: 4096;
+                    readonly description: "The OpenID4VP invocation URI for this session, carrying `client_id` and `request_uri`, to be rendered as a QR code or opened as a deep link. Its scheme is the community's choice for the wallet ecosystem it serves — `openid4vp://`, `swiyu-verify://`, `haip-vp://` and others.";
+                };
+                readonly clientId: {
+                    readonly type: "string";
+                    readonly minLength: 1;
+                    readonly maxLength: 2048;
+                    readonly description: "The full OpenID4VP client identifier the community presents to the wallet, prefix included (`decentralized_identifier:did:webvh:…`, `x509_hash:…`). It is the audience the wallet's key-binding JWT will name.";
+                };
+                readonly dcqlQuery: {
+                    readonly type: "object";
+                    readonly description: "The DCQL query (OpenID4VP 1.0 §6) the wallet will be asked to satisfy: the criterion's published query, unchanged. Opaque here; its members are DCQL's own and keep DCQL's snake_case names.";
+                };
+                readonly expiresAt: {
+                    readonly type: "string";
+                    readonly format: "date-time";
+                    readonly description: "When the session closes if no wallet has answered it. Minutes, not hours.";
+                };
+                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, and
+ * item 2 needs the schema this carries.
+ */
+export declare const SPEC: {
+    readonly typeUri: "https://trusttasks.org/spec/vtc/join-requests/wallet-session/start/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/vtc/join-requests/wallet-session/start/0.1";
+        readonly title: "VTC Join-Requests Wallet Session Start — payload";
+        readonly description: "An applicant asks the community to open an OpenID4VP 1.0 presentation session for one of its join criteria, so that a wallet which cannot sign Trust Tasks can present credentials as evidence for the applicant's join. The applicant is the document proof's signer, not a payload member. The outer document members are owned by the framework — SPEC §6.3.";
+        readonly type: "object";
+        readonly additionalProperties: false;
+        readonly required: readonly ["criterion"];
+        readonly properties: {
+            readonly criterion: {
+                readonly $ref: "#/$defs/DigestMultibase";
+                readonly description: "The `requirementsDigest` of the criterion the applicant is gathering evidence for, as vtc/join-requests/manifest/0.3 published it — the same value vtc/join-requests/submit/0.3 carries as its `criterion`. Naming the version, not only the criterion, fixes the DCQL query the wallet is asked to satisfy to the one the applicant read.";
+            };
+            readonly requestId: {
+                readonly type: "string";
+                readonly minLength: 1;
+                readonly maxLength: 128;
+                readonly description: "An existing join request of the applicant's to record the evidence on. Absent: the community holds the evidence, for a bounded period of its own policy, for the applicant's next vtc/join-requests/submit under the same criterion.";
+            };
+            readonly clientIdPrefix: {
+                readonly type: "string";
+                readonly enum: readonly ["decentralized_identifier", "x509_hash"];
+                readonly description: "The OpenID4VP 1.0 client identifier prefix the community should identify itself to the wallet with — a DID (`decentralized_identifier`, as swiyu wallets expect) or an X.509 certificate (`x509_hash`, as EUDI wallets expect). Values are OpenID4VP's own and are carried verbatim. Absent: the community's default. A community holding no verifier identity of the requested kind refuses with `verifierNotConfigured`.";
+            };
+            readonly ext: {
+                readonly $ref: "#/$defs/Ext";
+            };
+        };
+        readonly $defs: {
+            readonly Response: {
+                readonly $anchor: "response";
+                readonly title: "VTC Join-Requests Wallet Session Start — response payload";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["sessionId", "walletUri", "clientId", "dcqlQuery", "expiresAt"];
+                readonly properties: {
+                    readonly sessionId: {
+                        readonly type: "string";
+                        readonly minLength: 16;
+                        readonly maxLength: 128;
+                        readonly description: "Opaque, unguessable identifier of the session, carrying at least 128 bits of entropy. The applicant reads the outcome with vtc/join-requests/wallet-session/status under it.";
+                    };
+                    readonly walletUri: {
+                        readonly type: "string";
+                        readonly format: "uri";
+                        readonly minLength: 1;
+                        readonly maxLength: 4096;
+                        readonly description: "The OpenID4VP invocation URI for this session, carrying `client_id` and `request_uri`, to be rendered as a QR code or opened as a deep link. Its scheme is the community's choice for the wallet ecosystem it serves — `openid4vp://`, `swiyu-verify://`, `haip-vp://` and others.";
+                    };
+                    readonly clientId: {
+                        readonly type: "string";
+                        readonly minLength: 1;
+                        readonly maxLength: 2048;
+                        readonly description: "The full OpenID4VP client identifier the community presents to the wallet, prefix included (`decentralized_identifier:did:webvh:…`, `x509_hash:…`). It is the audience the wallet's key-binding JWT will name.";
+                    };
+                    readonly dcqlQuery: {
+                        readonly type: "object";
+                        readonly description: "The DCQL query (OpenID4VP 1.0 §6) the wallet will be asked to satisfy: the criterion's published query, unchanged. Opaque here; its members are DCQL's own and keep DCQL's snake_case names.";
+                    };
+                    readonly expiresAt: {
+                        readonly type: "string";
+                        readonly format: "date-time";
+                        readonly description: "When the session closes if no wallet has answered it. Minutes, not hours.";
+                    };
+                    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`
+ * 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/vtc/join-requests/wallet-session/start/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: "VTC Join-Requests Wallet Session Start — response payload";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["sessionId", "walletUri", "clientId", "dcqlQuery", "expiresAt"];
+                readonly properties: {
+                    readonly sessionId: {
+                        readonly type: "string";
+                        readonly minLength: 16;
+                        readonly maxLength: 128;
+                        readonly description: "Opaque, unguessable identifier of the session, carrying at least 128 bits of entropy. The applicant reads the outcome with vtc/join-requests/wallet-session/status under it.";
+                    };
+                    readonly walletUri: {
+                        readonly type: "string";
+                        readonly format: "uri";
+                        readonly minLength: 1;
+                        readonly maxLength: 4096;
+                        readonly description: "The OpenID4VP invocation URI for this session, carrying `client_id` and `request_uri`, to be rendered as a QR code or opened as a deep link. Its scheme is the community's choice for the wallet ecosystem it serves — `openid4vp://`, `swiyu-verify://`, `haip-vp://` and others.";
+                    };
+                    readonly clientId: {
+                        readonly type: "string";
+                        readonly minLength: 1;
+                        readonly maxLength: 2048;
+                        readonly description: "The full OpenID4VP client identifier the community presents to the wallet, prefix included (`decentralized_identifier:did:webvh:…`, `x509_hash:…`). It is the audience the wallet's key-binding JWT will name.";
+                    };
+                    readonly dcqlQuery: {
+                        readonly type: "object";
+                        readonly description: "The DCQL query (OpenID4VP 1.0 §6) the wallet will be asked to satisfy: the criterion's published query, unchanged. Opaque here; its members are DCQL's own and keep DCQL's snake_case names.";
+                    };
+                    readonly expiresAt: {
+                        readonly type: "string";
+                        readonly format: "date-time";
+                        readonly description: "When the session closes if no wallet has answered it. Minutes, not hours.";
+                    };
+                    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/vtc/join-requests/wallet-session/start/0.1/payload.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../../src/vtc/join-requests/wallet-session/start/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,OAAO,KAAK,EAAE,eAAe,EAAE,GAAG,EAAE,MAAM,sCAAsC,CAAC;AAGjF;;GAEG;AACH,MAAM,WAAW,wCAAwC;IACvD;;OAEG;IACH,SAAS,EAAE,eAAe,CAAC;IAC3B;;OAEG;IACH,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB;;OAEG;IACH,cAAc,CAAC,EAAE,0BAA0B,GAAG,WAAW,CAAC;IAC1D,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD,MAAM,WAAW,gDAAgD;IAC/D;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;IAClB;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;IAClB;;OAEG;IACH,QAAQ,EAAE,MAAM,CAAC;IACjB;;OAEG;IACH,SAAS,EAAE,EAAE,CAAC;IACd;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;IAClB,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AAED,kHAAkH;AAClH,YAAY,EAAE,eAAe,EAAE,GAAG,EAAE,CAAC;AAErC,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,wEAAiF,CAAC;AAE1G,mEAAmE;AACnE,MAAM,MAAM,OAAO,GAAG,wCAAwC,CAAC;AAE/D,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,iFAA0F,CAAC;AAE5H,4EAA4E;AAC5E,MAAM,MAAM,QAAQ,GAAG,gDAAgD,CAAC;AAExE;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqGjB,CAAC;AAEX,mEAAmE;AACnE,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAuE1B,CAAC;AAEX;;;;;GAKG;AACH,eAAO,MAAM,IAAI;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAOP,CAAC;AAEX;;;;GAIG;AACH,eAAO,MAAM,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAOhB,CAAC"}

package/dist/vtc/join-requests/wallet-session/start/0.1/payload.js

@@ -0,0 +1,220 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/vtc/join-requests/wallet-session/start/0.1/payload.schema.json
+ */
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/vtc/join-requests/wallet-session/start/0.1";
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/vtc/join-requests/wallet-session/start/0.1#response";
+/**
+ * This specification's payload schema, as a value.
+ *
+ * SPEC.md §7.2 item 2 is performed against this. It is shipped as data
+ * rather than only as a `.json` file because TypeScript types are erased
+ * at runtime: without a schema a consumer has nothing to validate, and
+ * every REQUIRED payload member is optional in practice. Cross-file
+ * `$ref`s are already inlined, so it needs no resolver.
+ */
+export const PAYLOAD_SCHEMA = {
+    "$schema": "https://json-schema.org/draft/2020-12/schema",
+    "$id": "https://trusttasks.org/spec/vtc/join-requests/wallet-session/start/0.1",
+    "title": "VTC Join-Requests Wallet Session Start — payload",
+    "description": "An applicant asks the community to open an OpenID4VP 1.0 presentation session for one of its join criteria, so that a wallet which cannot sign Trust Tasks can present credentials as evidence for the applicant's join. The applicant is the document proof's signer, not a payload member. The outer document members are owned by the framework — SPEC §6.3.",
+    "type": "object",
+    "additionalProperties": false,
+    "required": [
+        "criterion"
+    ],
+    "properties": {
+        "criterion": {
+            "$ref": "#/$defs/DigestMultibase",
+            "description": "The `requirementsDigest` of the criterion the applicant is gathering evidence for, as vtc/join-requests/manifest/0.3 published it — the same value vtc/join-requests/submit/0.3 carries as its `criterion`. Naming the version, not only the criterion, fixes the DCQL query the wallet is asked to satisfy to the one the applicant read."
+        },
+        "requestId": {
+            "type": "string",
+            "minLength": 1,
+            "maxLength": 128,
+            "description": "An existing join request of the applicant's to record the evidence on. Absent: the community holds the evidence, for a bounded period of its own policy, for the applicant's next vtc/join-requests/submit under the same criterion."
+        },
+        "clientIdPrefix": {
+            "type": "string",
+            "enum": [
+                "decentralized_identifier",
+                "x509_hash"
+            ],
+            "description": "The OpenID4VP 1.0 client identifier prefix the community should identify itself to the wallet with — a DID (`decentralized_identifier`, as swiyu wallets expect) or an X.509 certificate (`x509_hash`, as EUDI wallets expect). Values are OpenID4VP's own and are carried verbatim. Absent: the community's default. A community holding no verifier identity of the requested kind refuses with `verifierNotConfigured`."
+        },
+        "ext": {
+            "$ref": "#/$defs/Ext"
+        }
+    },
+    "$defs": {
+        "Response": {
+            "$anchor": "response",
+            "title": "VTC Join-Requests Wallet Session Start — response payload",
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "sessionId",
+                "walletUri",
+                "clientId",
+                "dcqlQuery",
+                "expiresAt"
+            ],
+            "properties": {
+                "sessionId": {
+                    "type": "string",
+                    "minLength": 16,
+                    "maxLength": 128,
+                    "description": "Opaque, unguessable identifier of the session, carrying at least 128 bits of entropy. The applicant reads the outcome with vtc/join-requests/wallet-session/status under it."
+                },
+                "walletUri": {
+                    "type": "string",
+                    "format": "uri",
+                    "minLength": 1,
+                    "maxLength": 4096,
+                    "description": "The OpenID4VP invocation URI for this session, carrying `client_id` and `request_uri`, to be rendered as a QR code or opened as a deep link. Its scheme is the community's choice for the wallet ecosystem it serves — `openid4vp://`, `swiyu-verify://`, `haip-vp://` and others."
+                },
+                "clientId": {
+                    "type": "string",
+                    "minLength": 1,
+                    "maxLength": 2048,
+                    "description": "The full OpenID4VP client identifier the community presents to the wallet, prefix included (`decentralized_identifier:did:webvh:…`, `x509_hash:…`). It is the audience the wallet's key-binding JWT will name."
+                },
+                "dcqlQuery": {
+                    "type": "object",
+                    "description": "The DCQL query (OpenID4VP 1.0 §6) the wallet will be asked to satisfy: the criterion's published query, unchanged. Opaque here; its members are DCQL's own and keep DCQL's snake_case names."
+                },
+                "expiresAt": {
+                    "type": "string",
+                    "format": "date-time",
+                    "description": "When the session closes if no wallet has answered it. Minutes, not hours."
+                },
+                "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": "VTC Join-Requests Wallet Session Start — response payload",
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "sessionId",
+                "walletUri",
+                "clientId",
+                "dcqlQuery",
+                "expiresAt"
+            ],
+            "properties": {
+                "sessionId": {
+                    "type": "string",
+                    "minLength": 16,
+                    "maxLength": 128,
+                    "description": "Opaque, unguessable identifier of the session, carrying at least 128 bits of entropy. The applicant reads the outcome with vtc/join-requests/wallet-session/status under it."
+                },
+                "walletUri": {
+                    "type": "string",
+                    "format": "uri",
+                    "minLength": 1,
+                    "maxLength": 4096,
+                    "description": "The OpenID4VP invocation URI for this session, carrying `client_id` and `request_uri`, to be rendered as a QR code or opened as a deep link. Its scheme is the community's choice for the wallet ecosystem it serves — `openid4vp://`, `swiyu-verify://`, `haip-vp://` and others."
+                },
+                "clientId": {
+                    "type": "string",
+                    "minLength": 1,
+                    "maxLength": 2048,
+                    "description": "The full OpenID4VP client identifier the community presents to the wallet, prefix included (`decentralized_identifier:did:webvh:…`, `x509_hash:…`). It is the audience the wallet's key-binding JWT will name."
+                },
+                "dcqlQuery": {
+                    "type": "object",
+                    "description": "The DCQL query (OpenID4VP 1.0 §6) the wallet will be asked to satisfy: the criterion's published query, unchanged. Opaque here; its members are DCQL's own and keep DCQL's snake_case names."
+                },
+                "expiresAt": {
+                    "type": "string",
+                    "format": "date-time",
+                    "description": "When the session closes if no wallet has answered it. Minutes, not hours."
+                },
+                "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, and
+ * item 2 needs the schema this carries.
+ */
+export const SPEC = {
+    typeUri: TYPE_URI,
+    isBearer: false,
+    isProofRequired: true,
+    isRecipientRequired: true,
+    isIssuedAtRequired: true,
+    payloadSchema: PAYLOAD_SCHEMA,
+};
+/**
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export const RESPONSE_SPEC = {
+    typeUri: RESPONSE_TYPE_URI,
+    isBearer: false,
+    isProofRequired: true,
+    isRecipientRequired: true,
+    isIssuedAtRequired: true,
+    payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+};
+//# sourceMappingURL=payload.js.map