@openvtc/trust-tasks 0.28.24 → 0.28.26

package/CHANGELOG.md

@@ -11,6 +11,113 @@ The package versions over **its own API** — what a consumer compiles against
 not over `SPEC.md`. Below 1.0 a breaking change bumps the leading non-zero
 component.
 
+## 0.28.26 — 2026-11-10
+
+
+### Added
+
+- **acl**: Purpose of use on grants and on memory reads (AclEntry 0.3; vta/memory put/delete/list 0.3, get 0.2) (#1074)
+
+* feat(acl): purpose of use on grants and on memory reads (AclEntry 0.3; vta/memory put/delete/list 0.3, get 0.2)
+
+  An access-control entry says who may do what, where and until when, but not
+  what for. An agent granted a read of its principal's memory can use the content
+  for anything, and nothing records the use it intended. The VTI specification
+  now requires the purpose (VTI-ACL-100 – 110, trustoverip/dtgwg-vti-spec#115);
+  these are the wire shapes.
+
+  acl/_shared/0.3 — AclEntry 0.3 adds one REQUIRED axis, `purposes`:
+  `{"scope": "any"}` or `{"scope": "listed", "purposes": [...]}` with at least
+  one `Purpose` — a lowerCamelCase name registered in the VTI purpose registry
+  (personalisation, taskExecution, analytics, modelTraining) or an absolute IRI
+  such as a DPV purpose. `any` never grants `modelTraining`. Delegated purposes
+  are a subset of the granter's. CONVENTIONS.md §8a maps a 0.2 entry onto 0.3
+  (`any`, the authority it already held, now stated) and §12 states the rules.
+
+  acl tasks on AclEntry 0.3: grant/0.3, update/0.3, show/0.3, revoke/0.3,
+  change-role/0.3, list/0.4. New errors on grant and update: `purposeOutsideDelegator`
+  (purposes wider than the granter's) and `purposeRefused` (policy will not grant
+  a purpose, refused by name, never dropped). update/0.3 replaces `purposes`
+  wholesale; narrowing it is an audited privilege reduction. `purposes` is never
+  redacted by show or list. No `extends`: a REQUIRED member on the entry cannot
+  be added to a version a 0.2 consumer still reads.
+
+  vta/memory put/0.3, delete/0.3, list/0.3, get/0.2 (each `extends` its
+  predecessor) add an optional `purpose` (`MemoryPurpose`, new in
+  vta/_shared/0.1/memory-record, a reference to acl's `Purpose`) and a
+  `purposeNotGranted` error that discloses nothing and is distinct from
+  `contextForbidden`. A recall, and a listing with values, is purpose-bound:
+  refused for a purpose the entry does not grant, or for none under an entry
+  listing several, and audited with its purpose either way. A write is not
+  purpose-bound, but a conflict that returns `currentValue` is: the value is
+  withheld unless the request's purpose is granted.
+
+  Data rooms (a room authority credential's `purposes`, VTI-ACL-110) are a
+  follow-up.
+
+  Samples in other specs that named the superseded acl versions now name the new
+  ones, with `purposes` on every embedded entry; prose links were moved by
+  `npm run fix-stale-references`.
+
+
+
+### Fixed
+
+- **mux/grant**: Unknown-key rule fails closed on direct authentication; no exemption for a grant without recorded keys (#1075)
+
+A grant that recorded no key-agreement keys exempted every grant on its DID from the DIDComm direct-authentication rule. A grant is now refused (didUnresolvable) when its keys cannot be read, an empty set means the DID listed none, and the rule is applied before a direct authentication succeeds, refusing it when it cannot be applied.
+
+- **messaging/mux**: Compare a direct authentication with keys of its own relationship; send grantsExpiring for every unrenewed grant (#1072)
+
+
+### Specifications
+
+- **rooms**: Purpose of use on room reads and authority credentials (VTI-ACL-102, -110) (#1076)
+
+* spec(rooms): purpose of use on room reads and authority credentials (VTI-ACL-102, -110)
+
+  Room content a key holder releases to its caller is purpose-bound, as agent
+  memory is (vta/memory/get 0.2), and a room's authority credential may state
+  the purposes it grants.
+
+  - rooms/keys/open 0.3, rooms/keys/read 0.3: optional `purpose`; refused with
+    `purposeNotGranted` where the caller's entry, or the principal's authority
+    over the room, does not grant it. read passes it to the host.
+  - rooms/keys/file-key 0.3: the same as `purposeOfUse` (`purpose` already
+    says seal or open), bound only on `open`.
+  - rooms/records/get 0.4: the host holds a read to the purposes the presented
+    chain states; a chain stating none grants `any`.
+  - rooms/owner/issue-authority 0.3: optional `purposes` (AclEntry 0.3's
+    PurposeScope), stated in the credential; absent grants `any`.
+  - rooms/_shared 0.2: `RecordPurpose`, and AuthorityPresentation's rule for
+    purposes along a chain: a link stating none takes its parent's, a link
+    stating wider is refused whole (VTI-ACL-107).
+
+  Each new version `extends` its predecessor.
+
+## 0.28.25 — 2026-11-09
+
+
+### Documentation
+
+- **vta/dids**: Did:webs is eligible with the key-role designation extension (#1070)
+
+* docs(vta/dids): did:webs is eligible with the key-role designation extension
+
+  The did:webs method profile declared the method ineligible as published
+  (criteria 4 and 6: no controller-chosen relationships, no room for
+  keyRoles or revoked) and recommended an extension A: role keys anchored in
+  the KEL, rendered into their roles' relationships with keyRoles and
+  revoked, key-state keys in no relationship. affinidi-did-webs 0.9.1
+  implements it as a key-role designation (an anchored ACDC), proposed to
+  the did:webs specification.
+
+  The profile now states the status as eligible with that extension and
+  ineligible without it, and renders §4 as built: the record's schema and
+  attributes, one standing record, accumulated revocations, the document's
+  members, the fail-closed checks. It states the interop caveat: a resolver
+  without the extension refuses the published did.json.
+
 ## 0.28.24 — 2026-11-09
 
 

package/dist/_extends.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"_extends.d.ts","sourceRoot":"","sources":["../src/_extends.ts"],"names":[],"mappings":"AAAA,wEAAwE;AAExE;;;;;GAKG;AACH,eAAO,MAAM,mBAAmB,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAmB/D,CAAC"}
+{"version":3,"file":"_extends.d.ts","sourceRoot":"","sources":["../src/_extends.ts"],"names":[],"mappings":"AAAA,wEAAwE;AAExE;;;;;GAKG;AACH,eAAO,MAAM,mBAAmB,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CA4B/D,CAAC"}

package/dist/_extends.js

@@ -10,14 +10,23 @@ export const EXTENDS_BY_TYPE_URI = Object.freeze({
     "https://trusttasks.org/spec/rooms/keys/act/0.11": "0.10",
     "https://trusttasks.org/spec/rooms/keys/act/0.12": "0.11",
     "https://trusttasks.org/spec/rooms/keys/act/0.9": "0.8",
+    "https://trusttasks.org/spec/rooms/keys/file-key/0.3": "0.2",
+    "https://trusttasks.org/spec/rooms/keys/open/0.3": "0.2",
+    "https://trusttasks.org/spec/rooms/keys/read/0.3": "0.2",
     "https://trusttasks.org/spec/rooms/keys/seal/0.3": "0.2",
+    "https://trusttasks.org/spec/rooms/owner/issue-authority/0.3": "0.2",
     "https://trusttasks.org/spec/rooms/records/get/0.3": "0.2",
+    "https://trusttasks.org/spec/rooms/records/get/0.4": "0.3",
     "https://trusttasks.org/spec/rooms/records/put/0.4": "0.3",
     "https://trusttasks.org/spec/rooms/records/put/0.5": "0.4",
     "https://trusttasks.org/spec/vta/did-templates/create/3.2": "3.1",
     "https://trusttasks.org/spec/vta/did-templates/get/3.2": "3.1",
     "https://trusttasks.org/spec/vta/did-templates/list/3.2": "3.1",
     "https://trusttasks.org/spec/vta/did-templates/update/3.2": "3.1",
+    "https://trusttasks.org/spec/vta/memory/delete/0.3": "0.2",
+    "https://trusttasks.org/spec/vta/memory/get/0.2": "0.1",
+    "https://trusttasks.org/spec/vta/memory/list/0.3": "0.2",
+    "https://trusttasks.org/spec/vta/memory/put/0.3": "0.2",
     "https://trusttasks.org/spec/vta/webvh/dids/update/1.1": "1.0",
     "https://trusttasks.org/spec/vtc/elections/list/0.4": "0.3",
     "https://trusttasks.org/spec/vtc/elections/list/0.5": "0.4",

package/dist/_extends.js.map

@@ -1 +1 @@
-{"version":3,"file":"_extends.js","sourceRoot":"","sources":["../src/_extends.ts"],"names":[],"mappings":"AAAA,wEAAwE;AAExE;;;;;GAKG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAqC,MAAM,CAAC,MAAM,CAAC;IACjF,iDAAiD,EAAE,KAAK;IACxD,iDAAiD,EAAE,MAAM;IACzD,iDAAiD,EAAE,MAAM;IACzD,gDAAgD,EAAE,KAAK;IACvD,iDAAiD,EAAE,KAAK;IACxD,mDAAmD,EAAE,KAAK;IAC1D,mDAAmD,EAAE,KAAK;IAC1D,mDAAmD,EAAE,KAAK;IAC1D,0DAA0D,EAAE,KAAK;IACjE,uDAAuD,EAAE,KAAK;IAC9D,wDAAwD,EAAE,KAAK;IAC/D,0DAA0D,EAAE,KAAK;IACjE,uDAAuD,EAAE,KAAK;IAC9D,oDAAoD,EAAE,KAAK;IAC3D,oDAAoD,EAAE,KAAK;IAC3D,oDAAoD,EAAE,KAAK;IAC3D,oDAAoD,EAAE,KAAK;IAC3D,6DAA6D,EAAE,KAAK;CACrE,CAAC,CAAC"}
+{"version":3,"file":"_extends.js","sourceRoot":"","sources":["../src/_extends.ts"],"names":[],"mappings":"AAAA,wEAAwE;AAExE;;;;;GAKG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAqC,MAAM,CAAC,MAAM,CAAC;IACjF,iDAAiD,EAAE,KAAK;IACxD,iDAAiD,EAAE,MAAM;IACzD,iDAAiD,EAAE,MAAM;IACzD,gDAAgD,EAAE,KAAK;IACvD,qDAAqD,EAAE,KAAK;IAC5D,iDAAiD,EAAE,KAAK;IACxD,iDAAiD,EAAE,KAAK;IACxD,iDAAiD,EAAE,KAAK;IACxD,6DAA6D,EAAE,KAAK;IACpE,mDAAmD,EAAE,KAAK;IAC1D,mDAAmD,EAAE,KAAK;IAC1D,mDAAmD,EAAE,KAAK;IAC1D,mDAAmD,EAAE,KAAK;IAC1D,0DAA0D,EAAE,KAAK;IACjE,uDAAuD,EAAE,KAAK;IAC9D,wDAAwD,EAAE,KAAK;IAC/D,0DAA0D,EAAE,KAAK;IACjE,mDAAmD,EAAE,KAAK;IAC1D,gDAAgD,EAAE,KAAK;IACvD,iDAAiD,EAAE,KAAK;IACxD,gDAAgD,EAAE,KAAK;IACvD,uDAAuD,EAAE,KAAK;IAC9D,oDAAoD,EAAE,KAAK;IAC3D,oDAAoD,EAAE,KAAK;IAC3D,oDAAoD,EAAE,KAAK;IAC3D,oDAAoD,EAAE,KAAK;IAC3D,6DAA6D,EAAE,KAAK;CACrE,CAAC,CAAC"}

package/dist/_shared/components.d.ts

@@ -1135,6 +1135,10 @@ export type MemoryExpectedVersion = number;
  * Agent-chosen identifier for an item within a context. Opaque to the maintainer: it MUST NOT be parsed, normalized, or case-folded, and prefix matching in `vta/memory/list` is a byte-prefix comparison over the UTF-8 encoding. Agents SHOULD use `/`-delimited hierarchical keys (`contact/billing`, `preference/timezone`) so that `prefix` can address a family of items, but the delimiter is a convention between an agent and itself. A key is content as well as an address: a key naming a person, a condition or a dispute discloses something to anyone who can list the context, even without its value.
  */
 export type MemoryKey = string;
+/**
+ * The one purpose for which the caller will use the memory content a request discloses (VTI-ACL-103): a name registered in the VTI specification's purpose registry (`personalisation`, `taskExecution`, `analytics`, `modelTraining`) or an absolute IRI. The VTA grants it only if the caller's ACL entry does — `any` grants every purpose but `modelTraining` — refuses it otherwise (`purposeNotGranted`), and records it in the audit record of the read. Optional where the entry lists exactly one purpose (that one applies) or states `any` (the read is recorded as for no stated purpose).
+ */
+export type MemoryPurpose = Purpose_AclV0_3;
 /**
  * The remembered text: a fact, a summary, a preference. Opaque to the maintainer, which stores it as given and never interprets, rewrites or summarises it. The maintainer enforces a documented per-item cap on its size (see `vta/memory/put`).
  */
@@ -1645,6 +1649,18 @@ export type ProviderObjectPrefix = string;
  * What the request is for. A CLOSED list: each purpose has a fixed row in CONVENTIONS.md §3 stating what is revealed at each step, what the grant contains, what redeem returns and the window lengths. Version 0.1 defines `login` only. `stepUp` and `deviceEnrol` are reserved names; adding one is a new version of this component and of every task that references it, never an in-place edit.
  */
 export type Purpose = "login";
+/**
+ * An explicit purpose scope. Exactly one of two shapes, discriminated by `scope`: `any`, or `listed` with a NON-EMPTY list of purposes. The empty list is invalid, not a third shape.
+ */
+export type PurposeScope = PurposeScopeAny | PurposeScopeListed;
+/**
+ * What content is used for: a lowerCamelCase name registered in the VTI specification's purpose registry (Appendix H) — `personalisation`, `taskExecution`, `analytics`, `modelTraining` at the time of writing — or an absolute IRI naming a purpose defined elsewhere, such as a purpose of the W3C Data Privacy Vocabulary (`https://w3id.org/dpv#ServicePersonalisation`). Compared by exact string equality: a consumer MUST NOT treat a purpose it does not recognise as equal to any other, and grants only a request naming exactly a listed purpose (VTI-ACL-109). A registered name is never an IRI, because it contains no `:`.
+ */
+export type Purpose_AclV0_3 = Purpose_AclV0_31 & Purpose_AclV0_32;
+export type Purpose_AclV0_31 = {
+    [k: string]: unknown | undefined;
+};
+export type Purpose_AclV0_32 = string;
 /**
  * A device's platform push channel — the body the device registers with its push GATEWAY (push wake-up binding, https://trusttasks.org/binding/push/0.1; modeled on Aries RFC 0699/0734). The gateway holds this token and returns an opaque WakeHandle in exchange; the token is held by the gateway ONLY, never by the mediator or the maintainer/VTA. The gateway uses it to send a contentless wake-up when an authorized trigger asks — the push payload never carries Trust Task content. Tagged union over the discriminator `platform`.
  */
@@ -1730,6 +1746,10 @@ export type RecordId_VtcNotificationsV0_1 = string;
  * What a reader shows a record as. Defined values: `note` — something kept in the room's library, titled or not, its `body` markdown; `message` — a turn in the room's conversation, its words in `body` as plain text; `reaction` — a short response to another record, its value in `body` (`SealedRecordBody`, *Reactions*). An open set, not an enumeration, so a new kind needs no new version of any schema: a reader MUST present a record whose kind it does not know as a note, and MUST NOT refuse a record for its kind. Absent means `note`, though a reader that keeps a conversation apart MAY show an untitled record without a kind as a message (*Untitled records*). A new version of a record MUST keep its kind. lowerCamelCase, at most 64 characters.
  */
 export type RecordKind = string;
+/**
+ * The one purpose for which a caller will use room content a request discloses (VTI-ACL-103): a name registered in the VTI specification's purpose registry (`personalisation`, `taskExecution`, `analytics`, `modelTraining`) or an absolute IRI. Granted only as the caller's authority grants it — `any` grants every purpose but `modelTraining` — refused otherwise (`purposeNotGranted`), and recorded with the read. Distinct from `PermittedUse`, which is what a record's author permits and is a statement, not a grant.
+ */
+export type RecordPurpose = Purpose_AclV0_3;
 /**
  * The path from one record's leaf to the room's `DataCommitment` — a Merkle inclusion proof, in the vocabulary this work already uses for it.
  *
@@ -4889,6 +4909,84 @@ export interface AclEntry_AclV0_2 {
      */
     ext?: Ext;
 }
+/**
+ * One access-control entry: who the grant is for (`subject`), the ceiling it is held under (`role`), where the subject may act (`act`) and approve (`approve`), and which capabilities it may exercise (`capabilities`) and approve (`approveCapabilities`).
+ *
+ * The act axis and the approve axis are independent and a consumer MUST resolve them separately: `act` + `capabilities` (+ `keys`) answer "may this subject do X"; `approve` + `approveCapabilities` answer "may this subject ratify someone else doing X". Neither implies the other. An entry with `act: {scope: none}` and an approve scope other than none is a least-privilege approver — able to satisfy an approval and unable to initiate any change.
+ */
+export interface AclEntry_AclV0_3 {
+    /**
+     * VID of the party in the ACL. Compared by exact string equality (SPEC.md §4.8); producers SHOULD emit canonical form.
+     */
+    subject: string;
+    /**
+     * Opaque role identifier interpreted by the ACL maintainer. A role is a CEILING, never a grant: it bounds the capabilities the entry may hold and never adds to them. A consumer that does not recognise the role MUST treat the entry as conferring no authority and MUST NOT fall back to a default role. Act scope and role are independent members; a consumer MUST NOT compute either from the other.
+     */
+    role: string;
+    /**
+     * REQUIRED explicit act scope: where this subject may make a change itself. Exactly one of `{"scope": "all"}` (unrestricted — every context the maintainer has), `{"scope": "none"}` (may act nowhere), or `{"scope": "contexts", "contexts": [...]}` with at least one context path (the named contexts and, where the maintainer's contexts are hierarchical, their descendants). There is no default and no implicit form: an entry without `act`, or with an empty `contexts` list, is malformed and MUST be refused, never read as `all` and never read as `none`. A maintainer that has no contexts (for example a community node that narrows authority with resource qualifiers instead) states `all` or `none` only. Replaces 0.1's `scopes`.
+     */
+    act: AuthorityScope;
+    /**
+     * OPTIONAL approve scope: where this subject may ratify a change made by someone else (a step-up ratification, a consent decision, an N-of-M approval). Same three shapes as `act`, resolved independently of it. ABSENT MEANS NONE — the subject may ratify nothing — so a consumer that has not implemented the member confers less than the producer intended, never more. A producer SHOULD state `{"scope": "none"}` explicitly rather than rely on omission. A subject MUST NOT confer approve authority wider than the approve authority it holds itself (see acl/grant `approveWiderThanGranter`). Replaces 0.1's `approve {all, scopes}`.
+     */
+    approve?: AuthorityScope;
+    /**
+     * REQUIRED explicit capability scope: which capabilities this entry holds. Exactly one of `{"scope": "ceiling"}` (the role's full ceiling, unnarrowed), `{"scope": "none"}` (no capabilities), or `{"scope": "listed", "grants": [...]}` with at least one CapabilityGrant. For `listed`, the EFFECTIVE set is (the role's ceiling ∩ the non-additive grants) ∪ the additive grants; it can only narrow the ceiling, except through an explicit additive grant, which only an unrestricted granter may make. There is no implicit form: an entry without `capabilities`, or with an empty `grants` list, is malformed and MUST be refused. A non-additive grant outside the role's ceiling is refused when written, never accepted with the capability silently dropped; a capability the consumer does not recognise is never treated as granted. Producers SHOULD NOT list the same (capability, resource) pair twice; a consumer MAY refuse a list that does.
+     */
+    capabilities: CapabilityScope;
+    /**
+     * OPTIONAL explicit approvable-capability scope: which capabilities this subject may APPROVE an action needing — independent of what it may do itself, so an approver can ratify a capability it does not hold (the least-privilege approver). One of `{"scope": "ceiling"}` (the role's full approve ceiling; at a maintainer whose roles define no capability-level approve ceiling, any action within `approve`), `{"scope": "none"}`, or `{"scope": "listed", "grants": [...]}` with at least one CapabilityRef (intersected with the role's approve ceiling where one is defined). ABSENT MEANS NONE: the subject may approve no capability, because absence derives no authority. Bounded by `approve`: where `approve` is absent or `{"scope": "none"}` this member confers nothing whatever it states. A subject MUST NOT confer approvable capabilities it cannot itself approve.
+     */
+    approveCapabilities?: ApproveCapabilityScope;
+    /**
+     * VID of the granter whose authority this entry was delegated from and is bounded by. The entry MUST NOT hold authority the granter did not hold when it was written, and MUST NOT retain authority the granter has since lost, so a maintainer re-evaluates it when the granter's own entry narrows or is removed. Distinct from `createdBy`, which records who wrote the entry: the two differ where an entry is written on a granter's behalf (for example after an N-of-M approval, or by an offline operator). Set by the maintainer from the granter it authorized; absent on an entry that derives from no granter's authority (the first administrator, an operator-written recovery entry).
+     */
+    delegatedBy?: string;
+    /**
+     * REQUIRED explicit key scope: which keys this subject may invoke the maintainer's signing oracle on. Exactly one of `{"scope": "all"}` (every key the entry's act scope reaches), `{"scope": "none"}` (no keys), or `{"scope": "listed", "keys": [...]}` with at least one key identifier. INTERSECTS WITH `act` — it can only narrow, never widen: a listed key that lies outside the entry's act scope remains unreachable, exactly as if it were not listed. There is no implicit form: an entry without `keys`, or with an empty `keys` list, is malformed and MUST be refused. A maintainer that operates no signing oracle states `{"scope": "none"}`. Replaces 0.1's `allowedKeys`, whose absence meant every key.
+     */
+    keys: KeyScope;
+    /**
+     * REQUIRED explicit purpose scope: what this subject may use content it reads for — the purpose a request for a purpose-bound operation (a read of content held for the principal, or a refusal that carries such content) names, and the maintainer records in that operation's audit record. Exactly one of `{"scope": "any"}` (any purpose EXCEPT `modelTraining`) or `{"scope": "listed", "purposes": [...]}` with at least one Purpose. There is no implicit form: an entry without `purposes`, or with an empty list, is malformed and MUST be refused, never read as `any`. A maintainer that adopts this version writes `any` on every entry that predates it before serving a purpose-bound operation under it (VTI-ACL-101). Delegated purposes are a subset of the granter's: a granter stating `any` MAY delegate a list; a granter stating a list MUST NOT delegate `any`, and no granter delegates `modelTraining` unless its own entry names it (acl/grant `purposeOutsideDelegator`). A maintainer MAY refuse by policy to grant a purpose, naming it, when the entry is written (acl/grant `purposeRefused`), never by writing the entry without it. A purpose is a declaration, not a proof: the maintainer cannot see what the subject does with content, and holds it to what it declared.
+     */
+    purposes: PurposeScope;
+    /**
+     * Optional human-readable label. Confers nothing.
+     */
+    label?: string;
+    createdAt?: string;
+    /**
+     * VID of the party that originally wrote this entry.
+     */
+    createdBy?: string;
+    updatedAt?: string;
+    /**
+     * VID of the party that last modified this entry.
+     */
+    updatedBy?: string;
+    /**
+     * Optional time after which the entry confers no authority. Evaluated at every authorization decision, not only when a session is established.
+     */
+    expiresAt?: string;
+    /**
+     * Per-entry authentication step-up configuration, consumed by the ACL maintainer when it gates an operation behind a step-up (see auth/step-up/policy). ADDITIVE-ONLY: a per-entry setting MAY raise the assurance required of this subject above the maintainer's system-wide floor, but MUST NOT lower it. The maintainer resolves the effective requirement as the strictest of (system floor, this entry). Carried forward from 0.1 unchanged.
+     */
+    stepUp?: {
+        /**
+         * VID authorized to ratify step-up for this subject — the `recipient` the maintainer addresses an auth/step-up/approve-request to (e.g. the holder's mobile authenticator or browser companion). Absent → the subject is its own approver (mode `self`) when it holds a usable authenticator; if neither an `approver` nor a self authenticator exists, no step-up method is available for this subject and the maintainer's fail-closed rule applies.
+         */
+        approver?: string;
+        /**
+         * Minimum step-up mode this subject MUST satisfy for gated operations, raising the system floor. `self` = the subject re-authenticates its own session; `delegated` = a separate `approver` MUST ratify. Omitted → the system floor applies unchanged. A value weaker than the resolved floor is ignored (additive-only).
+         */
+        require?: "self" | "delegated";
+    };
+    /**
+     * Ecosystem-defined extension members per SPEC.md §4.5.1. Reverse-DNS-namespaced; consumers MUST ignore unrecognized namespaces. An extension member MUST NOT be interpreted as conferring authority.
+     */
+    ext?: Ext;
+}
 /**
  * One parked administrative operation, as the caller is entitled to see it. The same action reads differently to different callers only in `challenge` and `callerRole`, which are per-caller.
  */
@@ -12620,6 +12718,25 @@ export interface PurgeProgress {
      */
     lastError?: string;
 }
+/**
+ * Any purpose except `modelTraining` (training, fine-tuning or evaluating a machine-learning model on the content), which `any` never grants (VTI-ACL-105).
+ */
+export interface PurposeScopeAny {
+    scope: "any";
+}
+/**
+ * Exactly the listed purposes. A request naming any other purpose is refused.
+ */
+export interface PurposeScopeListed {
+    scope: "listed";
+    /**
+     * Non-empty set of purposes. An empty array is invalid (it is not `any`).
+     *
+     * @minItems 1
+     * @maxItems 32
+     */
+    purposes: [Purpose_AclV0_3, ...Purpose_AclV0_3[]];
+}
 export interface Apns {
     platform: "apns";
     /**