@openvtc/trust-tasks 0.16.8 → 0.16.10

package/CHANGELOG.md

@@ -11,6 +11,291 @@ 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.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
+
+
+### Added
+
+- **rooms/keys**: How a group reaches a key-holding agent (#355)
+
+rooms/keys/open assumes something nothing specified: that a key-holding
+  agent HAS the room's MLS group. An oracle that opens records cannot open
+  anything until a group arrives, and nothing said how one does. Three
+  tasks, because there are three distinct steps with three distinct
+  authorization stories.
+
+  key-package - the joining side mints. Per room, never reused across
+  rooms: a KeyPackage is a stable public identifier, so the same one
+  offered to two rooms tells anyone who sees both that one party is in
+  both, which is the linkage a private room exists to deny arriving
+  through the door rather than the wall. The mint is not free either - the
+  recipient retains the private half against a Welcome that may never
+  come - so a key-holder should require an invitation and bound how long
+  it keeps an unused one.
+
+  welcome - the owner delivers, and the INVITATION is what makes it
+  acceptable. A Welcome carries a group's secrets; anyone able to reach a
+  key-holder could otherwise push group state into it. Joining a room is
+  already a two-party act and the VIC is already the consent artefact, so
+  this is where that consent stops being ceremonial. A recipient with no
+  matching unconsumed invitation MUST refuse, and MUST consume it on
+  success. Joining twice is refused rather than merged: two group states
+  for one room is a condition nothing downstream can resolve, and choosing
+  wrong returns 'did not open' for a record the member can plainly see.
+
+  commit - the half that is easy to forget and impossible to omit. A
+  Welcome gets an agent in once; commits keep it there, and an agent that
+  misses one is stuck at its last epoch and can open nothing sealed after
+  it - surfacing as 'this record does not open', which reads like
+  corruption rather than a missed message. Strictly in order: a replay is
+  success with the epoch unchanged (a retry that failed would make every
+  unreliable transport a liveness problem), a gap is refused with the
+  recipient's actual epoch so the sender resumes rather than guesses. The
+  epoch is in the payload rather than parsed out of the commit so a
+  recipient can tell replay from gap before doing cryptographic work on a
+  message it may not want.
+
+  Two things stated rather than left to be discovered.
+
+  Fan-out is O(n). MLS's logarithmic property is the SIZE of a commit, not
+  the number of recipients. On open and attributed a host may carry them;
+  on private it must not, and the owner fans out directly - so on that tier
+  membership changes need the owner online. That is a real cost of the
+  private tier and it belongs in the specification.
+
+  Routing a Welcome discloses membership. Whoever carries it learns that
+  this key-holder is joining this room, which is exactly what a private
+  room withholds - so on that tier the host is off the path entirely
+  rather than trusted not to look. Same rule, same reason, as the
+  invitation itself.
+
+  Who may commit is decided inside the group: a recipient verifies against
+  the group state it already holds, never from an access-control list of
+  its own. And none of this is authorization - holding a group's keys lets
+  an agent decrypt; what it may DO comes from the room's authority
+  credentials, checked separately.
+
+- **rooms/records/curate**: A member changes a record's standing (#354)
+
+A data room could be written to and read from, and a member who had put
+  something in it by mistake had no answer. The rooms family had no way to
+  demote, retract, restore or pin a record.
+
+  Separate from rooms/records/put for two reasons, and the second is the
+  load-bearing one.
+
+  A record's standing is not its content. On an attributed or private room
+  a host cannot read what it stores, so 'replace this record with the same
+  content marked deprecated' would make the member re-seal and re-upload a
+  body the host already holds, for a change that says nothing about the
+  body. Curation carries no content in either direction.
+
+  And curate is its own authority action, deliberately not implied by
+  write: deciding what a room's shared knowledge is worth is a different
+  grant from the ability to add to it. A community can hand an agent write
+  - let it record what it learns - without handing it the standing to
+  demote what a person wrote.
+
+  Retraction is a tombstone, not an erasure. A host MUST drop the body and
+  MUST keep the key, version and epoch: dropping the body is what the
+  member asked for, and keeping the rest is what makes incremental sync
+  converge - a caller that never saw the tombstone resurrects the record on
+  its next full rebuild, which is why list returns them. active is refused
+  for a retracted record rather than reporting a success that restored
+  nothing.
+
+  Permanent removal is out of scope on purpose. It breaks convergence for
+  every caller that has not synchronised past the tombstone, so it belongs
+  to a host's retention lifecycle and not to a member's curation verb.
+
+  Curation assigns a new version. A demotion others are expected to
+  converge on is a change like any other, and one that left the version
+  alone would be invisible to every sinceVersion watermark in the room.
+
+  pinned is orthogonal to status - 'what matters here' and 'is this still
+  current' are different questions, and a room may well want its superseded
+  canonical decision kept in view.
+
+  The Security section says plainly that a retraction is not a deletion and
+  that a surface presenting it as erasure is making a promise the protocol
+  does not keep; and that curate is a censorship surface, which is exactly
+  why it should not arrive as a side effect of being able to write.
+
+
+
+### Specifications
+
+- **device**: Register roomPresent and roomOpen capabilities (#351)
+
+The rooms/keys oracle pair (#349) says an implementation checks whatever
+  authorization the principal granted, and leaves the shape of that grant
+  to the implementation. Where it is a device capability, there should be a
+  registered value rather than a private one per implementation - that is
+  what the shared Capability enum is for, and both values are additive, so
+  a consumer that does not recognise one ignores it.
+
+  Two values, not one. Producing a presentation and decrypting a record are
+  different powers: an agent that indexes a room should not thereby be able
+  to read it.
+
+  Both are separate from sign. An agent that may ask for a scoped,
+  audience-bound presentation is not thereby an agent that may sign
+  anything at all with its principal's key - and gating either task on the
+  generic signing oracle would grant strictly more than it needs, which is
+  the opposite of what an oracle is for.
+
+  Each spec's Consent/purpose section now names its value, since that is
+  where an implementer reading the task will look.
+
 ## 0.16.8
 
 ### Added

package/dist/_shared/components.d.ts

@@ -22,11 +22,19 @@ export type AuditAction = "setAcl" | "accessListAdd" | "accessListRemove" | "acc
 /**
  * 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_1 = "vault-read" | "vault-write" | "proxy-login" | "fill-release" | "policy-admin" | "device-admin" | "sign" | "key-mint" | "sign-trust-task" | "credential-write" | "memory-read" | "memory-write";
+export type Capability_DeviceV0_1 = "vault-read" | "vault-write" | "proxy-login" | "fill-release" | "policy-admin" | "device-admin" | "sign" | "key-mint" | "sign-trust-task" | "credential-write" | "memory-read" | "memory-write" | "room-present" | "room-open";
 /**
  * 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";
+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,36 @@ 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. Absent when the caller asked for a metadata-only view, and absent when a credential-backed value could not be re-derived — a consumer MUST NOT conflate the two and MUST read `stale` to tell them apart.
+     */
+    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 +1044,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 +2294,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 +3365,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 +3373,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.
      */