@openvtc/trust-tasks 0.26.7 → 0.26.9

package/CHANGELOG.md

@@ -11,6 +11,97 @@ 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.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
+
+
+### Added
+
+- **vta/witness**: The client carries the witness messages — vta/witness/{open,present,accept} replace vta/witness/request (#779)
+
+vta/witness/request/0.1 (#777) had the VTA make both round trips to the
+  witness itself, as the principal's relationship DID. It cannot: a witness
+  checks that the transport-proven sender of each document is its issuer and
+  replies to that sender, and the relationship DID's one mediator connection
+  belongs to whoever holds the relationship, normally the client. So the
+  client carries the messages and the VTA builds, signs and verifies, in
+  three steps:
+
+  - vta/witness/open/0.1: checks key custody, the credentials and the member
+    link up front, opens a session record, and returns the witness/session
+    document signed as relationshipDid for the client to send.
+  - vta/witness/present/0.1: takes the witness's session #response verbatim,
+    checks it is the witness's for this session, builds the relationship
+    presentation (and the member presentation) bound to its challenge and
+    domain, and returns the signed witness/session/submit document.
+  - vta/witness/accept/0.1: takes the submit #response verbatim, verifies the
+    VWC as #777 did, stores it with its evidence, and answers as #777 did.
+
+  The record is keyed by the session id within the caller's contexts,
+  expires, holds no presentation or challenge, and moves opened -> presented
+  -> accepted. Every handed-back document is checked against it (type,
+  issuer = the witness, recipient = relationshipDid, threadId, the witness's
+  proof) before it is read, so nothing from another session can be spliced
+  in. Each step is safe to repeat: open's duplicate is inert, present's
+  duplicates are spent by the witness's single-use challenge, and accept
+  answers the same outcome again without storing twice.
+
+  Shared rules are in vta/_shared/0.5/CONVENTIONS.md and the shared shapes
+  (SessionId, CarriedDocument) in witness-party.schema.json. The
+  witnessRequest capability now covers the three tasks.
+
+  vta/witness/request/0.1 is published (release #778), so it is not edited:
+  it is retired in place, supersededBy vta/witness/open/0.1, with a status
+  note naming its successors, why it cannot be implemented, and that no
+  implementation shipped it.
+
 ## 0.26.7 — 2026-10-15
 
 

package/dist/_shared/components.d.ts

@@ -1081,6 +1081,10 @@ export type Sensitivity = "normal" | "high";
  * Which transport a task is acting on. This is the discriminator: it selects which member of `config` is meaningful, and a payload naming one kind with another's config is malformed rather than merely ignored.
  */
 export type ServiceKind = "didcomm" | "rest" | "tsp" | "webauthn";
+/**
+ * The id of the witness/session document the VTA built in vta/witness/open: the session's name, the thread every document of the session is on, and the value the VWC carries as taskContext. The VTA keys its state for the session by it.
+ */
+export type SessionId = string;
 /**
  * `EdDSA` pairs with an `ed25519` key; `ES256` pairs with a `p256` key; `ML-DSA-44` and `ML-DSA-65` pair with `mldsa44` and `mldsa65` keys respectively. An `x25519` key performs key agreement and can sign nothing, so no algorithm here is valid for one. These are JOSE algorithm identifiers, externally owned, so they are carried verbatim and never re-cased (SPEC.md §4.10 rule 5); the ML-DSA names are those RFC 9964 registers in the JOSE Web Signature and Encryption Algorithms registry, which is why their hyphenated casing differs from the `keyType` values beside them — those are specification-defined. The set is expected to grow as algorithms are registered. The enumeration remains closed: an unrecognised algorithm is refused rather than silently substituted with a supported one.
  */
@@ -4231,6 +4235,11 @@ export interface CapabilityScopeListed {
 export interface CapabilityScopeNone {
     scope: "none";
 }
+/**
+ * A whole Trust Task document — `id`, `type`, `payload` and every other member, `proof` included — carried between the VTA and the witness by the client: one the VTA built and signed for the client to send, or one the witness returned for the client to hand back. Typed as an open object so every member survives a round trip: carried exactly as built or received, never re-serialised, because its proof is over itself. Its envelope is checked by the VTA against the session record (CONVENTIONS.md §3), not by this schema.
+ */
+export interface CarriedDocument {
+}
 /**
  * The terms of a `chunkedTrustTask` transfer, committed before any chunk moves. On export the recipient states them in the descriptor; on import the producer pre-commits them in the request and the recipient echoes them. Either way the manifest arrives in a document whose proof is REQUIRED, so the per-chunk digests are authenticated by the party that computed them and each chunk can be verified — and a single bad chunk re-fetched or refused — on arrival rather than only after reassembly.
  *