@openvtc/trust-tasks 0.12.6 → 0.12.8

package/src/vtc/members/list/0.1/payload.ts

@@ -73,6 +73,26 @@ export interface MemberResponse {
    * Id of the member's current role Verifiable Endorsement Credential, if issued.
    */
   currentRoleVecId?: string | null;
+  /**
+   * Whether the community has asserted that this member is a distinct real person. Read-only here: it is set and cleared by the personhood verbs, and cleared by a renewal-policy downgrade. Load-bearing rather than informational — a community that recognises members of another community may gate on it, so a consumer that cannot read it cannot make that decision.
+   */
+  personhood?: boolean;
+  /**
+   * When personhood was most recently asserted. Absent where it never has been. Operator-facing: it belongs on admin-gated reads, and a member's own view of themselves need carry only the flag.
+   */
+  personhoodAssertedAt?: string | null;
+  /**
+   * Whether this member joined by presenting an invitation credential rather than by an admin's decision on an open request. The two routes to membership carry different evidence, and an operator reviewing a roster can otherwise not tell them apart.
+   */
+  joinedViaInvitation?: boolean;
+  /**
+   * `id` of the member-issued reciprocal membership credential — the member half of the pair — once the member has sent it. Absent until then, which is the useful signal: it distinguishes a membership the community has asserted from one the member has acknowledged. The credential body is not echoed here.
+   */
+  memberVmcId?: string | null;
+  /**
+   * When that reciprocal credential was received. Paired with `memberVmcId`.
+   */
+  memberVmcReceivedAt?: string | null;
   /**
    * Opaque community-defined extension bag. Keys are maintainer-defined; the maintainer caps its size (16 KiB in the reference implementation).
    */
@@ -242,6 +262,37 @@ export const PAYLOAD_SCHEMA = {
           ],
           "description": "Id of the member's current role Verifiable Endorsement Credential, if issued."
         },
+        "personhood": {
+          "type": "boolean",
+          "description": "Whether the community has asserted that this member is a distinct real person. Read-only here: it is set and cleared by the personhood verbs, and cleared by a renewal-policy downgrade. Load-bearing rather than informational — a community that recognises members of another community may gate on it, so a consumer that cannot read it cannot make that decision."
+        },
+        "personhoodAssertedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When personhood was most recently asserted. Absent where it never has been. Operator-facing: it belongs on admin-gated reads, and a member's own view of themselves need carry only the flag."
+        },
+        "joinedViaInvitation": {
+          "type": "boolean",
+          "description": "Whether this member joined by presenting an invitation credential rather than by an admin's decision on an open request. The two routes to membership carry different evidence, and an operator reviewing a roster can otherwise not tell them apart."
+        },
+        "memberVmcId": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "description": "`id` of the member-issued reciprocal membership credential — the member half of the pair — once the member has sent it. Absent until then, which is the useful signal: it distinguishes a membership the community has asserted from one the member has acknowledged. The credential body is not echoed here."
+        },
+        "memberVmcReceivedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When that reciprocal credential was received. Paired with `memberVmcId`."
+        },
         "extensions": {
           "type": "object",
           "description": "Opaque community-defined extension bag. Keys are maintainer-defined; the maintainer caps its size (16 KiB in the reference implementation)."
@@ -371,6 +422,37 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           ],
           "description": "Id of the member's current role Verifiable Endorsement Credential, if issued."
         },
+        "personhood": {
+          "type": "boolean",
+          "description": "Whether the community has asserted that this member is a distinct real person. Read-only here: it is set and cleared by the personhood verbs, and cleared by a renewal-policy downgrade. Load-bearing rather than informational — a community that recognises members of another community may gate on it, so a consumer that cannot read it cannot make that decision."
+        },
+        "personhoodAssertedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When personhood was most recently asserted. Absent where it never has been. Operator-facing: it belongs on admin-gated reads, and a member's own view of themselves need carry only the flag."
+        },
+        "joinedViaInvitation": {
+          "type": "boolean",
+          "description": "Whether this member joined by presenting an invitation credential rather than by an admin's decision on an open request. The two routes to membership carry different evidence, and an operator reviewing a roster can otherwise not tell them apart."
+        },
+        "memberVmcId": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "description": "`id` of the member-issued reciprocal membership credential — the member half of the pair — once the member has sent it. Absent until then, which is the useful signal: it distinguishes a membership the community has asserted from one the member has acknowledged. The credential body is not echoed here."
+        },
+        "memberVmcReceivedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When that reciprocal credential was received. Paired with `memberVmcId`."
+        },
         "extensions": {
           "type": "object",
           "description": "Opaque community-defined extension bag. Keys are maintainer-defined; the maintainer caps its size (16 KiB in the reference implementation)."

package/src/vtc/members/show/0.1/payload.ts

@@ -57,6 +57,26 @@ export interface MemberResponse {
    * Id of the member's current role Verifiable Endorsement Credential, if issued.
    */
   currentRoleVecId?: string | null;
+  /**
+   * Whether the community has asserted that this member is a distinct real person. Read-only here: it is set and cleared by the personhood verbs, and cleared by a renewal-policy downgrade. Load-bearing rather than informational — a community that recognises members of another community may gate on it, so a consumer that cannot read it cannot make that decision.
+   */
+  personhood?: boolean;
+  /**
+   * When personhood was most recently asserted. Absent where it never has been. Operator-facing: it belongs on admin-gated reads, and a member's own view of themselves need carry only the flag.
+   */
+  personhoodAssertedAt?: string | null;
+  /**
+   * Whether this member joined by presenting an invitation credential rather than by an admin's decision on an open request. The two routes to membership carry different evidence, and an operator reviewing a roster can otherwise not tell them apart.
+   */
+  joinedViaInvitation?: boolean;
+  /**
+   * `id` of the member-issued reciprocal membership credential — the member half of the pair — once the member has sent it. Absent until then, which is the useful signal: it distinguishes a membership the community has asserted from one the member has acknowledged. The credential body is not echoed here.
+   */
+  memberVmcId?: string | null;
+  /**
+   * When that reciprocal credential was received. Paired with `memberVmcId`.
+   */
+  memberVmcReceivedAt?: string | null;
   /**
    * Opaque community-defined extension bag. Keys are maintainer-defined; the maintainer caps its size (16 KiB in the reference implementation).
    */
@@ -202,6 +222,37 @@ export const PAYLOAD_SCHEMA = {
           ],
           "description": "Id of the member's current role Verifiable Endorsement Credential, if issued."
         },
+        "personhood": {
+          "type": "boolean",
+          "description": "Whether the community has asserted that this member is a distinct real person. Read-only here: it is set and cleared by the personhood verbs, and cleared by a renewal-policy downgrade. Load-bearing rather than informational — a community that recognises members of another community may gate on it, so a consumer that cannot read it cannot make that decision."
+        },
+        "personhoodAssertedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When personhood was most recently asserted. Absent where it never has been. Operator-facing: it belongs on admin-gated reads, and a member's own view of themselves need carry only the flag."
+        },
+        "joinedViaInvitation": {
+          "type": "boolean",
+          "description": "Whether this member joined by presenting an invitation credential rather than by an admin's decision on an open request. The two routes to membership carry different evidence, and an operator reviewing a roster can otherwise not tell them apart."
+        },
+        "memberVmcId": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "description": "`id` of the member-issued reciprocal membership credential — the member half of the pair — once the member has sent it. Absent until then, which is the useful signal: it distinguishes a membership the community has asserted from one the member has acknowledged. The credential body is not echoed here."
+        },
+        "memberVmcReceivedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When that reciprocal credential was received. Paired with `memberVmcId`."
+        },
         "extensions": {
           "type": "object",
           "description": "Opaque community-defined extension bag. Keys are maintainer-defined; the maintainer caps its size (16 KiB in the reference implementation)."
@@ -314,6 +365,37 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           ],
           "description": "Id of the member's current role Verifiable Endorsement Credential, if issued."
         },
+        "personhood": {
+          "type": "boolean",
+          "description": "Whether the community has asserted that this member is a distinct real person. Read-only here: it is set and cleared by the personhood verbs, and cleared by a renewal-policy downgrade. Load-bearing rather than informational — a community that recognises members of another community may gate on it, so a consumer that cannot read it cannot make that decision."
+        },
+        "personhoodAssertedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When personhood was most recently asserted. Absent where it never has been. Operator-facing: it belongs on admin-gated reads, and a member's own view of themselves need carry only the flag."
+        },
+        "joinedViaInvitation": {
+          "type": "boolean",
+          "description": "Whether this member joined by presenting an invitation credential rather than by an admin's decision on an open request. The two routes to membership carry different evidence, and an operator reviewing a roster can otherwise not tell them apart."
+        },
+        "memberVmcId": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "description": "`id` of the member-issued reciprocal membership credential — the member half of the pair — once the member has sent it. Absent until then, which is the useful signal: it distinguishes a membership the community has asserted from one the member has acknowledged. The credential body is not echoed here."
+        },
+        "memberVmcReceivedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When that reciprocal credential was received. Paired with `memberVmcId`."
+        },
         "extensions": {
           "type": "object",
           "description": "Opaque community-defined extension bag. Keys are maintainer-defined; the maintainer caps its size (16 KiB in the reference implementation)."

package/src/vtc/members/update/0.1/payload.ts

@@ -12,6 +12,10 @@ export interface VTCMembersUpdatePayload {
    * New role (wire form). MUST NOT be `admin` — promotion to admin is a separate, gated flow, not a metadata patch.
    */
   role?: string;
+  /**
+   * Operator-facing display label for this member. Editable, unlike the DID it labels — which is the point: an operator needs a name they can read on a roster of identifiers they cannot. `null` clears it; omit to leave it unchanged.
+   */
+  label?: string | null;
   /**
    * New directory-publish consent.
    */
@@ -70,6 +74,26 @@ export interface MemberResponse {
    * Id of the member's current role Verifiable Endorsement Credential, if issued.
    */
   currentRoleVecId?: string | null;
+  /**
+   * Whether the community has asserted that this member is a distinct real person. Read-only here: it is set and cleared by the personhood verbs, and cleared by a renewal-policy downgrade. Load-bearing rather than informational — a community that recognises members of another community may gate on it, so a consumer that cannot read it cannot make that decision.
+   */
+  personhood?: boolean;
+  /**
+   * When personhood was most recently asserted. Absent where it never has been. Operator-facing: it belongs on admin-gated reads, and a member's own view of themselves need carry only the flag.
+   */
+  personhoodAssertedAt?: string | null;
+  /**
+   * Whether this member joined by presenting an invitation credential rather than by an admin's decision on an open request. The two routes to membership carry different evidence, and an operator reviewing a roster can otherwise not tell them apart.
+   */
+  joinedViaInvitation?: boolean;
+  /**
+   * `id` of the member-issued reciprocal membership credential — the member half of the pair — once the member has sent it. Absent until then, which is the useful signal: it distinguishes a membership the community has asserted from one the member has acknowledged. The credential body is not echoed here.
+   */
+  memberVmcId?: string | null;
+  /**
+   * When that reciprocal credential was received. Paired with `memberVmcId`.
+   */
+  memberVmcReceivedAt?: string | null;
   /**
    * Opaque community-defined extension bag. Keys are maintainer-defined; the maintainer caps its size (16 KiB in the reference implementation).
    */
@@ -117,6 +141,13 @@ export const PAYLOAD_SCHEMA = {
       "minLength": 1,
       "description": "New role (wire form). MUST NOT be `admin` — promotion to admin is a separate, gated flow, not a metadata patch."
     },
+    "label": {
+      "type": [
+        "string",
+        "null"
+      ],
+      "description": "Operator-facing display label for this member. Editable, unlike the DID it labels — which is the point: an operator needs a name they can read on a roster of identifiers they cannot. `null` clears it; omit to leave it unchanged."
+    },
     "publishConsent": {
       "type": "boolean",
       "description": "New directory-publish consent."
@@ -237,6 +268,37 @@ export const PAYLOAD_SCHEMA = {
           ],
           "description": "Id of the member's current role Verifiable Endorsement Credential, if issued."
         },
+        "personhood": {
+          "type": "boolean",
+          "description": "Whether the community has asserted that this member is a distinct real person. Read-only here: it is set and cleared by the personhood verbs, and cleared by a renewal-policy downgrade. Load-bearing rather than informational — a community that recognises members of another community may gate on it, so a consumer that cannot read it cannot make that decision."
+        },
+        "personhoodAssertedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When personhood was most recently asserted. Absent where it never has been. Operator-facing: it belongs on admin-gated reads, and a member's own view of themselves need carry only the flag."
+        },
+        "joinedViaInvitation": {
+          "type": "boolean",
+          "description": "Whether this member joined by presenting an invitation credential rather than by an admin's decision on an open request. The two routes to membership carry different evidence, and an operator reviewing a roster can otherwise not tell them apart."
+        },
+        "memberVmcId": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "description": "`id` of the member-issued reciprocal membership credential — the member half of the pair — once the member has sent it. Absent until then, which is the useful signal: it distinguishes a membership the community has asserted from one the member has acknowledged. The credential body is not echoed here."
+        },
+        "memberVmcReceivedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When that reciprocal credential was received. Paired with `memberVmcId`."
+        },
         "extensions": {
           "type": "object",
           "description": "Opaque community-defined extension bag. Keys are maintainer-defined; the maintainer caps its size (16 KiB in the reference implementation)."
@@ -349,6 +411,37 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           ],
           "description": "Id of the member's current role Verifiable Endorsement Credential, if issued."
         },
+        "personhood": {
+          "type": "boolean",
+          "description": "Whether the community has asserted that this member is a distinct real person. Read-only here: it is set and cleared by the personhood verbs, and cleared by a renewal-policy downgrade. Load-bearing rather than informational — a community that recognises members of another community may gate on it, so a consumer that cannot read it cannot make that decision."
+        },
+        "personhoodAssertedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When personhood was most recently asserted. Absent where it never has been. Operator-facing: it belongs on admin-gated reads, and a member's own view of themselves need carry only the flag."
+        },
+        "joinedViaInvitation": {
+          "type": "boolean",
+          "description": "Whether this member joined by presenting an invitation credential rather than by an admin's decision on an open request. The two routes to membership carry different evidence, and an operator reviewing a roster can otherwise not tell them apart."
+        },
+        "memberVmcId": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "description": "`id` of the member-issued reciprocal membership credential — the member half of the pair — once the member has sent it. Absent until then, which is the useful signal: it distinguishes a membership the community has asserted from one the member has acknowledged. The credential body is not echoed here."
+        },
+        "memberVmcReceivedAt": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time",
+          "description": "When that reciprocal credential was received. Paired with `memberVmcId`."
+        },
         "extensions": {
           "type": "object",
           "description": "Opaque community-defined extension bag. Keys are maintainer-defined; the maintainer caps its size (16 KiB in the reference implementation)."

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"
     }