@openvtc/trust-tasks 0.26.18 → 0.26.19

package/dist/vtc/directory/card/public/0.1/payload.d.ts

@@ -0,0 +1,348 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/vtc/directory/card/public/0.1/payload.schema.json
+ */
+import type { DigestMultibase, EntryId, Ext, PublishedCard } from "../../../../../_shared/components.js";
+/**
+ * Read a member's external card, as they signed it. Anyone may ask; the request carries nothing about the reader. The outer document members are owned by the framework — SPEC §6.3.
+ */
+export interface VTCDirectoryCardPublicPayload {
+    entryId: EntryId;
+    /**
+     * The card the reader expects, from a registry pointer. Where the card served now is another, the answer is `notFound`.
+     */
+    cardDigest?: DigestMultibase;
+    ext?: Ext;
+}
+/**
+ * The success response to a vtc/directory/card/public/0.1 request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/vtc/directory/card/public/0.1#response.
+ */
+export interface VTCDirectoryCardPublicResponsePayload {
+    /**
+     * Exactly as the member signed it.
+     */
+    card: PublishedCard;
+    cardDigest: DigestMultibase;
+    publishedAt: string;
+    ext?: Ext;
+}
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { DigestMultibase, EntryId, Ext, PublishedCard };
+/** Trust Task type URI. */
+export declare const TYPE_URI: "https://trusttasks.org/spec/vtc/directory/card/public/0.1";
+/** Stable alias for this specification's request payload shape. */
+export type Payload = VTCDirectoryCardPublicPayload;
+/** Trust Task response type URI (request type URI + "#response"). */
+export declare const RESPONSE_TYPE_URI: "https://trusttasks.org/spec/vtc/directory/card/public/0.1#response";
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = VTCDirectoryCardPublicResponsePayload;
+/**
+ * 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/directory/card/public/0.1";
+    readonly title: "VTC Directory — Card — Public — payload";
+    readonly description: "Read a member's external card, as they signed it. Anyone may ask; the request carries nothing about the reader. The outer document members are owned by the framework — SPEC §6.3.";
+    readonly type: "object";
+    readonly additionalProperties: false;
+    readonly required: readonly ["entryId"];
+    readonly properties: {
+        readonly entryId: {
+            readonly $ref: "#/$defs/EntryId";
+        };
+        readonly cardDigest: {
+            readonly $ref: "#/$defs/DigestMultibase";
+            readonly description: "The card the reader expects, from a registry pointer. Where the card served now is another, the answer is `notFound`.";
+        };
+        readonly ext: {
+            readonly $ref: "#/$defs/Ext";
+        };
+    };
+    readonly $defs: {
+        readonly Response: {
+            readonly $anchor: "response";
+            readonly title: "VTC Directory — Card — Public — response payload";
+            readonly description: "The success response to a vtc/directory/card/public/0.1 request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/vtc/directory/card/public/0.1#response.";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["card", "cardDigest", "publishedAt"];
+            readonly properties: {
+                readonly card: {
+                    readonly $ref: "#/$defs/PublishedCard";
+                    readonly description: "Exactly as the member signed it.";
+                };
+                readonly cardDigest: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                };
+                readonly publishedAt: {
+                    readonly type: "string";
+                    readonly format: "date-time";
+                };
+                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"];
+        };
+        readonly PublishedCard: {
+            readonly title: "PublishedCard";
+            readonly description: "A member's external card: a JSContact `Card` (RFC 9553) holding exactly their values whose visibility is `public`, mapped as `JSContactCard` maps them, with the member's W3C Data Integrity `proof`. The community serves it as received and never signs, composes or edits it (VTI-REG-004 item 4).\n\nCarried as an open object, and deliberately so: the proof covers every member of the card, and a typed binding that kept only the members named here would drop the rest and break the signature. So this schema constrains none of its members, and a consumer MUST check them itself: `@type`, `version`, `uid` and `proof` are present; `@type` is `Card`; `version` is `1.0`; `uid` is `urn:vtc-directory:<EntryId>`; `proof` is a `DataIntegrityProof` with `cryptosuite` `eddsa-jcs-2022` or `ecdsa-jcs-2019`, `proofPurpose` `assertionMethod`, and a `verificationMethod` of the member's membership DID authorized for `assertionMethod`; and the proof verifies over the card without it, before any member is relied on.";
+            readonly type: "object";
+            readonly additionalProperties: true;
+        };
+        readonly EntryId: {
+            readonly title: "EntryId";
+            readonly description: "Opaque identifier of one directory entry: `dir_` followed by 16 to 64 base64url characters. Random, scoped to one community, and stable for the life of the membership — it survives a rotation of the member's DID, which is why groups, notes and cards are keyed by it. It MUST NOT be derived from, and MUST NOT reveal, any DID of the member, and the same person's entries in two communities MUST NOT share one. Compared by exact string equality.";
+            readonly type: "string";
+            readonly pattern: "^dir_[A-Za-z0-9_-]{16,64}$";
+        };
+    };
+};
+/** 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 Directory — Card — Public — response payload";
+            readonly description: "The success response to a vtc/directory/card/public/0.1 request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/vtc/directory/card/public/0.1#response.";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["card", "cardDigest", "publishedAt"];
+            readonly properties: {
+                readonly card: {
+                    readonly $ref: "#/$defs/PublishedCard";
+                    readonly description: "Exactly as the member signed it.";
+                };
+                readonly cardDigest: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                };
+                readonly publishedAt: {
+                    readonly type: "string";
+                    readonly format: "date-time";
+                };
+                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"];
+        };
+        readonly PublishedCard: {
+            readonly title: "PublishedCard";
+            readonly description: "A member's external card: a JSContact `Card` (RFC 9553) holding exactly their values whose visibility is `public`, mapped as `JSContactCard` maps them, with the member's W3C Data Integrity `proof`. The community serves it as received and never signs, composes or edits it (VTI-REG-004 item 4).\n\nCarried as an open object, and deliberately so: the proof covers every member of the card, and a typed binding that kept only the members named here would drop the rest and break the signature. So this schema constrains none of its members, and a consumer MUST check them itself: `@type`, `version`, `uid` and `proof` are present; `@type` is `Card`; `version` is `1.0`; `uid` is `urn:vtc-directory:<EntryId>`; `proof` is a `DataIntegrityProof` with `cryptosuite` `eddsa-jcs-2022` or `ecdsa-jcs-2019`, `proofPurpose` `assertionMethod`, and a `verificationMethod` of the member's membership DID authorized for `assertionMethod`; and the proof verifies over the card without it, before any member is relied on.";
+            readonly type: "object";
+            readonly additionalProperties: true;
+        };
+        readonly EntryId: {
+            readonly title: "EntryId";
+            readonly description: "Opaque identifier of one directory entry: `dir_` followed by 16 to 64 base64url characters. Random, scoped to one community, and stable for the life of the membership — it survives a rotation of the member's DID, which is why groups, notes and cards are keyed by it. It MUST NOT be derived from, and MUST NOT reveal, any DID of the member, and the same person's entries in two communities MUST NOT share one. Compared by exact string equality.";
+            readonly type: "string";
+            readonly pattern: "^dir_[A-Za-z0-9_-]{16,64}$";
+        };
+    };
+};
+/**
+ * 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/directory/card/public/0.1";
+    readonly isBearer: false;
+    readonly isProofRequired: false;
+    readonly isRecipientRequired: true;
+    readonly isIssuedAtRequired: false;
+    readonly payloadSchema: {
+        readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+        readonly $id: "https://trusttasks.org/spec/vtc/directory/card/public/0.1";
+        readonly title: "VTC Directory — Card — Public — payload";
+        readonly description: "Read a member's external card, as they signed it. Anyone may ask; the request carries nothing about the reader. The outer document members are owned by the framework — SPEC §6.3.";
+        readonly type: "object";
+        readonly additionalProperties: false;
+        readonly required: readonly ["entryId"];
+        readonly properties: {
+            readonly entryId: {
+                readonly $ref: "#/$defs/EntryId";
+            };
+            readonly cardDigest: {
+                readonly $ref: "#/$defs/DigestMultibase";
+                readonly description: "The card the reader expects, from a registry pointer. Where the card served now is another, the answer is `notFound`.";
+            };
+            readonly ext: {
+                readonly $ref: "#/$defs/Ext";
+            };
+        };
+        readonly $defs: {
+            readonly Response: {
+                readonly $anchor: "response";
+                readonly title: "VTC Directory — Card — Public — response payload";
+                readonly description: "The success response to a vtc/directory/card/public/0.1 request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/vtc/directory/card/public/0.1#response.";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["card", "cardDigest", "publishedAt"];
+                readonly properties: {
+                    readonly card: {
+                        readonly $ref: "#/$defs/PublishedCard";
+                        readonly description: "Exactly as the member signed it.";
+                    };
+                    readonly cardDigest: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                    };
+                    readonly publishedAt: {
+                        readonly type: "string";
+                        readonly format: "date-time";
+                    };
+                    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"];
+            };
+            readonly PublishedCard: {
+                readonly title: "PublishedCard";
+                readonly description: "A member's external card: a JSContact `Card` (RFC 9553) holding exactly their values whose visibility is `public`, mapped as `JSContactCard` maps them, with the member's W3C Data Integrity `proof`. The community serves it as received and never signs, composes or edits it (VTI-REG-004 item 4).\n\nCarried as an open object, and deliberately so: the proof covers every member of the card, and a typed binding that kept only the members named here would drop the rest and break the signature. So this schema constrains none of its members, and a consumer MUST check them itself: `@type`, `version`, `uid` and `proof` are present; `@type` is `Card`; `version` is `1.0`; `uid` is `urn:vtc-directory:<EntryId>`; `proof` is a `DataIntegrityProof` with `cryptosuite` `eddsa-jcs-2022` or `ecdsa-jcs-2019`, `proofPurpose` `assertionMethod`, and a `verificationMethod` of the member's membership DID authorized for `assertionMethod`; and the proof verifies over the card without it, before any member is relied on.";
+                readonly type: "object";
+                readonly additionalProperties: true;
+            };
+            readonly EntryId: {
+                readonly title: "EntryId";
+                readonly description: "Opaque identifier of one directory entry: `dir_` followed by 16 to 64 base64url characters. Random, scoped to one community, and stable for the life of the membership — it survives a rotation of the member's DID, which is why groups, notes and cards are keyed by it. It MUST NOT be derived from, and MUST NOT reveal, any DID of the member, and the same person's entries in two communities MUST NOT share one. Compared by exact string equality.";
+                readonly type: "string";
+                readonly pattern: "^dir_[A-Za-z0-9_-]{16,64}$";
+            };
+        };
+    };
+};
+/**
+ * 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/directory/card/public/0.1#response";
+    readonly isBearer: false;
+    readonly isProofRequired: false;
+    readonly isRecipientRequired: true;
+    readonly isIssuedAtRequired: false;
+    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 Directory — Card — Public — response payload";
+                readonly description: "The success response to a vtc/directory/card/public/0.1 request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/vtc/directory/card/public/0.1#response.";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["card", "cardDigest", "publishedAt"];
+                readonly properties: {
+                    readonly card: {
+                        readonly $ref: "#/$defs/PublishedCard";
+                        readonly description: "Exactly as the member signed it.";
+                    };
+                    readonly cardDigest: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                    };
+                    readonly publishedAt: {
+                        readonly type: "string";
+                        readonly format: "date-time";
+                    };
+                    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"];
+            };
+            readonly PublishedCard: {
+                readonly title: "PublishedCard";
+                readonly description: "A member's external card: a JSContact `Card` (RFC 9553) holding exactly their values whose visibility is `public`, mapped as `JSContactCard` maps them, with the member's W3C Data Integrity `proof`. The community serves it as received and never signs, composes or edits it (VTI-REG-004 item 4).\n\nCarried as an open object, and deliberately so: the proof covers every member of the card, and a typed binding that kept only the members named here would drop the rest and break the signature. So this schema constrains none of its members, and a consumer MUST check them itself: `@type`, `version`, `uid` and `proof` are present; `@type` is `Card`; `version` is `1.0`; `uid` is `urn:vtc-directory:<EntryId>`; `proof` is a `DataIntegrityProof` with `cryptosuite` `eddsa-jcs-2022` or `ecdsa-jcs-2019`, `proofPurpose` `assertionMethod`, and a `verificationMethod` of the member's membership DID authorized for `assertionMethod`; and the proof verifies over the card without it, before any member is relied on.";
+                readonly type: "object";
+                readonly additionalProperties: true;
+            };
+            readonly EntryId: {
+                readonly title: "EntryId";
+                readonly description: "Opaque identifier of one directory entry: `dir_` followed by 16 to 64 base64url characters. Random, scoped to one community, and stable for the life of the membership — it survives a rotation of the member's DID, which is why groups, notes and cards are keyed by it. It MUST NOT be derived from, and MUST NOT reveal, any DID of the member, and the same person's entries in two communities MUST NOT share one. Compared by exact string equality.";
+                readonly type: "string";
+                readonly pattern: "^dir_[A-Za-z0-9_-]{16,64}$";
+            };
+        };
+    };
+};
+//# sourceMappingURL=payload.d.ts.map

package/dist/vtc/directory/card/public/0.1/payload.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../../src/vtc/directory/card/public/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,OAAO,KAAK,EAAE,eAAe,EAAE,OAAO,EAAE,GAAG,EAAE,aAAa,EAAE,MAAM,sCAAsC,CAAC;AAGzG;;GAEG;AACH,MAAM,WAAW,6BAA6B;IAC5C,OAAO,EAAE,OAAO,CAAC;IACjB;;OAEG;IACH,UAAU,CAAC,EAAE,eAAe,CAAC;IAC7B,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,qCAAqC;IACpD;;OAEG;IACH,IAAI,EAAE,aAAa,CAAC;IACpB,UAAU,EAAE,eAAe,CAAC;IAC5B,WAAW,EAAE,MAAM,CAAC;IACpB,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AAED,kHAAkH;AAClH,YAAY,EAAE,eAAe,EAAE,OAAO,EAAE,GAAG,EAAE,aAAa,EAAE,CAAC;AAE7D,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,2DAAoE,CAAC;AAE7F,mEAAmE;AACnE,MAAM,MAAM,OAAO,GAAG,6BAA6B,CAAC;AAEpD,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,oEAA6E,CAAC;AAE/G,4EAA4E;AAC5E,MAAM,MAAM,QAAQ,GAAG,qCAAqC,CAAC;AAE7D;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAoFjB,CAAC;AAEX,mEAAmE;AACnE,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiE1B,CAAC;AAEX;;;;;GAKG;AACH,eAAO,MAAM,IAAI;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAOP,CAAC;AAEX;;;;GAIG;AACH,eAAO,MAAM,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAOhB,CAAC"}

package/dist/vtc/directory/card/public/0.1/payload.js

@@ -0,0 +1,197 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/vtc/directory/card/public/0.1/payload.schema.json
+ */
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/vtc/directory/card/public/0.1";
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/vtc/directory/card/public/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/directory/card/public/0.1",
+    "title": "VTC Directory — Card — Public — payload",
+    "description": "Read a member's external card, as they signed it. Anyone may ask; the request carries nothing about the reader. The outer document members are owned by the framework — SPEC §6.3.",
+    "type": "object",
+    "additionalProperties": false,
+    "required": [
+        "entryId"
+    ],
+    "properties": {
+        "entryId": {
+            "$ref": "#/$defs/EntryId"
+        },
+        "cardDigest": {
+            "$ref": "#/$defs/DigestMultibase",
+            "description": "The card the reader expects, from a registry pointer. Where the card served now is another, the answer is `notFound`."
+        },
+        "ext": {
+            "$ref": "#/$defs/Ext"
+        }
+    },
+    "$defs": {
+        "Response": {
+            "$anchor": "response",
+            "title": "VTC Directory — Card — Public — response payload",
+            "description": "The success response to a vtc/directory/card/public/0.1 request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/vtc/directory/card/public/0.1#response.",
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "card",
+                "cardDigest",
+                "publishedAt"
+            ],
+            "properties": {
+                "card": {
+                    "$ref": "#/$defs/PublishedCard",
+                    "description": "Exactly as the member signed it."
+                },
+                "cardDigest": {
+                    "$ref": "#/$defs/DigestMultibase"
+                },
+                "publishedAt": {
+                    "type": "string",
+                    "format": "date-time"
+                },
+                "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"
+            ]
+        },
+        "PublishedCard": {
+            "title": "PublishedCard",
+            "description": "A member's external card: a JSContact `Card` (RFC 9553) holding exactly their values whose visibility is `public`, mapped as `JSContactCard` maps them, with the member's W3C Data Integrity `proof`. The community serves it as received and never signs, composes or edits it (VTI-REG-004 item 4).\n\nCarried as an open object, and deliberately so: the proof covers every member of the card, and a typed binding that kept only the members named here would drop the rest and break the signature. So this schema constrains none of its members, and a consumer MUST check them itself: `@type`, `version`, `uid` and `proof` are present; `@type` is `Card`; `version` is `1.0`; `uid` is `urn:vtc-directory:<EntryId>`; `proof` is a `DataIntegrityProof` with `cryptosuite` `eddsa-jcs-2022` or `ecdsa-jcs-2019`, `proofPurpose` `assertionMethod`, and a `verificationMethod` of the member's membership DID authorized for `assertionMethod`; and the proof verifies over the card without it, before any member is relied on.",
+            "type": "object",
+            "additionalProperties": true
+        },
+        "EntryId": {
+            "title": "EntryId",
+            "description": "Opaque identifier of one directory entry: `dir_` followed by 16 to 64 base64url characters. Random, scoped to one community, and stable for the life of the membership — it survives a rotation of the member's DID, which is why groups, notes and cards are keyed by it. It MUST NOT be derived from, and MUST NOT reveal, any DID of the member, and the same person's entries in two communities MUST NOT share one. Compared by exact string equality.",
+            "type": "string",
+            "pattern": "^dir_[A-Za-z0-9_-]{16,64}$"
+        }
+    }
+};
+/** 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 Directory — Card — Public — response payload",
+            "description": "The success response to a vtc/directory/card/public/0.1 request. Carried in a Trust Task document whose type is https://trusttasks.org/spec/vtc/directory/card/public/0.1#response.",
+            "type": "object",
+            "additionalProperties": false,
+            "required": [
+                "card",
+                "cardDigest",
+                "publishedAt"
+            ],
+            "properties": {
+                "card": {
+                    "$ref": "#/$defs/PublishedCard",
+                    "description": "Exactly as the member signed it."
+                },
+                "cardDigest": {
+                    "$ref": "#/$defs/DigestMultibase"
+                },
+                "publishedAt": {
+                    "type": "string",
+                    "format": "date-time"
+                },
+                "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"
+            ]
+        },
+        "PublishedCard": {
+            "title": "PublishedCard",
+            "description": "A member's external card: a JSContact `Card` (RFC 9553) holding exactly their values whose visibility is `public`, mapped as `JSContactCard` maps them, with the member's W3C Data Integrity `proof`. The community serves it as received and never signs, composes or edits it (VTI-REG-004 item 4).\n\nCarried as an open object, and deliberately so: the proof covers every member of the card, and a typed binding that kept only the members named here would drop the rest and break the signature. So this schema constrains none of its members, and a consumer MUST check them itself: `@type`, `version`, `uid` and `proof` are present; `@type` is `Card`; `version` is `1.0`; `uid` is `urn:vtc-directory:<EntryId>`; `proof` is a `DataIntegrityProof` with `cryptosuite` `eddsa-jcs-2022` or `ecdsa-jcs-2019`, `proofPurpose` `assertionMethod`, and a `verificationMethod` of the member's membership DID authorized for `assertionMethod`; and the proof verifies over the card without it, before any member is relied on.",
+            "type": "object",
+            "additionalProperties": true
+        },
+        "EntryId": {
+            "title": "EntryId",
+            "description": "Opaque identifier of one directory entry: `dir_` followed by 16 to 64 base64url characters. Random, scoped to one community, and stable for the life of the membership — it survives a rotation of the member's DID, which is why groups, notes and cards are keyed by it. It MUST NOT be derived from, and MUST NOT reveal, any DID of the member, and the same person's entries in two communities MUST NOT share one. Compared by exact string equality.",
+            "type": "string",
+            "pattern": "^dir_[A-Za-z0-9_-]{16,64}$"
+        }
+    }
+};
+/**
+ * SPEC.md §7.2 policy for the request variant, from this specification's
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
+ */
+export const SPEC = {
+    typeUri: TYPE_URI,
+    isBearer: false,
+    isProofRequired: false,
+    isRecipientRequired: true,
+    isIssuedAtRequired: false,
+    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: false,
+    isRecipientRequired: true,
+    isIssuedAtRequired: false,
+    payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+};
+//# sourceMappingURL=payload.js.map

package/dist/vtc/directory/card/public/0.1/payload.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../../src/vtc/directory/card/public/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAgCH,2BAA2B;AAC3B,MAAM,CAAC,MAAM,QAAQ,GAAG,2DAAoE,CAAC;AAK7F,qEAAqE;AACrE,MAAM,CAAC,MAAM,iBAAiB,GAAG,oEAA6E,CAAC;AAK/G;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,cAAc,GAAG;IAC5B,SAAS,EAAE,8CAA8C;IACzD,KAAK,EAAE,2DAA2D;IAClE,OAAO,EAAE,yCAAyC;IAClD,aAAa,EAAE,oLAAoL;IACnM,MAAM,EAAE,QAAQ;IAChB,sBAAsB,EAAE,KAAK;IAC7B,UAAU,EAAE;QACV,SAAS;KACV;IACD,YAAY,EAAE;QACZ,SAAS,EAAE;YACT,MAAM,EAAE,iBAAiB;SAC1B;QACD,YAAY,EAAE;YACZ,MAAM,EAAE,yBAAyB;YACjC,aAAa,EAAE,uHAAuH;SACvI;QACD,KAAK,EAAE;YACL,MAAM,EAAE,aAAa;SACtB;KACF;IACD,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,kDAAkD;YAC3D,aAAa,EAAE,qLAAqL;YACpM,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,MAAM;gBACN,YAAY;gBACZ,aAAa;aACd;YACD,YAAY,EAAE;gBACZ,MAAM,EAAE;oBACN,MAAM,EAAE,uBAAuB;oBAC/B,aAAa,EAAE,kCAAkC;iBAClD;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,yBAAyB;iBAClC;gBACD,aAAa,EAAE;oBACb,MAAM,EAAE,QAAQ;oBAChB,QAAQ,EAAE,WAAW;iBACtB;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;QACD,iBAAiB,EAAE;YACjB,OAAO,EAAE,iBAAiB;YAC1B,aAAa,EAAE,gnDAAgnD;YAC/nD,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,EAAE;YACf,SAAS,EAAE,4CAA4C;YACvD,UAAU,EAAE;gBACV,iDAAiD;aAClD;SACF;QACD,eAAe,EAAE;YACf,OAAO,EAAE,eAAe;YACxB,aAAa,EAAE,8+BAA8+B;YAC7/B,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,IAAI;SAC7B;QACD,SAAS,EAAE;YACT,OAAO,EAAE,SAAS;YAClB,aAAa,EAAE,6bAA6b;YAC5c,MAAM,EAAE,QAAQ;YAChB,SAAS,EAAE,4BAA4B;SACxC;KACF;CACO,CAAC;AAEX,mEAAmE;AACnE,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACrC,SAAS,EAAE,8CAA8C;IACzD,MAAM,EAAE,kBAAkB;IAC1B,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,kDAAkD;YAC3D,aAAa,EAAE,qLAAqL;YACpM,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,MAAM;gBACN,YAAY;gBACZ,aAAa;aACd;YACD,YAAY,EAAE;gBACZ,MAAM,EAAE;oBACN,MAAM,EAAE,uBAAuB;oBAC/B,aAAa,EAAE,kCAAkC;iBAClD;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,yBAAyB;iBAClC;gBACD,aAAa,EAAE;oBACb,MAAM,EAAE,QAAQ;oBAChB,QAAQ,EAAE,WAAW;iBACtB;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;QACD,iBAAiB,EAAE;YACjB,OAAO,EAAE,iBAAiB;YAC1B,aAAa,EAAE,gnDAAgnD;YAC/nD,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,EAAE;YACf,SAAS,EAAE,4CAA4C;YACvD,UAAU,EAAE;gBACV,iDAAiD;aAClD;SACF;QACD,eAAe,EAAE;YACf,OAAO,EAAE,eAAe;YACxB,aAAa,EAAE,8+BAA8+B;YAC7/B,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,IAAI;SAC7B;QACD,SAAS,EAAE;YACT,OAAO,EAAE,SAAS;YAClB,aAAa,EAAE,6bAA6b;YAC5c,MAAM,EAAE,QAAQ;YAChB,SAAS,EAAE,4BAA4B;SACxC;KACF;CACO,CAAC;AAEX;;;;;GAKG;AACH,MAAM,CAAC,MAAM,IAAI,GAAG;IAClB,OAAO,EAAE,QAAQ;IACjB,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,KAAK;IACtB,mBAAmB,EAAE,IAAI;IACzB,kBAAkB,EAAE,KAAK;IACzB,aAAa,EAAE,cAAc;CACrB,CAAC;AAEX;;;;GAIG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG;IAC3B,OAAO,EAAE,iBAAiB;IAC1B,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,KAAK;IACtB,mBAAmB,EAAE,IAAI;IACzB,kBAAkB,EAAE,KAAK;IACzB,aAAa,EAAE,uBAAuB;CAC9B,CAAC"}