@openvtc/trust-tasks 0.19.20 → 0.19.22

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

@@ -3,7 +3,7 @@
  * Source: specs/messaging/account/update/0.1/payload.schema.json
  */
 
-import type { Account, AccountType, Ext, MediatorAcl, QueueLimits, Vid } from "../../../../_shared/components.js";
+import type { Account, AccountStats, AccountType, Ext, MediatorAcl, ProtocolCounts, QueueLimits, Vid } from "../../../../_shared/components.js";
 
 
 export interface MessagingUpdateAccountPayload {
@@ -43,7 +43,7 @@ export interface MessagingUpdateAccountResponsePayload {
 }
 
 /** Shared definitions this specification references, re-exported under the names it used to declare them with. */
-export type { Account, AccountType, Ext, MediatorAcl, QueueLimits, Vid };
+export type { Account, AccountStats, AccountType, Ext, MediatorAcl, ProtocolCounts, QueueLimits, Vid };
 
 /** Trust Task type URI. */
 export const TYPE_URI = "https://trusttasks.org/spec/messaging/account/update/0.1" as const;
@@ -176,6 +176,84 @@ 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."
+        },
+        "stats": {
+          "$ref": "#/$defs/AccountStats",
+          "description": "Lifetime counters the mediator keeps for this account. Present only when the request set `includeStats`."
+        }
+      }
+    },
+    "AccountStats": {
+      "title": "AccountStats",
+      "type": "object",
+      "additionalProperties": false,
+      "description": "What an account has sent and received over its lifetime, as the mediator counted it. Every member is optional: a mediator reports what it keeps, and a counter absent from a response was not kept rather than zero. Counters survive restarts and are not reset by reading them; removing an account discards them.",
+      "properties": {
+        "messagesReceived": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Messages the mediator accepted addressed to this account."
+        },
+        "messagesSent": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Messages the mediator accepted from this account."
+        },
+        "bytesReceived": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Total size of the messages counted by messagesReceived."
+        },
+        "bytesSent": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Total size of the messages counted by messagesSent."
+        },
+        "receivedByProtocol": {
+          "$ref": "#/$defs/ProtocolCounts",
+          "description": "messagesReceived split by the wire protocol the message arrived in."
+        },
+        "sentByProtocol": {
+          "$ref": "#/$defs/ProtocolCounts",
+          "description": "messagesSent split by the wire protocol the message was sent in."
+        }
+      }
+    },
+    "ProtocolCounts": {
+      "title": "ProtocolCounts",
+      "type": "object",
+      "additionalProperties": false,
+      "description": "Message counts split by wire protocol. An absent member is a protocol the mediator counted nothing for. The member names match the WireProtocol values the traffic monitor reports.",
+      "properties": {
+        "didcomm": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "DIDComm v2 (JWE/JWS)."
+        },
+        "didcommV1": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "A DIDComm v1 envelope."
+        },
+        "tsp": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "A Trust Spanning Protocol message."
+        },
+        "other": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Anything the mediator could not classify."
         }
       }
     },
@@ -368,6 +446,84 @@ 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."
+        },
+        "stats": {
+          "$ref": "#/$defs/AccountStats",
+          "description": "Lifetime counters the mediator keeps for this account. Present only when the request set `includeStats`."
+        }
+      }
+    },
+    "AccountStats": {
+      "title": "AccountStats",
+      "type": "object",
+      "additionalProperties": false,
+      "description": "What an account has sent and received over its lifetime, as the mediator counted it. Every member is optional: a mediator reports what it keeps, and a counter absent from a response was not kept rather than zero. Counters survive restarts and are not reset by reading them; removing an account discards them.",
+      "properties": {
+        "messagesReceived": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Messages the mediator accepted addressed to this account."
+        },
+        "messagesSent": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Messages the mediator accepted from this account."
+        },
+        "bytesReceived": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Total size of the messages counted by messagesReceived."
+        },
+        "bytesSent": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Total size of the messages counted by messagesSent."
+        },
+        "receivedByProtocol": {
+          "$ref": "#/$defs/ProtocolCounts",
+          "description": "messagesReceived split by the wire protocol the message arrived in."
+        },
+        "sentByProtocol": {
+          "$ref": "#/$defs/ProtocolCounts",
+          "description": "messagesSent split by the wire protocol the message was sent in."
+        }
+      }
+    },
+    "ProtocolCounts": {
+      "title": "ProtocolCounts",
+      "type": "object",
+      "additionalProperties": false,
+      "description": "Message counts split by wire protocol. An absent member is a protocol the mediator counted nothing for. The member names match the WireProtocol values the traffic monitor reports.",
+      "properties": {
+        "didcomm": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "DIDComm v2 (JWE/JWS)."
+        },
+        "didcommV1": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "A DIDComm v1 envelope."
+        },
+        "tsp": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "A Trust Spanning Protocol message."
+        },
+        "other": {
+          "type": "integer",
+          "minimum": 0,
+          "description": "Anything the mediator could not classify."
         }
       }
     },

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

package/src/vtc/vetting/vetters/show/0.1/payload.ts

@@ -0,0 +1,267 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/vtc/vetting/vetters/show/0.1/payload.schema.json
+ */
+
+import type { Ext } from "../../../../../_shared/components.js";
+
+
+/**
+ * The state of a vetter's grant in this community. The three refusing values are deliberately distinct: `revoked` says the community withdrew a grant it had made, `expired` says one ran out, and `none` says there is nothing to withdraw. An applicant reads those differently, and so does a vetter checking their own standing.
+ */
+export type GrantStatus = "live" | "revoked" | "expired" | "none";
+
+/**
+ * An authenticated applicant or member asks a community about one vetter, by DID. The answer is the state of that vetter's grant — `live`, `revoked`, `expired` or `none` — which a list of vetters cannot express, because an absent vetter and a revoked one look identical in it. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3.
+ */
+export interface VTCVettingShowVetterPayload {
+  /**
+   * The DID of the vetter being asked about — the subject of the vetter role credential. The caller usually holds it from an earlier listing, or from a vetting exchange that has since gone quiet.
+   */
+  vetterDid: string;
+  ext?: Ext;
+}
+/**
+ * One vetter's grant status. Carries no profile: what a vetter published for a directory is answered by vtc/vetting/vetters/list, and this task answers a caller who already knows which vetter they mean.
+ */
+export interface VTCVettingShowVetterResponsePayload {
+  /**
+   * The DID asked about, echoed so a response is self-contained.
+   */
+  vetterDid: string;
+  status: GrantStatus;
+  /**
+   * The identifier of the grant this status is about. Present for `live`, `revoked` and `expired`; absent for `none`, which is the absence of a grant and so has nothing to identify.
+   */
+  grantId?: string;
+  /**
+   * The grant's `validUntil`. Present for `live` and `expired` — for `expired` it is when it ran out, which tells a caller whether it lapsed long ago or yesterday. Absent for `none`, and for `revoked`, where the revocation and not the expiry is what ended it.
+   */
+  validUntil?: string;
+  /**
+   * When the grant was revoked. Present only for `revoked`. The reason is deliberately not carried: it is the community's internal record, and an applicant needs to know the grant does not hold, not why.
+   */
+  revokedAt?: string;
+  /**
+   * Whether this vetter has a profile stored with `listed: true`, and so would appear in vtc/vetting/vetters/list. Present only for `live`. It is what separates the two reasons a live vetter is missing from a listing: unlisted by choice, rather than not a vetter.
+   */
+  listed?: boolean;
+  ext?: Ext;
+}
+
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { Ext };
+
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/vtc/vetting/vetters/show/0.1" as const;
+
+/** Stable alias for this specification's request payload shape. */
+export type Payload = VTCVettingShowVetterPayload;
+
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/vtc/vetting/vetters/show/0.1#response" as const;
+
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = VTCVettingShowVetterResponsePayload;
+
+/**
+ * This specification's payload schema, as a value.
+ *
+ * SPEC.md §7.2 item 2 is performed against this. It is shipped as data
+ * rather than only as a `.json` file because TypeScript types are erased
+ * at runtime: without a schema a consumer has nothing to validate, and
+ * every REQUIRED payload member is optional in practice. Cross-file
+ * `$ref`s are already inlined, so it needs no resolver.
+ */
+export const PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://trusttasks.org/spec/vtc/vetting/vetters/show/0.1",
+  "title": "VTC Vetting — Show Vetter — payload",
+  "description": "An authenticated applicant or member asks a community about one vetter, by DID. The answer is the state of that vetter's grant — `live`, `revoked`, `expired` or `none` — which a list of vetters cannot express, because an absent vetter and a revoked one look identical in it. The outer document members (id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the framework — SPEC §6.3.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "vetterDid"
+  ],
+  "properties": {
+    "vetterDid": {
+      "type": "string",
+      "pattern": "^did:",
+      "minLength": 1,
+      "maxLength": 2048,
+      "description": "The DID of the vetter being asked about — the subject of the vetter role credential. The caller usually holds it from an earlier listing, or from a vetting exchange that has since gone quiet."
+    },
+    "ext": {
+      "$ref": "#/$defs/Ext"
+    }
+  },
+  "$defs": {
+    "GrantStatus": {
+      "title": "GrantStatus",
+      "description": "The state of a vetter's grant in this community. The three refusing values are deliberately distinct: `revoked` says the community withdrew a grant it had made, `expired` says one ran out, and `none` says there is nothing to withdraw. An applicant reads those differently, and so does a vetter checking their own standing.",
+      "type": "string",
+      "enum": [
+        "live",
+        "revoked",
+        "expired",
+        "none"
+      ]
+    },
+    "Response": {
+      "$anchor": "response",
+      "title": "VTC Vetting — Show Vetter — response payload",
+      "description": "One vetter's grant status. Carries no profile: what a vetter published for a directory is answered by vtc/vetting/vetters/list, and this task answers a caller who already knows which vetter they mean.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "vetterDid",
+        "status"
+      ],
+      "properties": {
+        "vetterDid": {
+          "type": "string",
+          "pattern": "^did:",
+          "description": "The DID asked about, echoed so a response is self-contained."
+        },
+        "status": {
+          "$ref": "#/$defs/GrantStatus"
+        },
+        "grantId": {
+          "type": "string",
+          "minLength": 1,
+          "maxLength": 512,
+          "description": "The identifier of the grant this status is about. Present for `live`, `revoked` and `expired`; absent for `none`, which is the absence of a grant and so has nothing to identify."
+        },
+        "validUntil": {
+          "type": "string",
+          "format": "date-time",
+          "description": "The grant's `validUntil`. Present for `live` and `expired` — for `expired` it is when it ran out, which tells a caller whether it lapsed long ago or yesterday. Absent for `none`, and for `revoked`, where the revocation and not the expiry is what ended it."
+        },
+        "revokedAt": {
+          "type": "string",
+          "format": "date-time",
+          "description": "When the grant was revoked. Present only for `revoked`. The reason is deliberately not carried: it is the community's internal record, and an applicant needs to know the grant does not hold, not why."
+        },
+        "listed": {
+          "type": "boolean",
+          "description": "Whether this vetter has a profile stored with `listed: true`, and so would appear in vtc/vetting/vetters/list. Present only for `live`. It is what separates the two reasons a live vetter is missing from a listing: unlisted by choice, rather than not a vetter."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "GrantStatus": {
+      "title": "GrantStatus",
+      "description": "The state of a vetter's grant in this community. The three refusing values are deliberately distinct: `revoked` says the community withdrew a grant it had made, `expired` says one ran out, and `none` says there is nothing to withdraw. An applicant reads those differently, and so does a vetter checking their own standing.",
+      "type": "string",
+      "enum": [
+        "live",
+        "revoked",
+        "expired",
+        "none"
+      ]
+    },
+    "Response": {
+      "$anchor": "response",
+      "title": "VTC Vetting — Show Vetter — response payload",
+      "description": "One vetter's grant status. Carries no profile: what a vetter published for a directory is answered by vtc/vetting/vetters/list, and this task answers a caller who already knows which vetter they mean.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "vetterDid",
+        "status"
+      ],
+      "properties": {
+        "vetterDid": {
+          "type": "string",
+          "pattern": "^did:",
+          "description": "The DID asked about, echoed so a response is self-contained."
+        },
+        "status": {
+          "$ref": "#/$defs/GrantStatus"
+        },
+        "grantId": {
+          "type": "string",
+          "minLength": 1,
+          "maxLength": 512,
+          "description": "The identifier of the grant this status is about. Present for `live`, `revoked` and `expired`; absent for `none`, which is the absence of a grant and so has nothing to identify."
+        },
+        "validUntil": {
+          "type": "string",
+          "format": "date-time",
+          "description": "The grant's `validUntil`. Present for `live` and `expired` — for `expired` it is when it ran out, which tells a caller whether it lapsed long ago or yesterday. Absent for `none`, and for `revoked`, where the revocation and not the expiry is what ended it."
+        },
+        "revokedAt": {
+          "type": "string",
+          "format": "date-time",
+          "description": "When the grant was revoked. Present only for `revoked`. The reason is deliberately not carried: it is the community's internal record, and an applicant needs to know the grant does not hold, not why."
+        },
+        "listed": {
+          "type": "boolean",
+          "description": "Whether this vetter has a profile stored with `listed: true`, and so would appear in vtc/vetting/vetters/list. Present only for `live`. It is what separates the two reasons a live vetter is missing from a listing: unlisted by choice, rather than not a vetter."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the request variant, from this specification's
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
+ */
+export const SPEC = {
+  typeUri: TYPE_URI,
+  isBearer: false,
+  isProofRequired: false,
+  isRecipientRequired: true,
+  isIssuedAtRequired: false,
+  payloadSchema: PAYLOAD_SCHEMA,
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export const RESPONSE_SPEC = {
+  typeUri: RESPONSE_TYPE_URI,
+  isBearer: false,
+  isProofRequired: false,
+  isRecipientRequired: true,
+  isIssuedAtRequired: false,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+} as const;