@openvtc/trust-tasks 0.26.19 → 0.26.21

package/CHANGELOG.md

@@ -11,6 +11,112 @@ 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.21 — 2026-10-19
+
+
+### Added
+
+- **voting**: Community voting — voting/* (the ballot box), vtc/elections/* (the registrar) and vta/pcs/voter/* + vta/pcs/vote (the voter's agent) (#834)
+
+* feat(voting): community voting — voting/* (the ballot box), vtc/elections/* (the registrar) and vta/pcs/voter/* + vta/pcs/vote (the voter's agent)
+
+  Twenty-one draft 0.1 tasks for VTI-VOT-001 – 100 (dtgwg-vti-spec, Community
+  Voting chapter). A member proves only that they may vote, never who they are,
+  and anyone permitted to read the board can recount it.
+
+  - voting/_shared/0.1: CONVENTIONS.md (separation of registrar and ballot box,
+    the exact cryptographic binding — deployment label, ticket class
+    voter/<electionId>, hash-to-G1 election point, framed ballot context, cast,
+    admission, RFC 9162 board hashing — authorization, VTA custody, privacy,
+    shared error local parts, retry safety) and voting.schema.json (Manifest,
+    Question, Ballot, Cast, BoardHead, BoardEntry, MerklePath, ElectionResult,
+    ElectionSummary, VotingParameters, Disclosure …).
+  - voting/*: election/{register,show,close,cancel}, ballot/cast (HTTPS binding
+    always accepted, one-time did:key issuer, signed receipt, idempotent),
+    board/{head,read,inclusion,consistency}, result/show. 0.1 serves open
+    elections only; sealed and tallied-encrypted await the trustee tasks.
+  - vtc/elections/*: create (binding elections park for a second
+    administrator), list, show (disclosure, kept checkpoints, certified result),
+    close, cancel, certify (the VTC verifies the board itself), tickets/issue
+    (blind, one per eligible party, recorded before answering).
+  - vta/pcs/voter/{register,accept,receipt} and vta/pcs/vote: a voter key per
+    election, the blinded ticket request, the signed cast document the client
+    sends itself, receipt keeping and inclusion checking. New capability
+    `pcsVoter` in device/_shared/0.2 Capability.
+
+  Bindings regenerated (Rust, TypeScript, Go, Dart); check-bindings agrees and
+  the Rust conformance suite passes. Reference implementation of the binding:
+  vti-voting in verifiable-trust-infrastructure.
+
+- **vtc/groups**: Appointing group managers — vtc/groups/managers/{add,remove}/0.1; create refuses an unserved dynamic group (#833)
+
+* feat(vtc/groups): appointing group managers — vtc/groups/managers/{add,remove}/0.1; create refuses an unserved dynamic group
+
+  The groups family made a manager an access-control resource grant,
+  `vtc.groups.manage` qualified `group:<groupId>`, "never this record". But no
+  task wrote that grant. The general `acl/grant` caps a grant by the holder's
+  role ceiling, so only an administrator could ever manage a group.
+
+  - vtc/groups/managers/add/0.1: a manager of the group, or a holder of the
+    unqualified capability, appoints an active member. The appointment is a
+    resource grant on the appointee's entry, delegated by the signer, which sits
+    beside the role and never inside its ceiling, so a member with no
+    administrative role may hold it. The signer must cover the grant. It is
+    reviewed like any delegated grant when its granter departs, and withdrawn
+    with the group or the holder's departure. The group's record never decides
+    who manages it. Codes: notFound, entryNotFound, alreadyManager.
+  - vtc/groups/managers/remove/0.1: a manager steps down, or a holder of the
+    unqualified capability removes another manager's appointment. Managers of
+    one group do not remove one another. Codes: notFound, notManager.
+  - vtc/groups/create: `kindNotServed` lets a community that serves only static
+    groups refuse a dynamic one after checking its rule. It never stores a
+    dynamic group it does not compute.
+  - group.schema.json: `managers` points at the new task.
+
+
+
+### Fixed
+
+- **device**: PcsVoter is appended to Capability, not inserted — no existing variant moves (#835)
+- **vtc/directory/card/present**: A Data Integrity presentation binds through its signed nonce and domain (#831)
+
+Producer conformance required a Data Integrity presentation's proof to carry `challenge` equal to the document's `id` and `domain` equal to the community's DID. Neither member is signed by the Data Integrity libraries the implementations use: a proof stating them either fails to verify or carries them unsigned, where they bind nothing. The presentations this ecosystem already produces for a verifier (`vta_sdk::vp::build_di_vp`, the OpenID4VP DI path, the personhood assertion) put `nonce` and `domain` on the presentation itself, which the holder's proof covers.
+
+  The binding is now the presentation's own `nonce` (this document's `id`) and `domain` (the community's DID), signed by the holder proof; a proof that also states `challenge` or `domain` must state the same values. The consumer's item 3 is unchanged: it verifies "the binding above".
+
+  No schema change beyond the presentation's description; the generated libraries carry the new text in their documentation.
+
+## 0.26.20 — 2026-10-19
+
+
+### Fixed
+
+- **vtc/directory/images/upload**: TooLarge also refuses a picture beyond the decoding bound (#829)
+
+images/upload declared `tooLarge` for `data` that decodes to more than 262144 bytes, and item 2 refuses it before decoding. But the payload schema already bounds `data` to exactly 262144 bytes, so a conforming community could never send the code. The schema answers malformedRequest first.
+
+  The bound that matters is the other one. A PNG of a few kilobytes can claim tens of thousands of pixels across, which is a decompression bomb, and nothing in the specification told a community to stop it. Item 2 now requires a community to bound what it decodes, the pixels a picture may claim and the memory its decoding may take, and to refuse a picture beyond either with `tooLarge`. The code's meaning says the same.
+
+  No schema change; the generated Rust carries the new meaning in its documentation.
+
+- **vtc/directory/card/publish**: The card names its signer as issuer, so an agent-held key can sign it (#830)
+
+card/publish allowed a card no members but `@type`, `version`, `uid`, `kind`, `updated` and `proof` besides its values. That left a member whose key their agent holds, the usual case, with no way to sign it: keys/sign-document signs a document only as the DID it names in `issuer` or `controller`, and the card could name neither.
+
+  The card now carries `issuer`, the membership DID, as a required member that carries no directory value. Item 4 checks it is the member's DID. The mapping section says why it is there, and a card/public reader checks it names the DID that signed. It adds no identifier: the proof's verificationMethod already names the DID, and the recognition record the card hangs from names it too. The correlation paragraph is corrected to say so.
+
+  The examples gain `issuer`, and their cardDigest is recomputed (zQmcjRKZd1TExLaEuMVv5xe2tTx4a1YkRQ58zwVrnByxYS4). The PublishedCard description in the shared schema lists `issuer` among the members a consumer checks; the bindings are regenerated for that description.
+
+- **vtc/directory/card/publish**: Pin the JSContact mapping, and withdraw without waiting on the registry (#827)
+
+card/publish item 4 compares a member's card with their public values "mapped as JSContactCard maps them", but JSContactCard names only where each base field lands, not its shape: not the map identifiers, not how a link list is laid out, and not what the avatar's `uri` is. Two conforming wallets could sign different bytes for the same values, and a community could not tell which was right.
+
+  *Mapping the public values* fixes it: one JSContact member per field, fixed map identifiers (k1, m1, p1, n1, l1…), the avatar as `media.m1` with `uri` `urn:vtc-directory:<entryId>:avatar:<sha256>` (what a reader sends to images/get), and every other field as a member named by its key. Item 4 now compares against that table, and lists `proof` among the members that carry no directory value.
+
+  Item 9 said to remove the registry pointer first, then stop serving the card. That kept a card the member had withdrawn on public view until the registry answered, which can be an hour when it is down. A withdrawal now stops serving and erases the card at once and removes the pointer, retried until it lands. A pointer read in the meantime names a card card/public answers notFound, which tells the reader nothing. card/update item 7 and the retention note follow.
+
+  Prose only: no schema or generated binding changes.
+
 ## 0.26.19 — 2026-10-19