@openvtc/trust-tasks 0.26.6 → 0.26.8

package/CHANGELOG.md

@@ -11,6 +11,87 @@ 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.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
+
+
+### 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
 
 

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.
  */
@@ -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.
  *