@openvtc/trust-tasks 0.12.6 → 0.12.7

package/dist/vtc/relationships/publish/0.1/payload.d.ts

@@ -2,11 +2,37 @@
  * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
  * Source: specs/vtc/relationships/publish/0.1/payload.schema.json
  */
+/**
+ * Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another.
+ */
+export type DigestMultibase = string;
 export interface VTCRelationshipsPublishPayload {
     /**
      * A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof.
      */
     vrc: {};
+    /**
+     * Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.
+     *
+     * A member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.
+     *
+     * Omit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.
+     */
+    pop?: {
+        /**
+         * Guards against a signature the issuer made over some other object being replayed here as authorization to publish.
+         */
+        type: "VrcPublishAuthorization";
+        /**
+         * The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session.
+         */
+        documentId: string;
+        vrcDigestMultibase: DigestMultibase;
+        /**
+         * Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes.
+         */
+        proof: {};
+    };
     ext?: Ext;
 }
 /**
@@ -57,6 +83,30 @@ export declare const PAYLOAD_SCHEMA: {
             readonly type: "object";
             readonly description: "A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof.";
         };
+        readonly pop: {
+            readonly type: "object";
+            readonly description: "Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.\n\nA member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.\n\nOmit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.";
+            readonly properties: {
+                readonly type: {
+                    readonly const: "VrcPublishAuthorization";
+                    readonly description: "Guards against a signature the issuer made over some other object being replayed here as authorization to publish.";
+                };
+                readonly documentId: {
+                    readonly type: "string";
+                    readonly description: "The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session.";
+                };
+                readonly vrcDigestMultibase: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                    readonly description: "Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another.";
+                };
+                readonly proof: {
+                    readonly type: "object";
+                    readonly description: "Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes.";
+                };
+            };
+            readonly required: readonly ["type", "documentId", "vrcDigestMultibase", "proof"];
+            readonly additionalProperties: false;
+        };
         readonly ext: {
             readonly $ref: "#/$defs/Ext";
         };
@@ -102,6 +152,14 @@ export declare const PAYLOAD_SCHEMA: {
                 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. */
@@ -149,6 +207,14 @@ export declare const RESPONSE_PAYLOAD_SCHEMA: {
                 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"];
+        };
     };
 };
 /**
@@ -174,6 +240,30 @@ export declare const SPEC: {
                 readonly type: "object";
                 readonly description: "A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof.";
             };
+            readonly pop: {
+                readonly type: "object";
+                readonly description: "Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.\n\nA member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.\n\nOmit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.";
+                readonly properties: {
+                    readonly type: {
+                        readonly const: "VrcPublishAuthorization";
+                        readonly description: "Guards against a signature the issuer made over some other object being replayed here as authorization to publish.";
+                    };
+                    readonly documentId: {
+                        readonly type: "string";
+                        readonly description: "The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session.";
+                    };
+                    readonly vrcDigestMultibase: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                        readonly description: "Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another.";
+                    };
+                    readonly proof: {
+                        readonly type: "object";
+                        readonly description: "Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes.";
+                    };
+                };
+                readonly required: readonly ["type", "documentId", "vrcDigestMultibase", "proof"];
+                readonly additionalProperties: false;
+            };
             readonly ext: {
                 readonly $ref: "#/$defs/Ext";
             };
@@ -219,6 +309,14 @@ export declare const SPEC: {
                     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"];
+            };
         };
     };
 };
@@ -276,6 +374,14 @@ export declare const RESPONSE_SPEC: {
                     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"];
+            };
         };
     };
 };

package/dist/vtc/relationships/publish/0.1/payload.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../src/vtc/relationships/publish/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,MAAM,WAAW,8BAA8B;IAC7C;;OAEG;IACH,GAAG,EAAE,EAAE,CAAC;IACR,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,GAAG;IAClB,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC;AACD,MAAM,WAAW,sCAAsC;IACrD;;OAEG;IACH,EAAE,EAAE,MAAM,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;IAClB,UAAU,EAAE,MAAM,CAAC;IACnB;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;IAClB,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AAED,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,2DAAoE,CAAC;AAE7F,mEAAmE;AACnE,MAAM,MAAM,OAAO,GAAG,8BAA8B,CAAC;AAErD,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,oEAA6E,CAAC;AAE/G,4EAA4E;AAC5E,MAAM,MAAM,QAAQ,GAAG,sCAAsC,CAAC;AAE9D;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiEjB,CAAC;AAEX,mEAAmE;AACnE,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAkD1B,CAAC;AAEX;;;;;GAKG;AACH,eAAO,MAAM,IAAI;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMP,CAAC;AAEX;;;;GAIG;AACH,eAAO,MAAM,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMhB,CAAC"}
+{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../src/vtc/relationships/publish/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,MAAM,eAAe,GAAG,MAAM,CAAC;AAErC,MAAM,WAAW,8BAA8B;IAC7C;;OAEG;IACH,GAAG,EAAE,EAAE,CAAC;IACR;;;;;;OAMG;IACH,GAAG,CAAC,EAAE;QACJ;;WAEG;QACH,IAAI,EAAE,yBAAyB,CAAC;QAChC;;WAEG;QACH,UAAU,EAAE,MAAM,CAAC;QACnB,kBAAkB,EAAE,eAAe,CAAC;QACpC;;WAEG;QACH,KAAK,EAAE,EAAE,CAAC;KACX,CAAC;IACF,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,GAAG;IAClB,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC;AACD,MAAM,WAAW,sCAAsC;IACrD;;OAEG;IACH,EAAE,EAAE,MAAM,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;IAClB,UAAU,EAAE,MAAM,CAAC;IACnB;;OAEG;IACH,SAAS,EAAE,MAAM,CAAC;IAClB,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AAED,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,2DAAoE,CAAC;AAE7F,mEAAmE;AACnE,MAAM,MAAM,OAAO,GAAG,8BAA8B,CAAC;AAErD,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,oEAA6E,CAAC;AAE/G,4EAA4E;AAC5E,MAAM,MAAM,QAAQ,GAAG,sCAAsC,CAAC;AAE9D;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwGjB,CAAC;AAEX,mEAAmE;AACnE,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4D1B,CAAC;AAEX;;;;;GAKG;AACH,eAAO,MAAM,IAAI;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMP,CAAC;AAEX;;;;GAIG;AACH,eAAO,MAAM,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMhB,CAAC"}

package/dist/vtc/relationships/publish/0.1/payload.js

@@ -29,6 +29,35 @@ export const PAYLOAD_SCHEMA = {
             "type": "object",
             "description": "A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof."
         },
+        "pop": {
+            "type": "object",
+            "description": "Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.\n\nA member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.\n\nOmit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.",
+            "properties": {
+                "type": {
+                    "const": "VrcPublishAuthorization",
+                    "description": "Guards against a signature the issuer made over some other object being replayed here as authorization to publish."
+                },
+                "documentId": {
+                    "type": "string",
+                    "description": "The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session."
+                },
+                "vrcDigestMultibase": {
+                    "$ref": "#/$defs/DigestMultibase",
+                    "description": "Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another."
+                },
+                "proof": {
+                    "type": "object",
+                    "description": "Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes."
+                }
+            },
+            "required": [
+                "type",
+                "documentId",
+                "vrcDigestMultibase",
+                "proof"
+            ],
+            "additionalProperties": false
+        },
         "ext": {
             "$ref": "#/$defs/Ext"
         }
@@ -78,6 +107,16 @@ export const PAYLOAD_SCHEMA = {
             "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"
+            ]
         }
     }
 };
@@ -130,6 +169,16 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
             "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"
+            ]
         }
     }
 };

package/dist/vtc/relationships/publish/0.1/payload.js.map

@@ -1 +1 @@
-{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../src/vtc/relationships/publish/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AA6BH,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,qCAAqC;IAC9C,MAAM,EAAE,QAAQ;IAChB,sBAAsB,EAAE,KAAK;IAC7B,UAAU,EAAE;QACV,KAAK;KACN;IACD,YAAY,EAAE;QACZ,KAAK,EAAE;YACL,MAAM,EAAE,QAAQ;YAChB,aAAa,EAAE,uMAAuM;SACvN;QACD,KAAK,EAAE;YACL,MAAM,EAAE,aAAa;SACtB;KACF;IACD,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,8CAA8C;YACvD,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,IAAI;gBACJ,WAAW;gBACX,YAAY;gBACZ,WAAW;aACZ;YACD,YAAY,EAAE;gBACZ,IAAI,EAAE;oBACJ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,kDAAkD;iBAClE;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,SAAS,EAAE,gBAAgB;oBAC3B,aAAa,EAAE,8DAA8D;iBAC9E;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;KACF;CACO,CAAC;AAEX,mEAAmE;AACnE,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACrC,SAAS,EAAE,8CAA8C;IACzD,MAAM,EAAE,kBAAkB;IAC1B,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,8CAA8C;YACvD,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,IAAI;gBACJ,WAAW;gBACX,YAAY;gBACZ,WAAW;aACZ;YACD,YAAY,EAAE;gBACZ,IAAI,EAAE;oBACJ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,kDAAkD;iBAClE;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,SAAS,EAAE,gBAAgB;oBAC3B,aAAa,EAAE,8DAA8D;iBAC9E;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;KACF;CACO,CAAC;AAEX;;;;;GAKG;AACH,MAAM,CAAC,MAAM,IAAI,GAAG;IAClB,OAAO,EAAE,QAAQ;IACjB,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,IAAI;IACzB,aAAa,EAAE,cAAc;CACrB,CAAC;AAEX;;;;GAIG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG;IAC3B,OAAO,EAAE,iBAAiB;IAC1B,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,IAAI;IACzB,aAAa,EAAE,uBAAuB;CAC9B,CAAC"}
+{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../src/vtc/relationships/publish/0.1/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAwDH,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,qCAAqC;IAC9C,MAAM,EAAE,QAAQ;IAChB,sBAAsB,EAAE,KAAK;IAC7B,UAAU,EAAE;QACV,KAAK;KACN;IACD,YAAY,EAAE;QACZ,KAAK,EAAE;YACL,MAAM,EAAE,QAAQ;YAChB,aAAa,EAAE,uMAAuM;SACvN;QACD,KAAK,EAAE;YACL,MAAM,EAAE,QAAQ;YAChB,aAAa,EAAE,ulBAAulB;YACtmB,YAAY,EAAE;gBACZ,MAAM,EAAE;oBACN,OAAO,EAAE,yBAAyB;oBAClC,aAAa,EAAE,oHAAoH;iBACpI;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,QAAQ;oBAChB,aAAa,EAAE,0TAA0T;iBAC1U;gBACD,oBAAoB,EAAE;oBACpB,MAAM,EAAE,yBAAyB;oBACjC,aAAa,EAAE,oJAAoJ;iBACpK;gBACD,OAAO,EAAE;oBACP,MAAM,EAAE,QAAQ;oBAChB,aAAa,EAAE,gLAAgL;iBAChM;aACF;YACD,UAAU,EAAE;gBACV,MAAM;gBACN,YAAY;gBACZ,oBAAoB;gBACpB,OAAO;aACR;YACD,sBAAsB,EAAE,KAAK;SAC9B;QACD,KAAK,EAAE;YACL,MAAM,EAAE,aAAa;SACtB;KACF;IACD,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,8CAA8C;YACvD,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,IAAI;gBACJ,WAAW;gBACX,YAAY;gBACZ,WAAW;aACZ;YACD,YAAY,EAAE;gBACZ,IAAI,EAAE;oBACJ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,kDAAkD;iBAClE;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,SAAS,EAAE,gBAAgB;oBAC3B,aAAa,EAAE,8DAA8D;iBAC9E;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;QACD,iBAAiB,EAAE;YACjB,OAAO,EAAE,iBAAiB;YAC1B,aAAa,EAAE,gnDAAgnD;YAC/nD,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,EAAE;YACf,SAAS,EAAE,4CAA4C;YACvD,UAAU,EAAE;gBACV,iDAAiD;aAClD;SACF;KACF;CACO,CAAC;AAEX,mEAAmE;AACnE,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACrC,SAAS,EAAE,8CAA8C;IACzD,MAAM,EAAE,kBAAkB;IAC1B,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,8CAA8C;YACvD,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,IAAI;gBACJ,WAAW;gBACX,YAAY;gBACZ,WAAW;aACZ;YACD,YAAY,EAAE;gBACZ,IAAI,EAAE;oBACJ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,kDAAkD;iBAClE;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,SAAS,EAAE,gBAAgB;oBAC3B,aAAa,EAAE,8DAA8D;iBAC9E;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;QACD,iBAAiB,EAAE;YACjB,OAAO,EAAE,iBAAiB;YAC1B,aAAa,EAAE,gnDAAgnD;YAC/nD,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,EAAE;YACf,SAAS,EAAE,4CAA4C;YACvD,UAAU,EAAE;gBACV,iDAAiD;aAClD;SACF;KACF;CACO,CAAC;AAEX;;;;;GAKG;AACH,MAAM,CAAC,MAAM,IAAI,GAAG;IAClB,OAAO,EAAE,QAAQ;IACjB,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,IAAI;IACzB,aAAa,EAAE,cAAc;CACrB,CAAC;AAEX;;;;GAIG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG;IAC3B,OAAO,EAAE,iBAAiB;IAC1B,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,IAAI;IACzB,aAAa,EAAE,uBAAuB;CAC9B,CAAC"}

package/dist/vtc/relationships/publish/0.2/payload.d.ts

@@ -3,14 +3,40 @@
  * Source: specs/vtc/relationships/publish/0.2/payload.schema.json
  */
 /**
- * Digest over the RFC 8785 canonicalization of the stored VRC, for out-of-band integrity checks. The same value vtc/relationships/request reports on issuance and vtc/relationships/list reports per entry, so a member can tie the three together without re-hashing.
+ * Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another.
  */
 export type DigestMultibase = string;
+/**
+ * Digest over the RFC 8785 canonicalization of the stored VRC, for out-of-band integrity checks. The same value vtc/relationships/request reports on issuance and vtc/relationships/list reports per entry, so a member can tie the three together without re-hashing.
+ */
+export type DigestMultibase1 = string;
 export interface VTCRelationshipsPublishPayload {
     /**
      * A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof.
      */
     vrc: {};
+    /**
+     * Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.
+     *
+     * A member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.
+     *
+     * Omit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.
+     */
+    pop?: {
+        /**
+         * Guards against a signature the issuer made over some other object being replayed here as authorization to publish.
+         */
+        type: "VrcPublishAuthorization";
+        /**
+         * The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session.
+         */
+        documentId: string;
+        vrcDigestMultibase: DigestMultibase;
+        /**
+         * Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes.
+         */
+        proof: {};
+    };
     ext?: Ext;
 }
 /**
@@ -26,7 +52,7 @@ export interface VTCRelationshipsPublishResponsePayload {
     id: string;
     issuerDid: string;
     subjectDid: string;
-    vrcDigestMultibase: DigestMultibase;
+    vrcDigestMultibase: DigestMultibase1;
     ext?: Ext;
 }
 /** Trust Task type URI. */
@@ -58,6 +84,30 @@ export declare const PAYLOAD_SCHEMA: {
             readonly type: "object";
             readonly description: "A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof.";
         };
+        readonly pop: {
+            readonly type: "object";
+            readonly description: "Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.\n\nA member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.\n\nOmit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.";
+            readonly properties: {
+                readonly type: {
+                    readonly const: "VrcPublishAuthorization";
+                    readonly description: "Guards against a signature the issuer made over some other object being replayed here as authorization to publish.";
+                };
+                readonly documentId: {
+                    readonly type: "string";
+                    readonly description: "The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session.";
+                };
+                readonly vrcDigestMultibase: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                    readonly description: "Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another.";
+                };
+                readonly proof: {
+                    readonly type: "object";
+                    readonly description: "Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes.";
+                };
+            };
+            readonly required: readonly ["type", "documentId", "vrcDigestMultibase", "proof"];
+            readonly additionalProperties: false;
+        };
         readonly ext: {
             readonly $ref: "#/$defs/Ext";
         };
@@ -189,6 +239,30 @@ export declare const SPEC: {
                 readonly type: "object";
                 readonly description: "A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof.";
             };
+            readonly pop: {
+                readonly type: "object";
+                readonly description: "Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.\n\nA member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.\n\nOmit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.";
+                readonly properties: {
+                    readonly type: {
+                        readonly const: "VrcPublishAuthorization";
+                        readonly description: "Guards against a signature the issuer made over some other object being replayed here as authorization to publish.";
+                    };
+                    readonly documentId: {
+                        readonly type: "string";
+                        readonly description: "The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session.";
+                    };
+                    readonly vrcDigestMultibase: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                        readonly description: "Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another.";
+                    };
+                    readonly proof: {
+                        readonly type: "object";
+                        readonly description: "Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes.";
+                    };
+                };
+                readonly required: readonly ["type", "documentId", "vrcDigestMultibase", "proof"];
+                readonly additionalProperties: false;
+            };
             readonly ext: {
                 readonly $ref: "#/$defs/Ext";
             };

package/dist/vtc/relationships/publish/0.2/payload.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../src/vtc/relationships/publish/0.2/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,MAAM,eAAe,GAAG,MAAM,CAAC;AAErC,MAAM,WAAW,8BAA8B;IAC7C;;OAEG;IACH,GAAG,EAAE,EAAE,CAAC;IACR,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,GAAG;IAClB,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC;AACD,MAAM,WAAW,sCAAsC;IACrD;;OAEG;IACH,EAAE,EAAE,MAAM,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;IAClB,UAAU,EAAE,MAAM,CAAC;IACnB,kBAAkB,EAAE,eAAe,CAAC;IACpC,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AAED,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,2DAAoE,CAAC;AAE7F,mEAAmE;AACnE,MAAM,MAAM,OAAO,GAAG,8BAA8B,CAAC;AAErD,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,oEAA6E,CAAC;AAE/G,4EAA4E;AAC5E,MAAM,MAAM,QAAQ,GAAG,sCAAsC,CAAC;AAE9D;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA0EjB,CAAC;AAEX,mEAAmE;AACnE,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2D1B,CAAC;AAEX;;;;;GAKG;AACH,eAAO,MAAM,IAAI;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMP,CAAC;AAEX;;;;GAIG;AACH,eAAO,MAAM,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMhB,CAAC"}
+{"version":3,"file":"payload.d.ts","sourceRoot":"","sources":["../../../../../src/vtc/relationships/publish/0.2/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH;;GAEG;AACH,MAAM,MAAM,eAAe,GAAG,MAAM,CAAC;AACrC;;GAEG;AACH,MAAM,MAAM,gBAAgB,GAAG,MAAM,CAAC;AAEtC,MAAM,WAAW,8BAA8B;IAC7C;;OAEG;IACH,GAAG,EAAE,EAAE,CAAC;IACR;;;;;;OAMG;IACH,GAAG,CAAC,EAAE;QACJ;;WAEG;QACH,IAAI,EAAE,yBAAyB,CAAC;QAChC;;WAEG;QACH,UAAU,EAAE,MAAM,CAAC;QACnB,kBAAkB,EAAE,eAAe,CAAC;QACpC;;WAEG;QACH,KAAK,EAAE,EAAE,CAAC;KACX,CAAC;IACF,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AACD;;GAEG;AACH,MAAM,WAAW,GAAG;IAClB,CAAC,CAAC,EAAE,MAAM,GAAG,OAAO,GAAG,SAAS,CAAC;CAClC;AACD,MAAM,WAAW,sCAAsC;IACrD;;OAEG;IACH,EAAE,EAAE,MAAM,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;IAClB,UAAU,EAAE,MAAM,CAAC;IACnB,kBAAkB,EAAE,gBAAgB,CAAC;IACrC,GAAG,CAAC,EAAE,GAAG,CAAC;CACX;AAED,2BAA2B;AAC3B,eAAO,MAAM,QAAQ,EAAG,2DAAoE,CAAC;AAE7F,mEAAmE;AACnE,MAAM,MAAM,OAAO,GAAG,8BAA8B,CAAC;AAErD,qEAAqE;AACrE,eAAO,MAAM,iBAAiB,EAAG,oEAA6E,CAAC;AAE/G,4EAA4E;AAC5E,MAAM,MAAM,QAAQ,GAAG,sCAAsC,CAAC;AAE9D;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAuGjB,CAAC;AAEX,mEAAmE;AACnE,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2D1B,CAAC;AAEX;;;;;GAKG;AACH,eAAO,MAAM,IAAI;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMP,CAAC;AAEX;;;;GAIG;AACH,eAAO,MAAM,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMhB,CAAC"}

package/dist/vtc/relationships/publish/0.2/payload.js

@@ -29,6 +29,35 @@ export const PAYLOAD_SCHEMA = {
             "type": "object",
             "description": "A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof."
         },
+        "pop": {
+            "type": "object",
+            "description": "Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.\n\nA member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.\n\nOmit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.",
+            "properties": {
+                "type": {
+                    "const": "VrcPublishAuthorization",
+                    "description": "Guards against a signature the issuer made over some other object being replayed here as authorization to publish."
+                },
+                "documentId": {
+                    "type": "string",
+                    "description": "The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session."
+                },
+                "vrcDigestMultibase": {
+                    "$ref": "#/$defs/DigestMultibase",
+                    "description": "Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another."
+                },
+                "proof": {
+                    "type": "object",
+                    "description": "Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes."
+                }
+            },
+            "required": [
+                "type",
+                "documentId",
+                "vrcDigestMultibase",
+                "proof"
+            ],
+            "additionalProperties": false
+        },
         "ext": {
             "$ref": "#/$defs/Ext"
         }

package/dist/vtc/relationships/publish/0.2/payload.js.map

@@ -1 +1 @@
-{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../src/vtc/relationships/publish/0.2/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AA+BH,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,qCAAqC;IAC9C,MAAM,EAAE,QAAQ;IAChB,sBAAsB,EAAE,KAAK;IAC7B,UAAU,EAAE;QACV,KAAK;KACN;IACD,YAAY,EAAE;QACZ,KAAK,EAAE;YACL,MAAM,EAAE,QAAQ;YAChB,aAAa,EAAE,uMAAuM;SACvN;QACD,KAAK,EAAE;YACL,MAAM,EAAE,aAAa;SACtB;KACF;IACD,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,8CAA8C;YACvD,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,IAAI;gBACJ,WAAW;gBACX,YAAY;gBACZ,oBAAoB;aACrB;YACD,YAAY,EAAE;gBACZ,IAAI,EAAE;oBACJ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,kDAAkD;iBAClE;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,oBAAoB,EAAE;oBACpB,MAAM,EAAE,yBAAyB;oBACjC,aAAa,EAAE,sQAAsQ;iBACtR;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;QACD,iBAAiB,EAAE;YACjB,OAAO,EAAE,iBAAiB;YAC1B,aAAa,EAAE,gnDAAgnD;YAC/nD,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,EAAE;YACf,SAAS,EAAE,4CAA4C;YACvD,UAAU,EAAE;gBACV,iDAAiD;aAClD;SACF;KACF;CACO,CAAC;AAEX,mEAAmE;AACnE,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACrC,SAAS,EAAE,8CAA8C;IACzD,MAAM,EAAE,kBAAkB;IAC1B,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,8CAA8C;YACvD,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,IAAI;gBACJ,WAAW;gBACX,YAAY;gBACZ,oBAAoB;aACrB;YACD,YAAY,EAAE;gBACZ,IAAI,EAAE;oBACJ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,kDAAkD;iBAClE;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,oBAAoB,EAAE;oBACpB,MAAM,EAAE,yBAAyB;oBACjC,aAAa,EAAE,sQAAsQ;iBACtR;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;QACD,iBAAiB,EAAE;YACjB,OAAO,EAAE,iBAAiB;YAC1B,aAAa,EAAE,gnDAAgnD;YAC/nD,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,EAAE;YACf,SAAS,EAAE,4CAA4C;YACvD,UAAU,EAAE;gBACV,iDAAiD;aAClD;SACF;KACF;CACO,CAAC;AAEX;;;;;GAKG;AACH,MAAM,CAAC,MAAM,IAAI,GAAG;IAClB,OAAO,EAAE,QAAQ;IACjB,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,IAAI;IACzB,aAAa,EAAE,cAAc;CACrB,CAAC;AAEX;;;;GAIG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG;IAC3B,OAAO,EAAE,iBAAiB;IAC1B,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,IAAI;IACzB,aAAa,EAAE,uBAAuB;CAC9B,CAAC"}
+{"version":3,"file":"payload.js","sourceRoot":"","sources":["../../../../../src/vtc/relationships/publish/0.2/payload.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAyDH,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,qCAAqC;IAC9C,MAAM,EAAE,QAAQ;IAChB,sBAAsB,EAAE,KAAK;IAC7B,UAAU,EAAE;QACV,KAAK;KACN;IACD,YAAY,EAAE;QACZ,KAAK,EAAE;YACL,MAAM,EAAE,QAAQ;YAChB,aAAa,EAAE,uMAAuM;SACvN;QACD,KAAK,EAAE;YACL,MAAM,EAAE,QAAQ;YAChB,aAAa,EAAE,ulBAAulB;YACtmB,YAAY,EAAE;gBACZ,MAAM,EAAE;oBACN,OAAO,EAAE,yBAAyB;oBAClC,aAAa,EAAE,oHAAoH;iBACpI;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,QAAQ;oBAChB,aAAa,EAAE,0TAA0T;iBAC1U;gBACD,oBAAoB,EAAE;oBACpB,MAAM,EAAE,yBAAyB;oBACjC,aAAa,EAAE,oJAAoJ;iBACpK;gBACD,OAAO,EAAE;oBACP,MAAM,EAAE,QAAQ;oBAChB,aAAa,EAAE,gLAAgL;iBAChM;aACF;YACD,UAAU,EAAE;gBACV,MAAM;gBACN,YAAY;gBACZ,oBAAoB;gBACpB,OAAO;aACR;YACD,sBAAsB,EAAE,KAAK;SAC9B;QACD,KAAK,EAAE;YACL,MAAM,EAAE,aAAa;SACtB;KACF;IACD,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,8CAA8C;YACvD,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,IAAI;gBACJ,WAAW;gBACX,YAAY;gBACZ,oBAAoB;aACrB;YACD,YAAY,EAAE;gBACZ,IAAI,EAAE;oBACJ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,kDAAkD;iBAClE;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,oBAAoB,EAAE;oBACpB,MAAM,EAAE,yBAAyB;oBACjC,aAAa,EAAE,sQAAsQ;iBACtR;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;QACD,iBAAiB,EAAE;YACjB,OAAO,EAAE,iBAAiB;YAC1B,aAAa,EAAE,gnDAAgnD;YAC/nD,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,EAAE;YACf,SAAS,EAAE,4CAA4C;YACvD,UAAU,EAAE;gBACV,iDAAiD;aAClD;SACF;KACF;CACO,CAAC;AAEX,mEAAmE;AACnE,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACrC,SAAS,EAAE,8CAA8C;IACzD,MAAM,EAAE,kBAAkB;IAC1B,OAAO,EAAE;QACP,UAAU,EAAE;YACV,SAAS,EAAE,UAAU;YACrB,OAAO,EAAE,8CAA8C;YACvD,MAAM,EAAE,QAAQ;YAChB,sBAAsB,EAAE,KAAK;YAC7B,UAAU,EAAE;gBACV,IAAI;gBACJ,WAAW;gBACX,YAAY;gBACZ,oBAAoB;aACrB;YACD,YAAY,EAAE;gBACZ,IAAI,EAAE;oBACJ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;oBACd,aAAa,EAAE,kDAAkD;iBAClE;gBACD,WAAW,EAAE;oBACX,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,YAAY,EAAE;oBACZ,MAAM,EAAE,QAAQ;oBAChB,WAAW,EAAE,CAAC;iBACf;gBACD,oBAAoB,EAAE;oBACpB,MAAM,EAAE,yBAAyB;oBACjC,aAAa,EAAE,sQAAsQ;iBACtR;gBACD,KAAK,EAAE;oBACL,MAAM,EAAE,aAAa;iBACtB;aACF;SACF;QACD,KAAK,EAAE;YACL,OAAO,EAAE,KAAK;YACd,aAAa,EAAE,uKAAuK;YACtL,MAAM,EAAE,QAAQ;YAChB,eAAe,EAAE,CAAC;YAClB,sBAAsB,EAAE,IAAI;YAC5B,eAAe,EAAE;gBACf,SAAS,EAAE,mCAAmC;aAC/C;SACF;QACD,iBAAiB,EAAE;YACjB,OAAO,EAAE,iBAAiB;YAC1B,aAAa,EAAE,gnDAAgnD;YAC/nD,MAAM,EAAE,QAAQ;YAChB,WAAW,EAAE,EAAE;YACf,SAAS,EAAE,4CAA4C;YACvD,UAAU,EAAE;gBACV,iDAAiD;aAClD;SACF;KACF;CACO,CAAC;AAEX;;;;;GAKG;AACH,MAAM,CAAC,MAAM,IAAI,GAAG;IAClB,OAAO,EAAE,QAAQ;IACjB,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,IAAI;IACzB,aAAa,EAAE,cAAc;CACrB,CAAC;AAEX;;;;GAIG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG;IAC3B,OAAO,EAAE,iBAAiB;IAC1B,QAAQ,EAAE,KAAK;IACf,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,IAAI;IACzB,aAAa,EAAE,uBAAuB;CAC9B,CAAC"}

package/package.json

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

package/src/vtc/relationships/publish/0.1/payload.ts

@@ -3,11 +3,38 @@
  * Source: specs/vtc/relationships/publish/0.1/payload.schema.json
  */
 
+/**
+ * Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another.
+ */
+export type DigestMultibase = string;
+
 export interface VTCRelationshipsPublishPayload {
   /**
    * A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof.
    */
   vrc: {};
+  /**
+   * Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.
+   *
+   * A member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.
+   *
+   * Omit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.
+   */
+  pop?: {
+    /**
+     * Guards against a signature the issuer made over some other object being replayed here as authorization to publish.
+     */
+    type: "VrcPublishAuthorization";
+    /**
+     * The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session.
+     */
+    documentId: string;
+    vrcDigestMultibase: DigestMultibase;
+    /**
+     * Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes.
+     */
+    proof: {};
+  };
   ext?: Ext;
 }
 /**
@@ -65,6 +92,35 @@ export const PAYLOAD_SCHEMA = {
       "type": "object",
       "description": "A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof."
     },
+    "pop": {
+      "type": "object",
+      "description": "Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.\n\nA member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.\n\nOmit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.",
+      "properties": {
+        "type": {
+          "const": "VrcPublishAuthorization",
+          "description": "Guards against a signature the issuer made over some other object being replayed here as authorization to publish."
+        },
+        "documentId": {
+          "type": "string",
+          "description": "The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session."
+        },
+        "vrcDigestMultibase": {
+          "$ref": "#/$defs/DigestMultibase",
+          "description": "Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another."
+        },
+        "proof": {
+          "type": "object",
+          "description": "Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes."
+        }
+      },
+      "required": [
+        "type",
+        "documentId",
+        "vrcDigestMultibase",
+        "proof"
+      ],
+      "additionalProperties": false
+    },
     "ext": {
       "$ref": "#/$defs/Ext"
     }
@@ -114,6 +170,16 @@ export const PAYLOAD_SCHEMA = {
       "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;
@@ -167,6 +233,16 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
       "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;

package/src/vtc/relationships/publish/0.2/payload.ts

@@ -4,15 +4,41 @@
  */
 
 /**
- * Digest over the RFC 8785 canonicalization of the stored VRC, for out-of-band integrity checks. The same value vtc/relationships/request reports on issuance and vtc/relationships/list reports per entry, so a member can tie the three together without re-hashing.
+ * Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another.
  */
 export type DigestMultibase = string;
+/**
+ * Digest over the RFC 8785 canonicalization of the stored VRC, for out-of-band integrity checks. The same value vtc/relationships/request reports on issuance and vtc/relationships/list reports per entry, so a member can tie the three together without re-hashing.
+ */
+export type DigestMultibase1 = string;
 
 export interface VTCRelationshipsPublishPayload {
   /**
    * A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof.
    */
   vrc: {};
+  /**
+   * Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.
+   *
+   * A member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.
+   *
+   * Omit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.
+   */
+  pop?: {
+    /**
+     * Guards against a signature the issuer made over some other object being replayed here as authorization to publish.
+     */
+    type: "VrcPublishAuthorization";
+    /**
+     * The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session.
+     */
+    documentId: string;
+    vrcDigestMultibase: DigestMultibase;
+    /**
+     * Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes.
+     */
+    proof: {};
+  };
   ext?: Ext;
 }
 /**
@@ -28,7 +54,7 @@ export interface VTCRelationshipsPublishResponsePayload {
   id: string;
   issuerDid: string;
   subjectDid: string;
-  vrcDigestMultibase: DigestMultibase;
+  vrcDigestMultibase: DigestMultibase1;
   ext?: Ext;
 }
 
@@ -67,6 +93,35 @@ export const PAYLOAD_SCHEMA = {
       "type": "object",
       "description": "A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST equal the document proof signer; credentialSubject.id names the subject member; it carries its own DataIntegrityProof."
     },
+    "pop": {
+      "type": "object",
+      "description": "Proof that the caller controls the key behind the VRC's `issuer`, when that is not the party issuing this document.\n\nA member publishes an edge under a relationship DID — an identifier scoped to one counterparty, which names nobody. The community still has to know a member published it, and the document's own `proof` says only that the member sent it, not that they control the credential's issuing key. Without this, any member handed a VRC could publish another party's edge.\n\nOmit it when the VRC's `issuer` is this document's issuer: the document's own proof already establishes control.",
+      "properties": {
+        "type": {
+          "const": "VrcPublishAuthorization",
+          "description": "Guards against a signature the issuer made over some other object being replayed here as authorization to publish."
+        },
+        "documentId": {
+          "type": "string",
+          "description": "The `id` of the Trust Task document carrying this authorization. Binds the authorization to one document, so a captured one cannot be replayed in another — including by a different member. Every document carries a unique `id` (SPEC §4.3), which is why the binding needs no transport-specific notion of a session."
+        },
+        "vrcDigestMultibase": {
+          "$ref": "#/$defs/DigestMultibase",
+          "description": "Digest over the RFC 8785 canonicalization of the VRC this authorizes. Binds the authorization to one credential, so it cannot be moved to another."
+        },
+        "proof": {
+          "type": "object",
+          "description": "Data-integrity proof over this object, by a verification method the VRC's `issuer` controls. This is the proof of possession; the members above only bound what it authorizes."
+        }
+      },
+      "required": [
+        "type",
+        "documentId",
+        "vrcDigestMultibase",
+        "proof"
+      ],
+      "additionalProperties": false
+    },
     "ext": {
       "$ref": "#/$defs/Ext"
     }