@openvtc/trust-tasks 0.24.0 → 0.24.2

package/src/keys/sign-jws/0.1/payload.ts

@@ -0,0 +1,271 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/keys/sign-jws/0.1/payload.schema.json
+ */
+
+import type { Ext } from "../../../_shared/components.js";
+
+
+/**
+ * A request for a compact JWS (RFC 7515) made with a key the custodian holds. The producer supplies the protected header members it wants and the payload; the custodian sets `alg` from the key, serialises both itself, and signs the JWS signing input with no framing of its own. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3.
+ */
+export type KeysSignJWSPayload = {
+  /**
+   * Identifier of the key to sign with, as `keys/show` describes it. The key MUST be `active` and of a type with a JOSE signature algorithm.
+   */
+  keyId: string;
+  /**
+   * Protected header members the producer wants in the JWS — `typ`, `kid`, `x5c`, `cty`, or a profile's own (swiyu's `profile_version`). Member names and values are JOSE's and the profile's, carried verbatim. The custodian adds `alg` itself and refuses `alg`, `crit`, `b64`, `jwk`, `jku` and `x5u` (see the specification's Conformance section). Absent means a header of `alg` alone.
+   */
+  header?: {};
+  /**
+   * The JWS payload, as a JSON object — for an OpenID4VP request object or any other JWT, its claims set. The custodian serialises it (RFC 8785) and base64url-encodes the result. Exactly one of `payload` and `payloadBase64Url` is present.
+   */
+  payload?: {};
+  /**
+   * The JWS payload as bytes, for a payload that is not a JSON object, base64url-encoded without padding. The custodian uses this string as the payload segment unchanged, after checking it is the canonical encoding of the bytes it decodes to. Exactly one of `payload` and `payloadBase64Url` is present.
+   */
+  payloadBase64Url?: string;
+  /**
+   * Ecosystem-defined extension members per SPEC.md §4.5.1.
+   */
+  ext?: Ext;
+} & {
+  [k: string]: unknown | undefined;
+};
+
+/**
+ * The success response to a keys/sign-jws request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/keys/sign-jws/0.1#response. Failures use trust-task-error, not this shape.
+ */
+export interface KeysSignJWSResponsePayload {
+  /**
+   * The key that produced the signature. Echoed so a response separated from its request is still attributable.
+   */
+  keyId: string;
+  /**
+   * The JOSE algorithm the custodian chose from the key's type and wrote into the header: `EdDSA` for `ed25519`, `ES256` for `p256`, `ES256K` for a secp256k1 key, `ML-DSA-44` and `ML-DSA-65` for `mldsa44` and `mldsa65`. Externally owned, carried verbatim.
+   */
+  alg: "EdDSA" | "ES256" | "ES256K" | "ML-DSA-44" | "ML-DSA-65";
+  /**
+   * The JWS in compact serialisation: BASE64URL(header) '.' BASE64URL(payload) '.' BASE64URL(signature), unpadded. For ECDSA the signature is the fixed-width `r || s` of RFC 7518 §3.4, not DER.
+   */
+  jws: string;
+  ext?: Ext;
+}
+
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { Ext };
+
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/keys/sign-jws/0.1" as const;
+
+/** Stable alias for this specification's request payload shape. */
+export type Payload = KeysSignJWSPayload;
+
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/keys/sign-jws/0.1#response" as const;
+
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = KeysSignJWSResponsePayload;
+
+/**
+ * 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/keys/sign-jws/0.1",
+  "title": "Keys — Sign JWS — payload",
+  "description": "A request for a compact JWS (RFC 7515) made with a key the custodian holds. The producer supplies the protected header members it wants and the payload; the custodian sets `alg` from the key, serialises both itself, and signs the JWS signing input with no framing of its own. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "keyId"
+  ],
+  "oneOf": [
+    {
+      "required": [
+        "payload"
+      ],
+      "not": {
+        "required": [
+          "payloadBase64Url"
+        ]
+      }
+    },
+    {
+      "required": [
+        "payloadBase64Url"
+      ],
+      "not": {
+        "required": [
+          "payload"
+        ]
+      }
+    }
+  ],
+  "properties": {
+    "keyId": {
+      "type": "string",
+      "minLength": 1,
+      "description": "Identifier of the key to sign with, as `keys/show` describes it. The key MUST be `active` and of a type with a JOSE signature algorithm."
+    },
+    "header": {
+      "type": "object",
+      "maxProperties": 32,
+      "description": "Protected header members the producer wants in the JWS — `typ`, `kid`, `x5c`, `cty`, or a profile's own (swiyu's `profile_version`). Member names and values are JOSE's and the profile's, carried verbatim. The custodian adds `alg` itself and refuses `alg`, `crit`, `b64`, `jwk`, `jku` and `x5u` (see the specification's Conformance section). Absent means a header of `alg` alone."
+    },
+    "payload": {
+      "type": "object",
+      "description": "The JWS payload, as a JSON object — for an OpenID4VP request object or any other JWT, its claims set. The custodian serialises it (RFC 8785) and base64url-encodes the result. Exactly one of `payload` and `payloadBase64Url` is present."
+    },
+    "payloadBase64Url": {
+      "type": "string",
+      "minLength": 2,
+      "pattern": "^[A-Za-z0-9_-]+$",
+      "description": "The JWS payload as bytes, for a payload that is not a JSON object, base64url-encoded without padding. The custodian uses this string as the payload segment unchanged, after checking it is the canonical encoding of the bytes it decodes to. Exactly one of `payload` and `payloadBase64Url` is present."
+    },
+    "ext": {
+      "$ref": "#/$defs/Ext",
+      "description": "Ecosystem-defined extension members per SPEC.md §4.5.1."
+    }
+  },
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Keys — Sign JWS — response payload",
+      "description": "The success response to a keys/sign-jws request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/keys/sign-jws/0.1#response. Failures use trust-task-error, not this shape.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "keyId",
+        "alg",
+        "jws"
+      ],
+      "properties": {
+        "keyId": {
+          "type": "string",
+          "description": "The key that produced the signature. Echoed so a response separated from its request is still attributable."
+        },
+        "alg": {
+          "type": "string",
+          "enum": [
+            "EdDSA",
+            "ES256",
+            "ES256K",
+            "ML-DSA-44",
+            "ML-DSA-65"
+          ],
+          "description": "The JOSE algorithm the custodian chose from the key's type and wrote into the header: `EdDSA` for `ed25519`, `ES256` for `p256`, `ES256K` for a secp256k1 key, `ML-DSA-44` and `ML-DSA-65` for `mldsa44` and `mldsa65`. Externally owned, carried verbatim."
+        },
+        "jws": {
+          "type": "string",
+          "pattern": "^[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+$",
+          "description": "The JWS in compact serialisation: BASE64URL(header) '.' BASE64URL(payload) '.' BASE64URL(signature), unpadded. For ECDSA the signature is the fixed-width `r || s` of RFC 7518 §3.4, not DER."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "Keys — Sign JWS — response payload",
+      "description": "The success response to a keys/sign-jws request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/keys/sign-jws/0.1#response. Failures use trust-task-error, not this shape.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "keyId",
+        "alg",
+        "jws"
+      ],
+      "properties": {
+        "keyId": {
+          "type": "string",
+          "description": "The key that produced the signature. Echoed so a response separated from its request is still attributable."
+        },
+        "alg": {
+          "type": "string",
+          "enum": [
+            "EdDSA",
+            "ES256",
+            "ES256K",
+            "ML-DSA-44",
+            "ML-DSA-65"
+          ],
+          "description": "The JOSE algorithm the custodian chose from the key's type and wrote into the header: `EdDSA` for `ed25519`, `ES256` for `p256`, `ES256K` for a secp256k1 key, `ML-DSA-44` and `ML-DSA-65` for `mldsa44` and `mldsa65`. Externally owned, carried verbatim."
+        },
+        "jws": {
+          "type": "string",
+          "pattern": "^[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+$",
+          "description": "The JWS in compact serialisation: BASE64URL(header) '.' BASE64URL(payload) '.' BASE64URL(signature), unpadded. For ECDSA the signature is the fixed-width `r || s` of RFC 7518 §3.4, not DER."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the request variant, from this specification's
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
+ */
+export const SPEC = {
+  typeUri: TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: PAYLOAD_SCHEMA,
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export const RESPONSE_SPEC = {
+  typeUri: RESPONSE_TYPE_URI,
+  isBearer: false,
+  isProofRequired: false,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+} as const;

package/src/rooms/_shared/0.1/blobs.ts

@@ -14,4 +14,4 @@ export interface RoomsSharedFileAndBlobTypes {
  * The definitions this shared schema publishes, hoisted to one declaration each.
  * See "../../../_shared/components.js".
  */
-export type { BlobManifest, BlobRef, RoomLimits, ScopeLimits, TransferId, Usage } from "../../../_shared/components.js";
+export type { BlobManifest, BlobRef, FileManifest, RoomLimits, ScopeLimits, TransferId, Usage } from "../../../_shared/components.js";

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

@@ -0,0 +1,279 @@
+/**
+ * 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 const TYPE_URI = "https://trusttasks.org/spec/vtc/join-requests/wallet-session/start/0.1" as const;
+
+/** Stable alias for this specification's request payload shape. */
+export type Payload = VTCJoinRequestsWalletSessionStartPayload;
+
+/** 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" as const;
+
+/** 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 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 const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "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 const;
+
+/**
+ * SPEC.md §7.2 policy for the request variant, from this specification's
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
+ */
+export const SPEC = {
+  typeUri: TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: PAYLOAD_SCHEMA,
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export const RESPONSE_SPEC = {
+  typeUri: RESPONSE_TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  isIssuedAtRequired: true,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+} as const;