@openvtc/trust-tasks 0.26.8 → 0.26.10

package/CHANGELOG.md

@@ -11,6 +11,132 @@ 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.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
+
+
+### Specifications
+
+- **external**: Credentials/issue 0.3 — at most 64 presigned requests per batch, responseTooLarge when the sealed answer would exceed its bound (#781)
+
+0.2 let a presign batch hold 128 operations and bounded the response's
+  sealedCredential at 262144 characters, on the estimate that 128 presigned
+  requests are about 128 KiB of cleartext and a third more once armored.
+  That estimate does not hold: a sealed-transfer bundle's overhead depends
+  on how its cleartext is encoded inside the seal and can be several times
+  the cleartext, and objectKey and uploadId may each be 1024 characters, so
+  a long key or upload id lengthens every URL in the set. A batch of 128
+  could produce an answer the schema forbids, and 0.2 said nothing about
+  what a custodian does then.
+
+  external/credentials/issue 0.3 (draft; a narrowed constraint, so a new
+  MINOR per SPEC §5.2):
+  - PresignBatch.requests maxItems 128 -> 64; every prose 128 for this task
+    updated (summary, Direct uploads, Definitions, examples, Security).
+  - New error external/credentials/issue:responseTooLarge: a custodian whose
+    sealed answer to a valid batch would exceed the sealedCredential bound
+    refuses it — never truncates the set, never answers over the bound —
+    with optional details.maxOperations; the caller SHOULD split and ask
+    again. It is a new conformance item 7, after the batch, ceiling and TTL
+    checks and before the rate check; a refused batch does not count
+    against the binding's rate. The custodian learns the size by presigning
+    and sealing (no provider contact), so noKeyAgreement precedes it, and a
+    set built and refused is discarded unreturned and unlogged.
+  - The maxDocumentBytes rationale is corrected; sealedCredential stays at
+    262144 and maxDocumentBytes at 65536 / 294912, which still hold a bundle
+    at its bound plus the echoed batch, envelope and proof.
+
+  Why cap rather than raise the bound: presigned requests are bearer
+  authority until they expire (five minutes at most for direct-upload
+  targets), so presigning more than can be used before expiry only widens
+  exposure; 64 parts of S3's 5 MiB minimum is 320 MiB per batch, and larger
+  uploads use larger parts or ask again; a larger answer must cross
+  mediators, DIDComm envelopes whose nesting multiplies base64 expansion,
+  and memory-constrained custodians and hosts.
+
+  Invalid examples: a 65-operation batch (request) and a response echoing
+  65 operations. external/_shared/0.1 already names PresignedRequestSet for
+  "0.2 and later" and keeps its own 128 bound for 0.2, so it is unchanged.
+  rooms/blobs/upload/begin/0.2's 128 part targets per answer stays true: a
+  host fills such an answer with two issuances. Bindings regenerated.
+
 ## 0.26.8 — 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.
  */