@openvtc/trust-tasks 0.12.5 → 0.12.7

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