@openvtc/trust-tasks 0.26.5 → 0.26.7

package/CHANGELOG.md

@@ -11,6 +11,86 @@ 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.7 — 2026-10-15
+
+
+### Added
+
+- **vta/witness**: Vta/witness/request — the VTA runs a witnessed session for its principal's relationship (#777)
+
+A Verifiable Witness Credential is issued to the participating party of a
+  witness/session, who presents its relationship credential bound to the
+  session's challenge. A principal whose keys and credentials live in a VTA
+  cannot do that from a client that holds neither. This adds
+  vta/witness/request/0.1: the client names a witness, the relationship
+  (relationshipDid, counterpartyDid, the enclosing thread) and credentials by
+  vault handle; the VTA opens the session as the relationship DID, builds and
+  signs the presentation itself, submits, verifies the VWC as a verifier of
+  the evidence would (issuer = session recipient = response signer,
+  taskContext/taskDigest over the session document as sent, subject and
+  object digest, vwcDigestMultibase), and stores it in the credential vault
+  with its evidence — the session document as sent and the submit #response
+  as received. It answers with the vault handle, the digest and the two
+  evidence documents (which carry the VWC); never a key, a presentation or
+  the challenge.
+
+  Membership evidence is optional. A VMC naming the relationship DID rides
+  in the relationship presentation; one naming a member DID needs an
+  explicit memberDid, and the VTA builds a second presentation by that DID
+  bound to the same session. witness/session/submit/0.1 has no member for
+  it, so its carriage is the witness's own (SPEC 4.5.1 leaves an ext
+  namespace's semantics to its controller); the OpenVTC carriage is cited
+  non-normatively.
+
+  Authorization is standing over every context the task touches, expressed
+  as the new witnessRequest capability (witness-request in device/_shared
+  0.1), which is not sign and is not satisfied by sign. Errors: notFound,
+  credentialMismatch, noMatchingProtocol, witnessUnreachable (retryable),
+  witnessRefused, challengeMismatch, presentationInvalid (the witness's own
+  code and message in details), vwcInvalid.
+
+## 0.26.6 — 2026-10-15
+
+
+### Specifications
+
+- **external**: Credentials/issue 0.2 — batched presigned requests with signed length and checksum, multipart and head, for direct uploads (#775)
+
+rooms/blobs/upload/begin/0.2 lets a host answer with direct-to-storage
+  targets whose PUT binds each part's exact length and SHA-256 (item 17),
+  and commit/0.2 has the host verify the object at storage and complete a
+  multipart upload before recording (item 3). A host that holds no storage
+  credential asks its custodian for each request through
+  external/credentials/issue on an s3-static-presign account, and 0.1 can
+  express none of it: one GET/PUT/DELETE per issuance, no signed headers,
+  no multipart operations, no HEAD.
+
+  external/credentials/issue 0.2:
+  - the payload takes either `scope` (session and token models, as 0.1)
+    or `presign` (s3-static-presign only): one object, at most one
+    multipart upload of it, up to 128 operations — put, get, head, delete,
+    create-multipart, upload-part, list-parts, complete-multipart,
+    abort-multipart;
+  - the custodian signs Content-Length and x-amz-checksum-sha256 into put
+    and upload-part, uploadId/partNumber into the query,
+    x-amz-checksum-algorithm into create-multipart, x-amz-mp-object-size
+    into complete-multipart, x-amz-checksum-mode into head, so storage is
+    the enforcer;
+  - every operation is presigned, none performed: issuance keeps needing
+    no egress, and verifying the object stays the host's duty;
+  - the binding ceiling is unchanged: each operation is authorized by
+    put / get / delete (multipart writes by put, head by get, abort by
+    delete), so no account record or other task changes shape;
+  - a batch counts once against the binding's rate;
+  - new errors requestShapeMismatch and invalidBatch; the sealed cleartext
+    for presign is a PresignedRequestSet; the response's bundle is bounded
+    at 256 KiB, maxDocumentBytes declared.
+
+  external/_shared/0.1 gains PresignOperation and PresignedRequestSet
+  (additive); CONVENTIONS §6 names the new cleartext. Bindings regenerated.
+  rooms/blobs/upload/{begin,commit}/0.2 do not name
+  external/credentials/issue, so they are unchanged.
+
 ## 0.26.5 — 2026-10-15
 
 

package/dist/_shared/components.d.ts

@@ -396,11 +396,11 @@ export type Capability_AclV0_2 = string;
 /**
  * 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" | "room-present" | "room-open" | "key-export" | "sign-sshsig" | "sign-jws" | "sign-csr" | "external-accounts-manage" | "external-auth-use" | "pcs-vetter" | "pcs-applicant";
+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" | "key-export" | "sign-sshsig" | "sign-jws" | "sign-csr" | "external-accounts-manage" | "external-auth-use" | "pcs-vetter" | "pcs-applicant" | "witness-request";
 /**
  * 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" | "roomPresent" | "roomOpen" | "keyExport" | "signSshsig" | "signJws" | "signCsr" | "externalAccountsManage" | "externalAuthUse" | "pcsVetter" | "pcsApplicant";
+export type Capability_DeviceV0_2 = "vaultRead" | "vaultWrite" | "proxyLogin" | "fillRelease" | "policyAdmin" | "deviceAdmin" | "sign" | "keyMint" | "signTrustTask" | "credentialWrite" | "memoryRead" | "memoryWrite" | "roomPresent" | "roomOpen" | "keyExport" | "signSshsig" | "signJws" | "signCsr" | "externalAccountsManage" | "externalAuthUse" | "pcsVetter" | "pcsApplicant" | "witnessRequest";
 /**
  * Number of chunks in the bundle, equal to ceil(expectedSizeBytes / chunkSize). Bounded at 4096 so that the manifest itself — one digest per chunk — fits in the single document that carries it under the same message-size reasoning as a chunk.
  */
@@ -1034,7 +1034,7 @@ export type SealedEnvelope_VaultV0_1 = DidcommAuthcryptEnvelope_VaultV0_1 | Hpke
  */
 export type SealedEnvelope_VaultV0_2 = DidcommAuthcryptEnvelope_VaultV0_2 | HpkeArmoredEnvelope_VaultV0_2 | TspMessageEnvelope_VaultV0_2;
 /**
- * A sealed-transfer bundle: OpenPGP-style ASCII armor around an HPKE-sealed `SealedPayloadV1` (base mode, X25519-HKDF-SHA256 KEM, HKDF-SHA256 KDF, ChaCha20-Poly1305 AEAD, info string `vta-sealed-transfer/v1`), with a producer assertion and Bundle-Id, Chunk and Digest-Algo headers bound into the associated data. Each task states the key it is sealed to: a single-use wrapping key from keys/import-wrapping-key for external/accounts/secret/set, and the caller's key-agreement key for external/credentials/issue. Its cleartext is an ExternalSecretPayload or an ExternalCredentialPayload. The only form in which secret material crosses the wire in this family, in either direction: the seal is what keeps a terminating proxy, a relay, a request log or a debug dump of "the response" from ever holding a usable secret, whatever transport carried the document.
+ * A sealed-transfer bundle: OpenPGP-style ASCII armor around an HPKE-sealed `SealedPayloadV1` (base mode, X25519-HKDF-SHA256 KEM, HKDF-SHA256 KDF, ChaCha20-Poly1305 AEAD, info string `vta-sealed-transfer/v1`), with a producer assertion and Bundle-Id, Chunk and Digest-Algo headers bound into the associated data. Each task states the key it is sealed to: a single-use wrapping key from keys/import-wrapping-key for external/accounts/secret/set, and the caller's key-agreement key for external/credentials/issue. Its cleartext is an ExternalSecretPayload, an ExternalCredentialPayload or, from external/credentials/issue 0.2 for `s3-static-presign`, a PresignedRequestSet. The only form in which secret material crosses the wire in this family, in either direction: the seal is what keeps a terminating proxy, a relay, a request log or a debug dump of "the response" from ever holding a usable secret, whatever transport carried the document.
  */
 export type SealedTransferBundle = string;
 /**