@openvtc/trust-tasks 0.26.0 → 0.26.2

package/CHANGELOG.md

@@ -11,6 +11,176 @@ 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.26.2 — 2026-10-14
+
+
+### Added
+
+- **vtc**: Community-owned rooms and member offers — vtc/rooms/community/* and vtc/rooms/offers/* (#768)
+
+A community hosts rooms its members own, and can now own rooms itself — the
+  board's papers, a working group's drafts, a members' library — run from its
+  console. Design: verifiable-trust-infrastructure docs/05-design-notes/
+  data-rooms-files.md §8.4.
+
+  The community is the owner, and its own VTA is the key holder: the VTA mints
+  the room's DID, signs its credentials and holds the community's place in a
+  sealed room's group, through the same rooms/owner/* and rooms/keys/* tasks any
+  owner's key holder serves. The community holds no room key and no group
+  secret.
+
+  Administrators, holding the new vtc.rooms.manage (the owner's authority,
+  distinct from hosting's vtc.rooms.admin):
+  - vtc/rooms/community/create — the VTA mints, founds the group, issues the
+    community's own admin authority; the room is stored only after every
+    remote step, so a failure leaves no room behind.
+  - vtc/rooms/community/{list,get} — the owner's view, with counts and when the
+    community's own authority lapses.
+  - vtc/rooms/community/members/{add,remove,list} — add has the VTA issue the
+    invitation, membership and authority credentials (never admin) and keeps
+    them as an offer; remove advances a sealed room's epoch through the owner's
+    group removal and says what removal does not do (no recall; an authority
+    credential is honoured until it expires, so open rooms want short expiries).
+    members/list is paged and separate from get, because a community library
+    can admit the whole community.
+
+  Members, on their own DID (pull-shaped admission: a member's VTA has no
+  inbound address):
+  - vtc/rooms/offers/list — the caller's offers and the credentials to store with
+    their own key holder; never anyone else's.
+  - vtc/rooms/offers/accept — on a sealed tier, a KeyPackage in and the Welcome
+    out, after the VTA adds the member. A repeat with the same KeyPackage gets the
+    same Welcome; an unknown outcome is admissionPending, retried safely because
+    the VTA settles a pending admission first.
+
+  Only active members of the community are admitted to its rooms. Step-up and
+  consent are described as the intended model, not declared (SPEC §7.3 item 13).
+  The owner's record of whom it admitted lives apart from anything the host path
+  reads, so invariant I5 and portability hold.
+
+  New shared schema vtc/_shared/0.1/community-room.schema.json. Additive for the
+  generated types: new modules only.
+
+
+
+### Specifications
+
+- **rooms,vtc**: Rooms/owner/group/remove, and a `rooms` topic on the console's live events (vtc/admin/events 0.2) (#767)
+
+rooms/owner/group/remove/0.1 — the last of the owner's group tasks
+  (data-rooms-files.md §11). Removal is an epoch advance and nothing else is:
+  the key holder drops the member's leaf and advances the room at its host
+  with the link and commit, under the caller's `admin` authority. Same
+  remote-first rules as group/add as corrected in #766: the advanced state is
+  kept durably before the host is contacted, applied only once the host
+  accepts, discarded only on a refusal, kept on an unknown outcome and settled
+  by the next request through rooms/info. At most one pending advance per room,
+  admission or removal. Refuses `ownLeaf` (an owner leaving hands the room on
+  with rooms/owner/transfer). States what removal does not do: no recall of
+  what was read, and the authority credential is a separate thing.
+
+  vtc/admin/events {_shared,subscribe,event} 0.2 — the topic set is closed per
+  version ("a topic not listed here is a new MINOR version of this
+  component"), so the `rooms` topic is a new version rather than an `ext`
+  member. `rooms` prompts vtc/rooms/list, vtc/rooms/usage and
+  vtc/storage/configs/list, goes to holders of vtc.rooms.admin, carries no
+  count, and is hinted when a room is registered or removed or changes
+  lifecycle state, when a room's usage or a storage config's held bytes
+  crosses 80, 95 or 100 percent of a limit or capacity in either direction,
+  and when a storage config is created, changed or changes state — naming
+  none of them (data-rooms-files.md §6.3 alerts). subscribe 0.2 allows up to
+  seven topics. 0.1 is unchanged; a community serving both answers each at its
+  own version.
+
+  Additive for the generated types: new modules; the TypeScript 0.1 modules
+  keep exporting `Topic` (the generator now disambiguates the two shared
+  definitions internally).
+
+- **rooms**: Group/add keeps a pending admission on an unknown outcome; details schemas for group codes (#766)
+
+Corrections to rooms/owner/group/{create,add}/0.1 (drafts, #763), found
+  implementing them in the VTA:
+
+  - add, item 5: discard the pending admission only on a refusal. An
+    unreachable or silent host is an unknown outcome — it may have accepted —
+    and discarding then would leave the owner an epoch behind their own room.
+    The pending admission is kept for item 6; hostUnreachable's meaning says so
+    instead of "nothing was changed".
+  - add, items 2-3: what is kept is the advanced group state with the link,
+    commit and Welcome, beside the group the recipient holds, since a
+    committer cannot process its own commit later.
+  - add, item 6: the host's epoch is read with rooms/info under the caller's
+    read authority, from the host the admission was sent to; a host at neither
+    epoch has moved on, so discard and refuse epochConflict.
+  - detailsSchema for create's alreadyExists (epoch) and add's epochConflict
+    (hostEpoch), which the text already promised.
+  - create, item 1: the gates on naming the key are issue-membership's, but
+    nothing is signed, so a signing quota is not consumed or consulted.
+
+- **rooms**: Rooms/owner/group/{create,add} — the owner's agent founds and grows a sealed room's group; register signs as the owner (#763)
+
+* spec(rooms): rooms/owner/group/{create,add} — the owner's agent founds and grows a sealed room's group; register signs as the owner
+
+  A sealed room (`attributed`, `private`) cannot be written to until its MLS
+  group exists, and every member reaches the group by a Welcome — except the
+  owner, whom nobody can welcome. The member half is specified
+  (`rooms/keys/{key-package,welcome,commit}`); the owner half was not, so no
+  surface could found a sealed room or admit anyone to one.
+
+  - `rooms/owner/group/create/0.1`: the owner's key holder forms the room's
+    group with the owner as its only leaf, at room epoch 1 (the epoch a host
+    records at registration). Entitlement: control of the room's signing key,
+    as for issuing its credentials. Refuses `alreadyExists` rather than
+    replacing a group whose key schedule sealed records depend on.
+  - `rooms/owner/group/add/0.1`: the key holder admits a member's KeyPackage,
+    advances the room at its host with `rooms/epoch/mint` (link and commit
+    included, the caller's `admin` authority presented), and returns the
+    Welcome for the caller to deliver with `rooms/keys/welcome` — never
+    through the host. Remote first: the pending commit is kept durably, sent,
+    and applied only once the host accepts, and reconciled against the host's
+    epoch after a crash, since a key holder cannot process its own commit
+    from the wire.
+  - `rooms/owner/register/0.1` (draft, clarified in place): the key holder
+    sends `rooms/create` with `ownerDid` as its issuer, signed with a key of
+    that DID it holds, and never as itself; it refuses with `permissionDenied`
+    before contacting the host when it holds none. `rooms/create` names the
+    Owner as issuer, and a host running a creation policy (a community
+    admitting rooms for its members) checks the party asking is the owner it
+    names — a registration issued by the agent in another party's name is one
+    no host can tell from registering rooms in a stranger's name. No schema
+    change beyond the `ownerDid` description.
+
+  Additive for the generated types: two new modules, no change to an
+  existing type.
+
+## 0.26.1 — 2026-10-14
+
+
+### Added
+
+- **vtc**: Verifier identities list — the OpenID4VP verifier's state for administrators (#761)
+
+vtc/oid4vp/identities/list/0.1 lets a community's configuration
+  administrator read the OpenID4VP verifier identities the community presents
+  to swiyu and EUDI wallets, and what stops each from serving one.
+
+  A verifier identity is installed out of band — a DID registered with an
+  ecosystem, an access certificate from a registrar, trust statements from a
+  registry — and each part expires on its own schedule. A wallet that refuses
+  a request object tells the community nothing. Per identity the response
+  gives the client identifier wallets see, the DID and signing method, where
+  the key is held (cached, or kept by the community's agent), the access
+  certificate's subject, issuer and validity, each verifier_info attestation
+  with its expiry, whether it is the default, and whether a session could be
+  opened on it now. Problems use a fixed vocabulary with error/warning
+  severity: invalid key custody, no loaded signer, no link to the agent, a
+  missing, not-yet-valid, expired or expiring certificate, a missing identity
+  trust statement, an expired or expiring statement; and, community-wide, a
+  default identity that is not installed, or no https public URL.
+
+  The response never carries key material, nor the identifier under which the
+  agent holds a key.
+
 ## 0.26.0 — 2026-10-13
 
 

package/dist/_shared/components.d.ts

@@ -707,6 +707,21 @@ export type LimitSource = "policy" | "override" | "default";
  * The two-digit number the service chooses at claim, shows only to the starter (through redeem), and the approver types from the starter's screen. A string so that a leading zero survives.
  */
 export type MatchNumber = string;
+/**
+ * What a member of a community-owned room may do there. `admin` is not among them: minting epochs, admitting and removing members are the community's, as the room's owner, and are exercised through the vtc/rooms/community/* tasks rather than by any member's credential. `curate` is not implied by `write`.
+ */
+export type MemberAction = "read" | "write" | "curate";
+/**
+ * The actions granted, at least one. An empty list confers nothing rather than everything, and a schema that allowed it would make the more dangerous reading available to a careless consumer.
+ *
+ * @minItems 1
+ * @maxItems 3
+ */
+export type MemberActions = [MemberAction] | [MemberAction, MemberAction] | [MemberAction, MemberAction, MemberAction];
+/**
+ * Where an admission stands. `offered`: credentials issued and waiting for the member to collect and accept them. `admitted`: accepted — on a sealed tier, the member is in the room's group. `removed`: an administrator removed them; on a sealed tier the room has advanced past them.
+ */
+export type MemberState = "offered" | "admitted" | "removed";
 /**
  * How the request reaches the approver. A CLOSED list. Version 0.1 defines `scan`: the starter shows a trigger link (as a QR code that is also a clickable link, TRIGGER-LINK.md) and the approver's wallet reads it. `code` (a typed code of at least 8 characters, under strict rate limits) and `push` (sent to the approver's enrolled devices) are reserved names.
  */
@@ -866,6 +881,10 @@ export type PushRegistration = Apns | Fcm | WebPush;
  * Which of an account's two queues. `receive` holds messages addressed to the account awaiting its pickup. `send` holds messages the account sent that are still held against it until their recipient deletes them — so a stalled recipient fills its senders' send queues.
  */
 export type Queue = "receive" | "send";
+/**
+ * Why the administrator is making this change. Recorded with it in the audit trail. Attributed to its author on every surface and untrusted: it MUST NOT carry personal data or a credential, and a reader MUST NOT treat it as instructions.
+ */
+export type Reason = string;
 /**
  * How many records the room held when `DataCommitment` was computed — the number of leaves in that tree, tombstones included, since a tombstone is a record.
  *
@@ -970,6 +989,10 @@ export type RoleKeyState = "pending" | "staged" | "active" | "retiring" | "retir
  * A role identifier: lowercase, hyphen-separated, at most 64 characters. Compared by exact string equality. It is the value an AclEntry 0.2 carries in `role`.
  */
 export type RoleName = string;
+/**
+ * A name for the room, chosen by an administrator: shown to administrators and to the members a room is offered to. Not part of the room's identity and not sent to the room's host path. MUST NOT carry personal data.
+ */
+export type RoomLabel = string;
 /**
  * `planned` — a successor was staged, activated, and the predecessor retired on the operator's schedule. `compromise` — a key was revoked and, where the role would otherwise be empty, replaced in the same log entry. `addition` — a key was added to a role without anything leaving it (for example a post-quantum key alongside a classical one).
  */
@@ -1133,7 +1156,11 @@ export type TickLength = string;
 /**
  * One kind of change a console can be told about. A closed set: a topic not listed here is a new MINOR version of this component, not an `ext` member, because each topic is bound to the read that authorizes it.
  */
-export type Topic = "actions" | "acknowledgements" | "joinRequests" | "members" | "singleAdminMode" | "config";
+export type Topic_VtcAdminEventsV0_1 = "actions" | "acknowledgements" | "joinRequests" | "members" | "singleAdminMode" | "config";
+/**
+ * One kind of change a console can be told about. A closed set: a topic not listed here is a new MINOR version of this component, not an `ext` member, because each topic is bound to the read that authorizes it.
+ */
+export type Topic_VtcAdminEventsV0_2 = "actions" | "acknowledgements" | "joinRequests" | "members" | "singleAdminMode" | "config" | "rooms";
 /**
  * How the traffic reached or left the mediator. `peerMediator` is mediator-to-mediator forwarding.
  */
@@ -4323,6 +4350,33 @@ export interface CommunityProfileView {
      */
     personhood?: PersonhoodGovernance;
 }
+/**
+ * One room the community owns, as its administrators see it.
+ */
+export interface CommunityRoom {
+    room: HostedRoom;
+    label: RoomLabel;
+    /**
+     * The storage config receiving the room's new uploads.
+     */
+    storageConfig?: StorageConfigId;
+    /**
+     * Members in state `admitted`.
+     */
+    admitted: number;
+    /**
+     * Offers not yet accepted or withdrawn.
+     */
+    offered: number;
+    /**
+     * When the community's own `admin` authority over the room expires. A room whose owner's authority lapses can no longer advance its epoch, admit or remove; a community SHOULD renew it well before.
+     */
+    ownerAuthorityValidUntil?: string;
+    /**
+     * The administrator who created it.
+     */
+    createdBy?: string;
+}
 /**
  * A community's portable configuration: its profile plus the configuration overrides a maintainer stores for itself. Deliberately excludes per-host layers (environment variables, on-disk config files) — those describe where a maintainer runs, not what the community is, and carrying them would make an import overwrite the target host's own deployment settings.
  *
@@ -6470,6 +6524,43 @@ export interface MonitorFilter {
      */
     failuresOnly?: boolean;
 }
+/**
+ * A community's offer of admission to a room it owns, as the member it is addressed to sees it.
+ */
+export interface Offer {
+    roomId: string;
+    /**
+     * The room's host: this community.
+     */
+    host: string;
+    label: RoomLabel;
+    visibility: Visibility;
+    actions: MemberActions;
+    validUntil: string;
+    offeredAt: string;
+    /**
+     * `open`: not yet accepted. `accepted`: accepted, kept listed while a repeated accept can still be answered.
+     */
+    state: "open" | "accepted";
+    credentials: OfferCredentials;
+}
+/**
+ * The three credentials the room issued to the member, serialized as rooms/owner/{invite,issue-membership,issue-authority} return them. None is a secret: each names its subject, and a presentation of it must be signed by that subject. The member stores them in their own key holder's vault.
+ */
+export interface OfferCredentials {
+    /**
+     * The Verifiable Invitation Credential. On a sealed tier the member's key holder needs it to mint a KeyPackage (rooms/keys/key-package) and to accept the Welcome (rooms/keys/welcome).
+     */
+    invitation: string;
+    /**
+     * The Verifiable Membership Credential.
+     */
+    membership: string;
+    /**
+     * The Verifiable Authority Credential granting `actions` until `validUntil`.
+     */
+    authority: string;
+}
 export interface PasskeyVerificationMethod {
     /**
      * The verificationMethod id as it appears in the DID document: `<did>#passkey-<base64url(sha256(credentialId))>`. The fragment is content-derived so a verifier can locate this VM by recomputing `sha256(credential.id)`.
@@ -7609,6 +7700,21 @@ export interface RoomLimits {
      */
     member?: ScopeLimits;
 }
+/**
+ * One party the community admitted to a room it owns, or offered admission to.
+ */
+export interface RoomMember {
+    member: string;
+    actions: MemberActions;
+    /**
+     * When the member's authority credential expires.
+     */
+    validUntil: string;
+    state: MemberState;
+    offeredAt: string;
+    admittedAt?: string;
+    removedAt?: string;
+}
 /**
  * One change to a role's key set, from preview to completion. The rotation history of a DID is the list of these; the log is the authority for what was published, and this record adds what the log cannot say — which change was which, and (custody projection only) who asked, who approved, and why.
  */