@openvtc/trust-tasks 0.16.9 → 0.16.11

package/CHANGELOG.md

@@ -11,6 +11,226 @@ 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.16.11 — 2026-09-05
+
+
+### Specifications
+
+- **persona**: Attribute.value is OPTIONAL, so the default listing is representable (#367)
+
+The schema required `value` while its own description said the member is
+  absent in two situations. That contradiction made the DEFAULT path of
+  persona/attribute/list unrepresentable: `includeValues` defaults to false
+  precisely so a picker can render the pool without decrypting every fact in it,
+  and a maintainer taking that path had to choose between disclosing every value
+  in bulk and emitting a non-conformant response.
+
+  The same contradiction blocked the other documented case — a credential-backed
+  value that could not be re-derived, which is returned carrying `stale` so the
+  holder learns a claim has stopped being presentable rather than seeing a pool
+  that looks smaller than it is.
+
+  Found by a conformance witness in verifiable-trust-infrastructure while wiring
+  the family: the witness for the default listing would not round-trip. Which is
+  what witnesses are for — the defect was in the schema, not the implementation,
+  and nothing else would have caught it before the first non-disclosing read
+  went out.
+
+  Both bindings regenerated; conformance checks 403 specs against 403 TypeScript
+  and 398 Rust modules.
+
+- **rooms**: The Consent/purpose section six specs shipped without (#365)
+
+The Security & Privacy lint landed 2026-08-26 (#273). These six specs landed
+  between 3 and 5 September, each carrying `Data carried`, `Correlation` and
+  `Retention` but not `Consent/purpose`. That is not the debt the allowlist is
+  for — its own message says it is "only for content predating this lint" — so
+  the fix is to write the sections, not to list the specs.
+
+  Each says what the disclosure is for, what records the basis, and where the
+  purpose stops. What the six have in common is that the interesting part is the
+  limit:
+
+  - `rooms/records/curate` — the `reason` is addressed to the room, not to the
+    record's author, who is neither asked nor notified; and no consent withdrawn
+    here reaches an export taken before the retraction.
+  - `rooms/owner/claim` — the consent authorizing a claim was given in advance by
+    the previous owner, and a nomination with no expiry cannot be withdrawn by an
+    owner who has stopped, which is definitionally what a dormant owner has done.
+    The room's other members are not party to it.
+  - `rooms/owner/transfer` — the outgoing owner's consent is contemporaneous; the
+    incoming owner's is not recorded at all, and the specification defines no
+    member through which they accept or decline a role that carries quota, abuse
+    and lifecycle obligations.
+  - `rooms/keys/commit` — there is no per-commit decision to make. A member who
+    does not apply one has declined nothing; consent operates at the boundaries
+    of membership, not on each epoch inside it.
+  - `rooms/keys/key-package` — minting is not joining, the expiry is a purpose
+    bound rather than housekeeping, and reuse across rooms is a disclosure the
+    party never made and cannot detect.
+  - `rooms/keys/welcome` — consent reaches the member's own key-holding agent and
+    no further, which is why a `private` room's Welcome is not routed through the
+    host: accepting an invitation is not consenting to the host learning you are
+    in the room.
+
+  Prose only. No front matter, schema, or generated code moves.
+
+  Also turns on TT_STRICT_SECURITY_PRIVACY in the CI build. With these six
+  written the non-allowlisted count is zero, so strict mode passes today and
+  fires only on a spec added without the section — the allowlist is closed to new
+  content by definition. It was six specs in three days that made the case: the
+  warning was invisible in a green build, and nothing else would have caught
+  them. Negative-tested by removing one section and confirming the build fails.
+
+## 0.16.10 — 2026-09-05
+
+
+### Added
+
+- **persona**: A holder's own identity, composed once and disclosed under control (#360)
+
+* feat(persona): attribute pool — shared schema and attribute/put
+
+  First slice of the persona family: the holder's own identity attributes,
+  agent-scoped above the context boundary.
+
+  The shared schema carries the family's load-bearing definitions — the three
+  provenance kinds, the four profile-entry forms, the proof-rung ordering, and
+  the two-scope rule that keeps a context-scoped caller from reading the pool.
+
+  attribute/put establishes the pattern: holder-authorized and unscoped,
+  value validated against its declared type, credential-backed provenance
+  resolved at write time so an attribute cannot read back stale forever, and an
+  advisory correlation count returned on the write so a builder can warn while
+  the holder is still composing.
+
+- **rooms/owner**: Transfer and claim, so a room outlives one person (#359)
+
+§10 of the data-rooms design was the last part with no specification.
+  Ownership there is load-bearing for liveness, not just administration: a
+  room's owner is its sole committer, so a room with no reachable owner
+  cannot advance an epoch, cannot be renewed, and lapses to read-only. One
+  person becoming unreachable ends a shared space.
+
+  Two tasks, not one with a flag. They end the same way and differ in
+  everything else - who initiates, what authorizes, and whether the room
+  has to have lapsed. Collapsing them would mean either a transfer that
+  waits for a lapse or a claim that works while the owner is still
+  renewing, and both are wrong.
+
+  There is deliberately no nominate task. A nomination is a credential the
+  room issues and the claimant presents, the same shape as an invitation
+  and for the same reason: a host keeping a roster of successors would hold
+  part of the room's authority structure, and the room could no longer move
+  hosts without rebuilding it. The consequence is that 'no successor' and
+  'the successor has not claimed yet' are the same observation to a host -
+  which is fine, because both resolve identically when retention runs out.
+
+  A claim is an ACT, never an automatic promotion, and that is not
+  ceremony. An automatic one is an ownership change nobody performed: no
+  actor to audit, no moment to point at, and an owner who returns finds the
+  room changed hands with no event to examine.
+
+  Three conditions, all required, each closing a different route to a
+  takeover: a nomination the room itself issued naming this claimant; the
+  room dormant rather than merely lapsed, so the grace window has passed
+  and the owner has had their notice; and the claimant already a member,
+  because a successor who cannot commit inherits a room they cannot renew.
+
+  Renewing cancels a pending claim, and that is the property worth
+  noticing: the defence against a hostile claim is the same act as ordinary
+  use. An owner who was merely away fixes it by doing what they would have
+  done anyway - nothing revoked, no dispute raised.
+
+  Transfer requires the incoming owner to be a member for the same reason.
+  Handing someone a room they cannot renew looks like success and produces
+  a room that lapses on schedule a year later with nobody able to save it.
+
+  Three things the Security sections say plainly. A transfer does NOT
+  remove the outgoing owner - they keep whatever their credentials confer,
+  usually still admin, so handing over and leaving are two more acts. Every
+  credential stays valid because the room's identifier does not change,
+  which is the whole reason a room has an identifier of its own rather than
+  borrowing its owner's. And the host is not an arbiter: it records what an
+  authorized party told it, and ownership of an identifier is settled by
+  whoever controls that identifier, not by a service that stores
+  ciphertext.
+
+
+
+### Documentation
+
+- Base every example on the registered acl/change-role task (#356)
+
+SPEC.md, both READMEs, the loopback example and the framework unit tests
+  all illustrated themselves with `kyc-handoff/1.0`, a slug that has never
+  been registered. Three consequences, in increasing order of cost:
+
+  - `https://trusttasks.org/spec/kyc-handoff/1.0` is a live URL in the
+    Abstract and in five worked examples. It resolves — the registry site
+    serves the SPA for any /spec/ path — and rendered `acl/change-role`,
+    the alphabetically first entry, because SpecPage fell back to
+    `TT_TASKS[0]` for an unresolvable slug. A reader following the URL in
+    §1 got a complete, confident page for a different task.
+  - No example could be checked against anything. The build validates every
+    fenced JSON block against the framework envelope schema; a payload
+    naming a slug with no schema was structurally unverifiable.
+  - The `trust-task-error` extended-code example was non-conforming: it
+    answered an ACL request with a `kyc-handoff:`-namespaced code, which
+    §8.5 forbids in the same breath as it defines namespacing.
+
+  Everything now names `acl/change-role/0.1`, whose payloads validate
+  against its published schema, whose error codes are the two it declares,
+  and whose REQUIRED `proof` the examples honour. Appendix A is reproduced
+  from that registry entry rather than invented. The framework parser tests
+  that used the slug as an arbitrary string now use real ones —
+  `trust-task-discovery` and `trust-task-control` where a single-segment
+  slug is the point.
+
+  SpecPage is strict as a result: an unregistered slug, or a known slug at
+  an unknown version, renders a not-found page offering the versions that
+  do exist, the way BindingSpecPage and CeremonyPage already did. The
+  lookup moved into a hook-free wrapper so a route that stops resolving
+  unmounts the detail view rather than changing a mounted component's hook
+  count.
+
+  SPEC.md is also maintained canonically at trustoverip/dtgwg-trust-tasks-spec;
+  the matching change lands there in parallel.
+
+
+
+### Fixed
+
+- **rooms/owner**: A host cannot see the MLS group, so stop implying it can (#361)
+
+Both tasks required a host to check that a party is a member of the
+  room's group. A host holds no roster and no group state, so neither check
+  was implementable as written. Found while starting the implementation,
+  which is what implementation is for.
+
+  claim now carries a presentation. The host has exactly one membership
+  signal available - the VMC the room itself issued - and the claim payload
+  did not ask for it, so condition 3 was unimplementable and the claimant's
+  own standing went unverified. It is now required, and it is the same
+  presentation every other room task carries.
+
+  The spec is also exact about what that proxy is worth: a party removed
+  from the MLS group while still holding an unexpired VMC would pass. That
+  gap closes by revoking the credential, which is the room's job, not the
+  host's. Better said than implied.
+
+  transfer moves the obligation to the party who can discharge it. The
+  incoming owner is not the one making the request, presents nothing, and
+  may be someone the host has never seen - so 'MUST refuse if not a member'
+  asked a host to judge a third party from no evidence. The requirement is
+  now on the transferring owner, who can see the group; a host that can
+  independently establish non-membership MAY still refuse, and one that
+  cannot MUST NOT invent a check or treat its own ignorance as evidence.
+
+  That last point is the same boundary the rest of the family draws,
+  arriving from an unfamiliar direction: a host verifies what is presented
+  to it, and a claim about a third party is not that.
+
 ## 0.16.9 — 2026-09-04
 
 

package/dist/_shared/components.d.ts

@@ -27,6 +27,14 @@ export type Capability_DeviceV0_1 = "vault-read" | "vault-write" | "proxy-login"
  * Fine-grained capability flag scoped to the device's allowed contexts. See SPEC.md for the full semantics of each. Capability values are additive: a consumer MUST ignore a value it does not recognise rather than reject the binding, and MUST NOT treat an unrecognised value as conferring anything.
  */
 export type Capability_DeviceV0_2 = "vaultRead" | "vaultWrite" | "proxyLogin" | "fillRelease" | "policyAdmin" | "deviceAdmin" | "sign" | "keyMint" | "signTrustTask" | "credentialWrite" | "memoryRead" | "memoryWrite" | "roomPresent" | "roomOpen";
+/**
+ * The vocabulary token naming what a value IS — `name.legal`, `phone.mobile`, `address.postal`, `person.birthDate`. Dotted, most-general segment first, so that a consumer with no knowledge of the specific token can still group by its prefix.
+ *
+ * The token is the maintainer's own; no external vocabulary is primary. External vocabularies (vCard/jCard, OIDC standard claims, schema.org) are mappings applied at PRESENTATION by a renderer, not at rest, so that a query written in any of them can be matched without the store having to live inside any one of them.
+ *
+ * The `x:` prefix is an open extension namespace and is not decoration. The closest prior art — Windows CardSpace's self-issued card — supported exactly fifteen predefined claim types with no extensibility, and that is the specific way it failed the requirement a holder actually has. An `x:` attribute stores, composes, binds and discloses exactly like a known one; it renders generically and matches only an explicit query.
+ */
+export type ClaimType = string;
 /**
  * Discriminator: is this consumer a user-driven Companion or a headless Service?
  */
@@ -65,10 +73,14 @@ export type DigestMultibase = string;
  * Whether the subject is permitted. The ABSENCE of any grant is treated as `deny` (default-deny).
  */
 export type Effect_ConsentV0_1 = "allow" | "deny";
+/**
+ * Optimistic-concurrency precondition. A positive value requires the record's current `version` to equal it exactly; zero means create-only and applies only when no live record exists at the address.
+ */
+export type ExpectedVersion_PersonaV0_1 = number;
 /**
  * Optimistic-concurrency precondition on a write. A positive value requires that the record's current `version` equals it exactly. Zero means "create only" — the write applies only if no LIVE record exists at the address, which is what makes lease acquisition safe: without it two instances can each read "absent", each write, and each believe it won. A tombstone is not a live record, so `expectedVersion: 0` succeeds over one; the created record takes the namespace's next counter value, which is necessarily greater than the tombstone's.
  */
-export type ExpectedVersion = number;
+export type ExpectedVersion_VtaV0_1 = number;
 /**
  * `issued` is outstanding and revocable; `consumed` and `expired` are terminal.
  */
@@ -97,6 +109,88 @@ export type Kind = "dm" | "group" | "channel";
  * Scopes one application's records within a context, so several tools can share a context without colliding — `openvtc`, `cnm`, an agent runtime. The maintainer MUST NOT interpret the value; it is an opaque partition name. Namespaces are first-come and unreserved, so an application SHOULD pick a stable, specific one: a future per-namespace ACL would grant on this exact string, which makes renaming a namespace a migration rather than an edit.
  */
 export type Namespace = string;
+/**
+ * One line of a profile, in exactly one of four forms. Together they are the whole of a profile's flexibility, and each exists for a case the others handle badly.
+ *
+ * `{ref}` — use the pool attribute, live. Editing the pool updates every profile that references it, which is the point.
+ *
+ * `{ref, pinVersion}` — use the value as it was at that version. For a profile that must keep presenting the value a counterparty already verified.
+ *
+ * `{ref, override}` — the same fact, a different value here. ("In the gaming profile my display name is different.")
+ *
+ * `{inline}` — a value that never enters the pool, and so never leaks into another profile.
+ *
+ * Omission is exclusion; there is no removal marker.
+ */
+export type ProfileEntry = {
+    ref: Ulid;
+} | {
+    ref: Ulid;
+    pinVersion: Version_PersonaV0_1;
+} | {
+    ref: Ulid;
+    /**
+     * Replaces the pool attribute's value for this profile only. `type`, `valueType` and `provenance` are inherited from the referenced attribute and MUST NOT be overridden — an override that changed provenance would let a self-asserted value present as attested.
+     */
+    override: {
+        value: unknown;
+        label?: string;
+    };
+} | {
+    inline: {
+        type: ClaimType;
+        valueType: ValueType;
+        value: unknown;
+        label?: string;
+        provenance: Provenance;
+    };
+};
+/**
+ * How strongly a credential-backed claim is hidden when presented, ordered most private first. `predicate` proves a statement over a claim without disclosing the claim. `derived` discloses exactly the claims needed via an unlinkable derived proof, so two presentations cannot be joined. `selectiveDisclosure` discloses exactly the claims needed but carries the issuer's signature unchanged, so two presentations ARE linkable. `whole` discloses the entire credential.
+ *
+ * The distinction between the first two and the last two is of kind, not degree: only `predicate` and `derived` avoid handing two verifiers a join key. A maintainer MUST default to the highest rung the credential's format supports, and MUST NOT silently fall to a lower one — a request that cannot be satisfied at the rung a producer asked for is refused, because a silent privacy downgrade discloses material the holder believed was hidden.
+ */
+export type ProofRung = "predicate" | "derived" | "selectiveDisclosure" | "whole";
+/**
+ * Where a value comes from, and the member that makes this family worth building on a trust stack rather than in an address book. It survives to the verifier, so a recipient can tell — per field — what the holder typed from what an issuer attested.
+ *
+ * `selfAsserted` — the holder supplied it.
+ *
+ * `credentialBacked` — the value is derived from a credential in the vault at `claimPath`. The stored value is a CACHE FOR DISPLAY; the credential is the truth. A maintainer MUST re-derive it on read and MUST fail closed (never presenting a stale value) when the credential has been revoked, has expired, or has been archived or deleted.
+ *
+ * `generated` — the value is minted per verifier at disclosure time and recorded against that verifier, so every relying party receives a different one that routes back to the holder. This is the shape of the most widely adopted consumer privacy feature in this space; a maintainer need not operate a relay to conform, but the shape must exist, because retrofitting per-verifier values into a pool-of-values model is a migration rather than an addition.
+ */
+export type Provenance = {
+    kind: "selfAsserted";
+} | {
+    kind: "credentialBacked";
+    /**
+     * Vault identifier of the backing credential.
+     */
+    credentialId: string;
+    /**
+     * RFC 6901 JSON Pointer to the claim within the credential, e.g. `/credentialSubject/familyName`.
+     */
+    claimPath: string;
+    /**
+     * Issuer of the backing credential. Advisory: a consumer MUST verify the credential rather than trusting this member.
+     */
+    issuerDid?: string;
+    /**
+     * The disclosure rung this claim was, or will be, presented at.
+     */
+    proof?: ProofRung;
+} | {
+    kind: "generated";
+    /**
+     * Names the minting scheme, e.g. `relayEmail`. Maintainer-defined.
+     */
+    generator: string;
+    /**
+     * When true (the default and the only useful setting), a distinct value is minted for each verifier.
+     */
+    perVerifier?: boolean;
+};
 /**
  * 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`.
  */
@@ -167,6 +261,14 @@ export type SiteTarget_VaultV0_1 = WebOrigin_VaultV0_1 | Did_VaultV0_1 | IosApp_
 export type SiteTarget_VaultV0_2 = WebOrigin_VaultV0_2 | Did_VaultV0_2 | IosApp_VaultV0_2 | AndroidApp_VaultV0_2;
 export type SyncEvent_SyncV0_1 = VaultUpsertedEvent_SyncV0_1 | VaultDeletedEvent_SyncV0_1 | AclChangedEvent_SyncV0_1 | PolicyChangedEvent_SyncV0_1;
 export type SyncEvent_SyncV0_2 = VaultUpsertedEvent_SyncV0_2 | VaultDeletedEvent_SyncV0_2 | AclChangedEvent_SyncV0_2 | PolicyChangedEvent_SyncV0_2;
+/**
+ * A ULID in Crockford base32, uppercase. Used for `attributeId` and `profileId`. Chosen over a UUID because the leading 48 bits are a timestamp, so a key-ordered scan of the store is also creation-ordered and a `list` needs no secondary sort. Server-assigned on create; a producer MAY supply one to make a create idempotent, and a maintainer MUST reject a supplied value that already exists rather than silently overwriting.
+ */
+export type Ulid = string;
+/**
+ * The JSON shape of `value`, declared so that a consumer can render and compare without guessing. The maintainer validates that `value` agrees with this member and does nothing further: it does NOT validate a phone number against a phone-number grammar. That is a producer's affordance, and a store that grows opinions about the contents of its records eventually blocks its consumer's release.
+ */
+export type ValueType = "string" | "number" | "boolean" | "date" | "object";
 /**
  * What the policy decided.
  *
@@ -175,10 +277,14 @@ export type SyncEvent_SyncV0_2 = VaultUpsertedEvent_SyncV0_2 | VaultDeletedEvent
  * The four are not reducible to a pending/decided pair. `refer` and `requestMore` are both 'not decided', but they place the next action with different parties: `refer` waits on the community, `requestMore` waits on the applicant. A consumer that cannot tell them apart cannot tell a user whether to wait or to act.
  */
 export type VerdictEffect = "allow" | "deny" | "refer" | "requestMore";
+/**
+ * A value of the store's monotonic write counter. Server-assigned; a producer never chooses one.
+ */
+export type Version_PersonaV0_1 = number;
 /**
  * A value of the namespace's monotonic write counter (see this schema's description). Server-assigned; a producer never chooses one.
  */
-export type Version = number;
+export type Version_VtaV0_1 = number;
 /**
  * A Verifiable Identifier (SPEC §4.8). For a mediator-served account this is the account's controlling DID, carried verbatim and compared by exact string equality. For privacy — and because some mediators key accounts by a one-way hash and never hold the full DID — a stable hash of the DID (e.g. its SHA-256 digest) is an equally valid value here: producer and consumer simply agree on the same opaque identifier and compare by exact string equality. The field carries whichever form the issuing mediator uses.
  */
@@ -353,7 +459,7 @@ export interface AppStateRecord {
     /**
      * The namespace counter value this record's most recent write took. Supply it as `expectedVersion` on the next write to make that write conditional on nothing having changed in between.
      */
-    version: Version;
+    version: Version_VtaV0_1;
     /**
      * The stored JSON, in whatever shape the owning application chose. Any JSON value, including `null`. The maintainer neither validates nor interprets it. Absent when this is a tombstone or a metadata-only view — see this definition's description for why that is not the same as a null value.
      */
@@ -450,6 +556,38 @@ export interface AttachmentRef_VaultV0_3 {
      */
     contentType?: string;
 }
+/**
+ * One atomic fact a holder keeps about themselves. Several attributes MAY share a `type` — three phone numbers, a legal name and a preferred name — which is why `attributeId` is the identity of a fact and `type` is not. The pool is flat and unordered; ordering is a profile's concern.
+ */
+export interface Attribute {
+    attributeId: Ulid;
+    type: ClaimType;
+    valueType: ValueType;
+    /**
+     * The fact itself, agreeing with `valueType`. Encrypted at rest by the maintainer.
+     *
+     * OPTIONAL, and its absence is meaningful in two distinct situations a consumer MUST NOT conflate: the caller asked for a metadata-only view (`list` without `includeValues`, which is the DEFAULT and the common case), or a credential-backed value could not be re-derived. `stale` tells them apart. Requiring this member would make the default listing unrepresentable — a maintainer would have to choose between disclosing every value in bulk and emitting a non-conformant response.
+     */
+    value?: {
+        [k: string]: unknown | undefined;
+    };
+    /**
+     * The holder's own words for this attribute, shown in a picker. Never disclosed to a verifier; it is a note to self.
+     */
+    label?: string;
+    provenance: Provenance;
+    /**
+     * Present and true when a `credentialBacked` value could not be re-derived. `staleReason` says why. A maintainer MUST refuse to disclose a stale attribute.
+     */
+    stale?: boolean;
+    /**
+     * Why re-derivation failed. Present only alongside `stale`.
+     */
+    staleReason?: "revoked" | "expired" | "archived" | "deleted" | "notFound";
+    version: Version_PersonaV0_1;
+    createdAt?: string;
+    updatedAt: string;
+}
 /**
  * One record in the mediator's privileged-change audit log: one change, by one actor, at one time.
  */
@@ -908,6 +1046,46 @@ export interface Service_DeviceV0_2 {
     kind: "service";
     serviceKind: "mediator" | "aiAgent" | "daemon";
 }
+/**
+ * What a peer disclosed, as received. Structurally the same claim set a holder composes and presents — a profile and a contact card are one schema seen from two sides — which is why a maintainer validates both with the same code and a consumer renders both with the same view.
+ */
+export interface ContactDocument {
+    /**
+     * The DID that published the document, as it appeared. Normally a pairwise identifier, so it names the relationship rather than the person.
+     */
+    publisher?: string;
+    /**
+     * The publisher's own monotonic counter, if they supplied one. Advisory: it orders the publisher's revisions relative to each other and MUST NOT be trusted to order them against anything else.
+     */
+    cardVersion?: number;
+    /**
+     * @maxItems 256
+     */
+    claims: {
+        type: ClaimType;
+        valueType: ValueType;
+        value: unknown;
+        /**
+         * As asserted by the publisher. A recipient MUST NOT treat a claimed credentialBacked provenance as verified — it is a statement about what the publisher says backs the claim, and verification is a separate act against the credential itself.
+         */
+        provenance?: Provenance;
+    }[];
+}
+/**
+ * One received version of a contact's document. Revisions exist because an address book that silently replaces a payment address is a phishing surface, and one that says what changed and when is a defence.
+ */
+export interface ContactRevision {
+    /**
+     * Monotonic per contact, assigned by the recipient. Not the publisher's cardVersion — a recipient counts what it received, which is the only sequence it can vouch for.
+     */
+    rev: number;
+    receivedAt: string;
+    /**
+     * When a later revision replaced this one. Null for the current revision.
+     */
+    supersededAt?: string | null;
+    document?: ContactDocument;
+}
 /**
  * Per-context restrictions the VTA enforces. Every member is optional, and **absence means unrestricted, not empty** — a policy that omits `presentableTypes` permits every type, while one that sets it to `[]` permits none. The two are opposite instructions and a consumer MUST NOT collapse them.
  */
@@ -2118,6 +2296,29 @@ export interface PolicyModule {
     updatedAt: string;
     ext?: Ext;
 }
+/**
+ * A named projection over the pool. Agent-scoped, like the pool it draws from. `entries` is ordered and the order is display order.
+ */
+export interface Profile {
+    profileId: Ulid;
+    /**
+     * The holder's name for this profile — "Work", "Gaming". Not disclosed.
+     */
+    name: string;
+    /**
+     * @maxItems 256
+     */
+    entries: ProfileEntry[];
+    /**
+     * Vault identifiers of credentials associated with this profile as INVENTORY, distinct from the evidence relationship a `credentialBacked` attribute expresses. The two answer different questions — what can this persona prove, versus what backs this specific claim — and a consumer MUST NOT read one as the other.
+     *
+     * @maxItems 256
+     */
+    credentialRefs?: string[];
+    version: Version_PersonaV0_1;
+    createdAt?: string;
+    updatedAt: string;
+}
 /**
  * Server-issued options for `navigator.credentials.create({ publicKey: ... })`. Mirrors the WebAuthn Level 2 `PublicKeyCredentialCreationOptions` dictionary; binary fields are base64url-encoded strings (rather than ArrayBuffers) so the value is JSON-safe over the wire.
  */
@@ -3166,7 +3367,7 @@ export interface WriteResult {
     /**
      * The new version, on `written`.
      */
-    version?: Version;
+    version?: Version_VtaV0_1;
     /**
      * On `written`: true when no live record existed at the address beforehand.
      */
@@ -3174,7 +3375,7 @@ export interface WriteResult {
     /**
      * On `conflict`: the version the maintainer actually holds. Absent when the conflict is that no record exists (`expectedVersion` was positive and the address is empty).
      */
-    currentVersion?: Version;
+    currentVersion?: Version_VtaV0_1;
     /**
      * On `conflict`: the value the maintainer actually holds, returned WITH the rejection rather than left for the caller to re-read. A bare rejection has no fixed point under contention — between the rejection and the re-read the record can change again — so returning the winner's view removes the race rather than narrowing it. Absent when `currentDeleted` is true or no record exists.
      */