@openvtc/trust-tasks 0.19.19 → 0.19.21

package/src/messaging/account/get/0.1/payload.ts

@@ -11,6 +11,10 @@ export interface MessagingGetAccountPayload {
    * The DID of the account to fetch.
    */
   did: Vid;
+  /**
+   * When true, the mediator includes each returned account's `lastReceivedAt` and `lastAuthenticatedAt`, where recorded. Omitted or false = neither is returned.
+   */
+  includeActivity?: boolean;
   /**
    * Ecosystem-defined extension members per SPEC.md §4.5.1.
    */
@@ -68,6 +72,10 @@ export const PAYLOAD_SCHEMA = {
       "$ref": "#/$defs/Vid",
       "description": "The DID of the account to fetch."
     },
+    "includeActivity": {
+      "type": "boolean",
+      "description": "When true, the mediator includes each returned account's `lastReceivedAt` and `lastAuthenticatedAt`, where recorded. Omitted or false = neither is returned."
+    },
     "ext": {
       "$ref": "#/$defs/Ext",
       "description": "Ecosystem-defined extension members per SPEC.md §4.5.1."
@@ -152,6 +160,16 @@ export const PAYLOAD_SCHEMA = {
           "type": "integer",
           "minimum": 0,
           "description": "Number of entries in the account's access list."
+        },
+        "lastReceivedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which the mediator last accepted a message addressed to this account. Present only when the request set `includeActivity` and the mediator has recorded such a message; MAY lag the true time by up to 60 seconds."
+        },
+        "lastAuthenticatedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which this account last completed authentication with the mediator, over any transport. Present only when the request set `includeActivity` and the mediator has recorded an authentication."
         }
       }
     },
@@ -344,6 +362,16 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           "type": "integer",
           "minimum": 0,
           "description": "Number of entries in the account's access list."
+        },
+        "lastReceivedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which the mediator last accepted a message addressed to this account. Present only when the request set `includeActivity` and the mediator has recorded such a message; MAY lag the true time by up to 60 seconds."
+        },
+        "lastAuthenticatedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which this account last completed authentication with the mediator, over any transport. Present only when the request set `includeActivity` and the mediator has recorded an authentication."
         }
       }
     },

package/src/messaging/account/list/0.1/payload.ts

@@ -19,6 +19,10 @@ export interface MessagingListAccountsPayload {
    * Maximum number of accounts to return in this page. The mediator chooses a default when omitted.
    */
   limit?: number;
+  /**
+   * When true, the mediator includes each returned account's `lastReceivedAt` and `lastAuthenticatedAt`, where recorded. Omitted or false = neither is returned.
+   */
+  includeActivity?: boolean;
   /**
    * Ecosystem-defined extension members per SPEC.md §4.5.1.
    */
@@ -88,6 +92,10 @@ export const PAYLOAD_SCHEMA = {
       "maximum": 1000,
       "description": "Maximum number of accounts to return in this page. The mediator chooses a default when omitted."
     },
+    "includeActivity": {
+      "type": "boolean",
+      "description": "When true, the mediator includes each returned account's `lastReceivedAt` and `lastAuthenticatedAt`, where recorded. Omitted or false = neither is returned."
+    },
     "ext": {
       "$ref": "#/$defs/Ext",
       "description": "Ecosystem-defined extension members per SPEC.md §4.5.1."
@@ -180,6 +188,16 @@ export const PAYLOAD_SCHEMA = {
           "type": "integer",
           "minimum": 0,
           "description": "Number of entries in the account's access list."
+        },
+        "lastReceivedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which the mediator last accepted a message addressed to this account. Present only when the request set `includeActivity` and the mediator has recorded such a message; MAY lag the true time by up to 60 seconds."
+        },
+        "lastAuthenticatedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which this account last completed authentication with the mediator, over any transport. Present only when the request set `includeActivity` and the mediator has recorded an authentication."
         }
       }
     },
@@ -380,6 +398,16 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           "type": "integer",
           "minimum": 0,
           "description": "Number of entries in the account's access list."
+        },
+        "lastReceivedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which the mediator last accepted a message addressed to this account. Present only when the request set `includeActivity` and the mediator has recorded such a message; MAY lag the true time by up to 60 seconds."
+        },
+        "lastAuthenticatedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which this account last completed authentication with the mediator, over any transport. Present only when the request set `includeActivity` and the mediator has recorded an authentication."
         }
       }
     },

package/src/messaging/account/update/0.1/payload.ts

@@ -176,6 +176,16 @@ export const PAYLOAD_SCHEMA = {
           "type": "integer",
           "minimum": 0,
           "description": "Number of entries in the account's access list."
+        },
+        "lastReceivedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which the mediator last accepted a message addressed to this account. Present only when the request set `includeActivity` and the mediator has recorded such a message; MAY lag the true time by up to 60 seconds."
+        },
+        "lastAuthenticatedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which this account last completed authentication with the mediator, over any transport. Present only when the request set `includeActivity` and the mediator has recorded an authentication."
         }
       }
     },
@@ -368,6 +378,16 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           "type": "integer",
           "minimum": 0,
           "description": "Number of entries in the account's access list."
+        },
+        "lastReceivedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which the mediator last accepted a message addressed to this account. Present only when the request set `includeActivity` and the mediator has recorded such a message; MAY lag the true time by up to 60 seconds."
+        },
+        "lastAuthenticatedAt": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Unix epoch seconds at which this account last completed authentication with the mediator, over any transport. Present only when the request set `includeActivity` and the mediator has recorded an authentication."
         }
       }
     },

package/src/persona/binding/set/1.0/payload.ts

@@ -15,9 +15,9 @@ export interface PersonaBindingSetPayload {
    */
   contextId: string;
   /**
-   * The persona being bound.
+   * The persona being bound. Omit to use the persona the holder already uses in `contextId` — the one DID with a binding there, current or cleared. None is refused (`noPersonaHere`): a persona is minted on its own, through the DID-template path, never as a side effect of wearing a face. Several are refused (`personaAmbiguous`, naming them): picking one for the holder would decide which of their identities a context sees. The response names the persona used.
    */
-  personaDid: string;
+  personaDid?: string;
   /**
    * The profile to bind, or null to clear. Null is a first-class value and not an omission: a persona with no profile is a legitimate, common state — a throwaway identity that presents nothing — and the schema says so rather than leaving a consumer to infer it from an absent member.
    */
@@ -101,8 +101,7 @@ export const PAYLOAD_SCHEMA = {
   "type": "object",
   "additionalProperties": false,
   "required": [
-    "contextId",
-    "personaDid"
+    "contextId"
   ],
   "properties": {
     "contextId": {
@@ -114,7 +113,7 @@ export const PAYLOAD_SCHEMA = {
       "type": "string",
       "minLength": 1,
       "maxLength": 2048,
-      "description": "The persona being bound."
+      "description": "The persona being bound. Omit to use the persona the holder already uses in `contextId` — the one DID with a binding there, current or cleared. None is refused (`noPersonaHere`): a persona is minted on its own, through the DID-template path, never as a side effect of wearing a face. Several are refused (`personaAmbiguous`, naming them): picking one for the holder would decide which of their identities a context sees. The response names the persona used."
     },
     "profileId": {
       "oneOf": [

package/src/persona/profile/compose/1.0/payload.ts

@@ -35,11 +35,15 @@ export interface PersonaProfileComposePayload {
    */
   personaDid?: string;
   /**
-   * What the context may call the face, as on persona/binding/set. Meaningful only with `personaDid`; a maintainer MUST refuse it without one rather than drop it.
+   * Wear the new face in `contextId` as the persona the holder already uses in `contextId` — the one DID with a binding there, current or cleared. None is refused (`noPersonaHere`): a persona is minted on its own, through the DID-template path, never as a side effect of wearing a face. Several are refused (`personaAmbiguous`, naming them): picking one for the holder would decide which of their identities a context sees. Not with `personaDid`, which names the persona instead.
+   */
+  wear?: boolean;
+  /**
+   * What the context may call the face, as on persona/binding/set. Meaningful only when the face is worn (`personaDid` or `wear`); a maintainer MUST refuse it otherwise rather than drop it.
    */
   label?: string;
   /**
-   * When wearing the face here ends on its own, as persona/binding/set `until`: at it the binding clears and the face, if worn nowhere else, is retired — never deleted. For the face composed at the door of a conference or a listing, which is where a throwaway face is usually made. Meaningful only with `personaDid`, and refused without one or in the past (`untilNotFuture`).
+   * When wearing the face here ends on its own, as persona/binding/set `until`: at it the binding clears and the face, if worn nowhere else, is retired — never deleted. For the face composed at the door of a conference or a listing, which is where a throwaway face is usually made. Meaningful only when the face is worn (`personaDid` or `wear`), and refused otherwise or in the past (`untilNotFuture`).
    */
   until?: string;
   ext?: Ext;
@@ -171,16 +175,21 @@ export const PAYLOAD_SCHEMA = {
       "maxLength": 2048,
       "description": "Wear the new face as this persona in `contextId`, in the same act. Omit to compose without wearing it."
     },
+    "wear": {
+      "type": "boolean",
+      "default": false,
+      "description": "Wear the new face in `contextId` as the persona the holder already uses in `contextId` — the one DID with a binding there, current or cleared. None is refused (`noPersonaHere`): a persona is minted on its own, through the DID-template path, never as a side effect of wearing a face. Several are refused (`personaAmbiguous`, naming them): picking one for the holder would decide which of their identities a context sees. Not with `personaDid`, which names the persona instead."
+    },
     "label": {
       "type": "string",
       "minLength": 1,
       "maxLength": 128,
-      "description": "What the context may call the face, as on persona/binding/set. Meaningful only with `personaDid`; a maintainer MUST refuse it without one rather than drop it."
+      "description": "What the context may call the face, as on persona/binding/set. Meaningful only when the face is worn (`personaDid` or `wear`); a maintainer MUST refuse it otherwise rather than drop it."
     },
     "until": {
       "type": "string",
       "format": "date-time",
-      "description": "When wearing the face here ends on its own, as persona/binding/set `until`: at it the binding clears and the face, if worn nowhere else, is retired — never deleted. For the face composed at the door of a conference or a listing, which is where a throwaway face is usually made. Meaningful only with `personaDid`, and refused without one or in the past (`untilNotFuture`)."
+      "description": "When wearing the face here ends on its own, as persona/binding/set `until`: at it the binding clears and the face, if worn nowhere else, is retired — never deleted. For the face composed at the door of a conference or a listing, which is where a throwaway face is usually made. Meaningful only when the face is worn (`personaDid` or `wear`), and refused otherwise or in the past (`untilNotFuture`)."
     },
     "ext": {
       "$ref": "#/$defs/Ext"

package/src/vtc/join-requests/manifest/0.2/payload.ts

@@ -3,7 +3,7 @@
  * Source: specs/vtc/join-requests/manifest/0.2/payload.schema.json
  */
 
-import type { ClaimType, DigestMultibase, Ext, VettingDocumentation, VettingMethod } from "../../../../_shared/components.js";
+import type { ClaimType, DigestMultibase, Ext, ExtCritical, VettingDocumentation, VettingMethod } from "../../../../_shared/components.js";
 
 
 /**
@@ -135,6 +135,20 @@ export interface VettingRequirements {
    * Where the community's vetting governance — including the attestation text vetters sign — is published.
    */
   governanceFrameworkUrl?: string;
+  /**
+   * Ecosystem-defined extension members per SPEC.md §4.5.1, for vetting parameters this version does not enumerate. A community publishing an admission mode the base members cannot express — the zero-knowledge parameters an applicant proves against, say — puts them under a namespace it controls, rather than waiting for a version that names them.
+   *
+   * This object is already `additionalProperties: true`, so an unknown member here has always validated. That is not the same as reaching a consumer: a generated type names the members this schema declares and drops the rest, so an undeclared member is parsed and discarded, and it is discarded again on the re-serialization `requirementsDigest` is computed over. `ext` is a declared member, so it survives both.
+   */
+  ext?: Ext;
+  /**
+   * Namespaces of `ext` an applicant MUST understand or refuse, per SPEC.md §4.5.1.
+   *
+   * A community marks a namespace here when applying under this criterion without understanding it would mean something other than what the community requires — an applicant that ignored a hidden-vetting namespace, for instance, would submit named statements to a criterion whose whole point was that it does not receive them. An applicant that does not recognize a marked namespace stops rather than downgrading silently.
+   *
+   * Absent, which is the common case, every namespace under `ext` is advisory and ignorable.
+   */
+  extCritical?: ExtCritical;
   [k: string]: unknown | undefined;
 }
 /**
@@ -157,7 +171,7 @@ export interface CommunityBranding {
 }
 
 /** Shared definitions this specification references, re-exported under the names it used to declare them with. */
-export type { ClaimType, DigestMultibase, Ext, VettingDocumentation, VettingMethod };
+export type { ClaimType, DigestMultibase, Ext, ExtCritical, VettingDocumentation, VettingMethod };
 
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/vtc/join-requests/manifest/0.2" as const;
@@ -375,6 +389,14 @@ export const PAYLOAD_SCHEMA = {
           "pattern": "^https://",
           "maxLength": 2048,
           "description": "Where the community's vetting governance — including the attestation text vetters sign — is published."
+        },
+        "ext": {
+          "description": "Ecosystem-defined extension members per SPEC.md §4.5.1, for vetting parameters this version does not enumerate. A community publishing an admission mode the base members cannot express — the zero-knowledge parameters an applicant proves against, say — puts them under a namespace it controls, rather than waiting for a version that names them.\n\nThis object is already `additionalProperties: true`, so an unknown member here has always validated. That is not the same as reaching a consumer: a generated type names the members this schema declares and drops the rest, so an undeclared member is parsed and discarded, and it is discarded again on the re-serialization `requirementsDigest` is computed over. `ext` is a declared member, so it survives both.",
+          "$ref": "#/$defs/Ext"
+        },
+        "extCritical": {
+          "description": "Namespaces of `ext` an applicant MUST understand or refuse, per SPEC.md §4.5.1.\n\nA community marks a namespace here when applying under this criterion without understanding it would mean something other than what the community requires — an applicant that ignored a hidden-vetting namespace, for instance, would submit named statements to a criterion whose whole point was that it does not receive them. An applicant that does not recognize a marked namespace stops rather than downgrading silently.\n\nAbsent, which is the common case, every namespace under `ext` is advisory and ignorable.",
+          "$ref": "#/$defs/ExtCritical"
         }
       }
     },
@@ -476,6 +498,22 @@ export const PAYLOAD_SCHEMA = {
         "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
       }
     },
+    "ExtCritical": {
+      "title": "ExtCritical",
+      "description": "Names the `ext` namespaces a consumer MUST understand or refuse, per SPEC.md §4.5.1.\n\nEvery entry MUST be an immediate key of the sibling `ext` object at the same level; an entry naming an absent namespace is non-conforming and the consumer rejects the document with `malformedRequest`. A consumer that does not recognize a namespace named here MUST NOT process the document as though the namespace were absent, and rejects it with `unsupportedExtension` — the exception to the rule that unrecognized namespaces are ignored.\n\nA producer marks a namespace only where the document's meaning depends on it. Marking one that merely carries a hint or an annotation turns every consumer that has not implemented it into a failure where it would otherwise have interoperated. JSON Schema cannot check either of those rules: that an entry names a present namespace is checkable only against the sibling `ext`, and whether a namespace is load-bearing is not a schema question at all. Both are consumer-side checks.",
+      "type": "array",
+      "minItems": 1,
+      "uniqueItems": true,
+      "items": {
+        "type": "string",
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      },
+      "examples": [
+        [
+          "org.openvtc.hidden-vetting"
+        ]
+      ]
+    },
     "VettingRelationship": {
       "title": "VettingRelationship",
       "type": "string",
@@ -714,6 +752,14 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
           "pattern": "^https://",
           "maxLength": 2048,
           "description": "Where the community's vetting governance — including the attestation text vetters sign — is published."
+        },
+        "ext": {
+          "description": "Ecosystem-defined extension members per SPEC.md §4.5.1, for vetting parameters this version does not enumerate. A community publishing an admission mode the base members cannot express — the zero-knowledge parameters an applicant proves against, say — puts them under a namespace it controls, rather than waiting for a version that names them.\n\nThis object is already `additionalProperties: true`, so an unknown member here has always validated. That is not the same as reaching a consumer: a generated type names the members this schema declares and drops the rest, so an undeclared member is parsed and discarded, and it is discarded again on the re-serialization `requirementsDigest` is computed over. `ext` is a declared member, so it survives both.",
+          "$ref": "#/$defs/Ext"
+        },
+        "extCritical": {
+          "description": "Namespaces of `ext` an applicant MUST understand or refuse, per SPEC.md §4.5.1.\n\nA community marks a namespace here when applying under this criterion without understanding it would mean something other than what the community requires — an applicant that ignored a hidden-vetting namespace, for instance, would submit named statements to a criterion whose whole point was that it does not receive them. An applicant that does not recognize a marked namespace stops rather than downgrading silently.\n\nAbsent, which is the common case, every namespace under `ext` is advisory and ignorable.",
+          "$ref": "#/$defs/ExtCritical"
         }
       }
     },
@@ -815,6 +861,22 @@ export const RESPONSE_PAYLOAD_SCHEMA = {
         "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
       }
     },
+    "ExtCritical": {
+      "title": "ExtCritical",
+      "description": "Names the `ext` namespaces a consumer MUST understand or refuse, per SPEC.md §4.5.1.\n\nEvery entry MUST be an immediate key of the sibling `ext` object at the same level; an entry naming an absent namespace is non-conforming and the consumer rejects the document with `malformedRequest`. A consumer that does not recognize a namespace named here MUST NOT process the document as though the namespace were absent, and rejects it with `unsupportedExtension` — the exception to the rule that unrecognized namespaces are ignored.\n\nA producer marks a namespace only where the document's meaning depends on it. Marking one that merely carries a hint or an annotation turns every consumer that has not implemented it into a failure where it would otherwise have interoperated. JSON Schema cannot check either of those rules: that an entry names a present namespace is checkable only against the sibling `ext`, and whether a namespace is load-bearing is not a schema question at all. Both are consumer-side checks.",
+      "type": "array",
+      "minItems": 1,
+      "uniqueItems": true,
+      "items": {
+        "type": "string",
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      },
+      "examples": [
+        [
+          "org.openvtc.hidden-vetting"
+        ]
+      ]
+    },
     "VettingRelationship": {
       "title": "VettingRelationship",
       "type": "string",