@openvtc/trust-tasks 0.26.9 → 0.26.11

package/CHANGELOG.md

@@ -11,6 +11,161 @@ 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.11 — 2026-10-16
+
+
+### Specifications
+
+- **rooms/keys**: Act 0.2 — the member is the subject, and a document that names no room names its member (#787)
+
+`rooms/keys/act/0.1` declared `subjectPath: /document/payload/roomId` and
+  resolved the member to act as "among the members of the document's room".
+  Three types in its own table carry no `roomId` — `rooms/blobs/chunk/0.1`
+  (`downloadId`, `index`) and `rooms/blobs/upload/{commit,abort}/0.2`
+  (`uploadId`) — and for them 0.1 defined neither the subject nor how the
+  recipient finds the document's room, while a producer MAY omit `issuer`.
+  A conforming request could leave the recipient nothing to resolve the
+  member from.
+
+  act 0.2:
+  - The table: these types carry no `roomId`; the member is the document's
+    `issuer`, which the producer MUST set to the member whose request
+    opened the transfer.
+  - Producer item 2: `issuer` MUST be set for a type that names no room
+    (MAY → MUST for those types; unchanged otherwise).
+  - Recipient item 2a: for a type that names no room, act as `issuer` if it
+    is a member the recipient holds keys for and the caller may act as;
+    otherwise `issuerNotPrincipal`; `issuer` absent is `principalAmbiguous`.
+    The recipient MUST NOT pick a member for the caller (not its only one,
+    not one inferred from the transfer identifier).
+  - `subjectPath` moves to `/document/issuer`. The subject is the party
+    whose authority the task exercises (`actsAsSubject: true`) — the
+    member, whose key signs — which is the question a delegated-execution
+    policy point asks of `subjectPath` ("does the executing agent speak
+    for this subject?") and exactly what Recipient item 2 decides. The room
+    is the resource the completed document addresses, not a party the caller
+    speaks for, and three of the table's types do not name one. Where
+    `issuer` is absent (a room-naming type, one candidate member) the
+    subject is the member item 2 resolves, and a recipient evaluating
+    policy or audit against the subject MUST use it and MUST NOT treat the
+    unresolved pointer as "no subject".
+  - `principalAmbiguous` / `issuerNotPrincipal` meanings cover the
+    room-less case. No code added; payload and response schemas unchanged
+    except the `issuer` description.
+  - Examples: a direct upload's commit completed as the member; a chunk
+    refused `principalAmbiguous`. Invalid example: a non-DID `issuer`.
+
+- **rooms/keys**: File-key and open 0.2 — unknownEpoch says `removed` when catching up cannot help (#786)
+
+`rooms/keys/file-key/0.1` gave `unknownEpoch` two reasons in a closed
+  details schema — `notDelivered` and `beyondChain` — and defined
+  `notDelivered` as "E is later than any epoch it holds". A removal leaves
+  the oracle's group where it was, so a file sealed after the oracle's
+  principal was removed matches that definition too. The oracle could only
+  say `notDelivered`, telling the caller to catch up with the room's
+  commits, and no commit will ever make that epoch derivable for a removed
+  member: a caller following the reason retried forever.
+  `rooms/keys/open/0.1` declared `unknownEpoch` with no details schema at
+  all, so a caller could not tell the two cases apart there either, and an
+  implementation already sends an undeclared `reason: removed`.
+
+  file-key 0.2:
+  - `unknownEpoch.details.reason` gains `removed`, and `details` gains
+    `removedAtEpoch` (integer, minimum 1).
+  - Oracle item 4: `removed`, with `removedAtEpoch`, when a commit the
+    oracle processed removed its principal from the room's group at
+    `removedAtEpoch` and E is at or after it — no later commit will make E
+    derivable, so the caller MUST NOT be told to catch up. It takes
+    precedence: an oracle that knows of such a removal MUST NOT answer
+    `notDelivered` for an E at or after it.
+  - Caller: acts on `details.reason`, never on the message; after `removed`
+    it MUST NOT retry after catching up.
+  - A `removed` refusal example, a Security & Privacy sentence, and a
+    "What changed from 0.1" section.
+
+  open 0.2 declares the same three reasons and the same details schema for
+  `rooms/keys/open:unknownEpoch`, with the same conformance text
+  (`beyondChain` for an epoch earlier than the oracle's current one that its
+  retained chain does not reach).
+
+## 0.26.10 — 2026-10-16
+
+
+### Added
+
+- **vtc/members**: Admit and make-membership — direct admission by an administrator, decided by the community's admission policy (#784)
+
+Two new draft tasks for admitting a member without a join request, as one
+  governed ceremony:
+
+  - vtc/members/admit/0.1 ("Add a member"): a DID with no access-control
+    entry (or only an `application` entry) is admitted at a community role the
+    administrator names. The community writes the entry, the member record and
+    a revocation slot and issues the VMC and role VAC, as a completed join
+    would. A former member (removed record, no entry) is re-admitted and
+    reported `returning`.
+  - vtc/members/make-membership/0.1 ("Make this a membership"): an existing
+    live entry with no member record (typically the bootstrap administrator)
+    gets the member record and credentials at the role it already holds; the
+    entry itself is not changed.
+
+  The rules no policy can change:
+  - the requester holds `vtc.members.manage` (permissionDenied);
+  - a role other than `member` takes `vtc.roles.assign`, and the entry it
+    seats is bounded by the requester's own;
+  - `admin`, `application` and any role conferring authority-conferring
+    capabilities are never seated (`roleNotPermitted`);
+  - make-membership refuses an `application` entry, an expired or suspended
+    entry, a live membership and a removed record.
+
+  The community's admission policy then admits, refers (parked in the action
+  list, answered with trust-task-next-step, approved only by another holder of
+  `vtc.members.manage` who is neither requester nor subject, every check
+  re-run at execution, exactly once) or refuses (`deniedByPolicy`). Step-up
+  and consent are described as the model the tasks are designed for, not
+  required (SPEC §7.3 item 13).
+
+  Both answer with the same AdmittedMembership (subject, role, label?,
+  status, returning, approval policyAllowed|approved|waived,
+  statusListIndex, vmc, roleVac), shared in vtc/_shared/0.1/admission.
+
+  The wire shape and codes are those of the Verifiable Trust Infrastructure
+  implementation (vtc-service), which bound the tasks ahead of this
+  specification with local types; generated types replace them.
+
+  Bindings regenerated (Rust, TS, Go, Dart).
+
+
+
+### Specifications
+
+- **external**: Credentials/issue 0.3 — details.maxOperations is a guaranteed-to-fit count, clarified in place (#783)
+
+0.3 said `details.maxOperations` on `responseTooLarge` was "how many of the
+  batch's operations, taken in order, would fit", which left open whether a
+  consumer may rely on it or must treat it as a hint.
+
+  It is a guarantee, and now says so:
+
+  - Producer (Conformance item 7): a custodian that gives `maxOperations`
+    MUST give a count k such that the same request, with `presign.requests`
+    cut to its first k operations (and `uploadId` left out if none of them
+    needs one, as item 4 requires), is answered within the bound on
+    `sealedCredential`, the account and binding as they were at the refusal.
+    It MAY be conservative — a sealed bundle's length varies with its
+    ciphertext's randomness, so a count computed from an upper bound on the
+    sealed length is sometimes lower than the most that would fit. It MUST
+    NOT give a count it has not established fits; it omits the member when it
+    cannot compute one or when not even one operation fits. The count speaks
+    for those operations in that order only.
+  - Consumer (item 5): SHOULD split by it (else in half); the first part fits,
+    the rest carries no promise, and the consumer MUST handle another
+    `responseTooLarge` on any part or any other batch by splitting again. It
+    MUST NOT treat the count as a size that fits other operations. A single
+    operation refused this way cannot be split and SHOULD NOT be retried.
+  - The `responseTooLarge` meaning, the "What changed from 0.2" list and the
+    refusal example say the same.
+
 ## 0.26.9 — 2026-10-15
 
 

package/dist/_shared/components.d.ts

@@ -337,6 +337,10 @@ export type Admission = "automatic" | "review";
  * Deliberately not a duration. A room that promised "daily" would be making a claim its owner's availability cannot keep, and a member comparing against a clock would read an owner's holiday as a host's misbehaviour.
  */
 export type AnchorCadence = "never" | "renewal" | "manual";
+/**
+ * How the admission came to execute. `policyAllowed`: the community's policy admitted it at once. `approved`: the policy referred it, the community parked it, and another administrator approved it. `waived`: the policy referred it, and the community's single-administrator mode waived the approval on the requester's own re-authentication bound to the operation.
+ */
+export type Approval = "policyAllowed" | "approved" | "waived";
 /**
  * An explicit statement of the capabilities a subject may approve. Exactly one of `ceiling` (the role's full approve ceiling), `none`, or `listed` with a NON-EMPTY list of CapabilityRef.
  */
@@ -3533,6 +3537,45 @@ export interface AdminRightRow {
      */
     breakGlass?: BreakGlass;
 }
+/**
+ * A membership admitted directly, with the credentials issued for it — the success payload of vtc/members/admit and vtc/members/make-membership.
+ */
+export interface AdmittedMembership {
+    /**
+     * The DID admitted.
+     */
+    subject: string;
+    /**
+     * The community role the membership holds: for vtc/members/admit the one requested, for vtc/members/make-membership the role the entry already held.
+     */
+    role: string;
+    /**
+     * The new entry's label, when vtc/members/admit was given one. Absent for vtc/members/make-membership, which writes no entry.
+     */
+    label?: string;
+    /**
+     * Always `admitted`: a refusal is a trust-task-error, and a referred admission is answered with trust-task-next-step until it executes.
+     */
+    status: "admitted";
+    /**
+     * True when vtc/members/admit re-admitted a former member (a removed member record, no entry), as a rejoin would re-admit them. Always false for vtc/members/make-membership, which refuses a removed record.
+     */
+    returning: boolean;
+    approval: Approval;
+    /**
+     * The membership's slot on the community's revocation status list, which the VMC's credentialStatus names.
+     */
+    statusListIndex: number;
+    /**
+     * The Verifiable Membership Credential issued for the admission, delivered inline as vtc/join-requests/decide delivers it.
+     */
+    vmc: {};
+    /**
+     * The role credential issued for the admission: a Verifiable Authority Credential issued by the community whose `credentialSubject.authority` is `{ scope: <community DID>, actions: ["role:<name>"] }`, the shape vtc/join-requests/decide returns.
+     */
+    roleVac: {};
+    ext?: Ext;
+}
 /**
  * An agent name bound to a DID. A name is only ever authoritative in the DID→name direction: the DID document's `alsoKnownAs` is what proves the binding, because anyone controlling a domain can point a name at somebody else's DID.
  */