trust-tasks-v0.35.3

chore: Release package trust-tasks version 0.35.3

trust-tasks-v0.35.2

chore: Release package trust-tasks version 0.35.2

trust-tasks-v0.35.1

chore: Release package trust-tasks version 0.35.1

trust-tasks-v0.35.0

Added

• codegen: Superseded and retired spec versions are deprecated in every library, and withdrawn ones leave them in a quarterly batch (#921)

• feat(go): mark superseded and retired spec versions deprecated, and omit withdrawn ones

  Every generated request package now exports const Deprecation (empty for a
  current version, otherwise "superseded by /<M.N>", "retired; use
  /<M.N>" or "retired"), and a deprecated version's Payload and Response
  types carry a // Deprecated: paragraph. A version with status: withdrawn
  gets no package at all. The rule is derived independently from front matter,
  per SPEC "Superseded and Withdrawn Versions".

trust-tasks-tsp-v0.35.3

Fixed

• rs: The transport crates depend on trust-tasks-rs's runtime only (#939)

trust-tasks-didcomm, -didcomm-v1, -tsp, -https, -proof and
-capability-client depended on trust-tasks-rs with its default features,
which are every specification family. Cargo unifies features across the
graph, so an application that generates only the tasks it pins
(trust-tasks-build) still compiled every prebuilt module as soon as it
depended on any transport, and the facade route in GETTING-STARTED
(trust-tasks with default-features = false and runtime_path) got every
family anyway.

None of these crates uses a specification module outside its tests,
examples and doc examples, so each now depends on the runtime alone
(default-features = false) and enables acl (and task-consent for
trust-tasks-https) as a dev-dependency feature for those.

Verified per crate in isolation, so no other workspace member can switch
the families back on: cargo tree -e features shows trust-tasks-rs with
no features for each, and each crate's tests, examples and doctests pass
with --all-features.

An application that reached a family's types only because a transport
switched every family on must now enable that family (or the all-specs
default) on trust-tasks-rs itself.

trust-tasks-tsp-v0.35.2

chore: Release package trust-tasks-tsp version 0.35.2

trust-tasks-tsp-v0.35.1

chore: Release package trust-tasks-tsp version 0.35.1

trust-tasks-tsp-v0.35.0

chore: Release package trust-tasks-tsp version 0.35.0

trust-tasks-rs-v0.35.3

Documentation

• How a Rust application generates only the tasks it uses (#936)

GETTING-STARTED.md gains the client-side path: trust-tasks-cli to pin, trust-tasks-rs without default features plus trust-tasks-build in build.rs, and the facade variant (runtime_path("::trust_tasks")). trust-tasks-rs's README points at it from its feature section. Both verified as an outside client would use them: the crates.io CLI pinning from trusttasks.org, then a build against crates.io trust-tasks-build 0.1.0 and trust-tasks-rs / trust-tasks 0.35.1.

trust-tasks-rs-v0.35.2

Added

• cli, build, rs: Pin and generate tasks from third-party sources beside the registry's (#934)

• feat(cli, build, rs): pin and generate tasks from third-party sources beside the registry's

  SPEC §6.1/§6.5 already allow specifications under another authority, with
  a slug unique only within its authority. An application can now pin them
  from a third-party registry and generate them with the official ones.

  trust-tasks-cli

  • trust-tasks.toml gains [sources.] (url = "https://…" or
    path = ""); tasks are named ":", and on the command
    line trust-tasks add acme:payments/settle/1.0. add, update, check,
    fetch, list and remove all take sourced tasks; a source serves the
    trusttasks.org layout (index.json, bundle.json, by-digest).
  • The lock (still version 1) records [sources.*] and source =, sorted
    official first, then source, slug, version; bundles vendor to
    trust-tasks/@/…. Every lock read or written is also held to
    trust-tasks-build's reading of it.
  • Refused: a sourced bundle under https://trusttasks.org/ (SPEC §6.5
    item 1) and an official one outside it; a framework slug from a source;
    two pins with one Type URI; a source named like a pinned official
    family; a malformed source name or an http url; a bundle whose Type
    URI, slug and version disagree with each other or the lock.
  • trust-tasks registry build --specs --type-uri-prefix --out [--official-specs] builds a third party's specs/ tree into the served
    layout, by-digest store included. TRUST_TASKS_CA_FILE trusts an
    internal CA.

  trust-tasks-build

  • Lock parsing accepts [sources.*] and source; a sourced task is
    generated under a top-level module named for its source
    (tasks::acme::payments::settle::v1_0) and read from its vendored path.
    Identity is the bundle's Type URI in any SPEC §6.1 form; EXTENDS and
    declare_extends() key by it.
  • New publish feature: the bundle builder (front matter, policy, $ref
    inlining incl. absolute https://trusttasks.org component refs,
    lifecycles, canonical JSON, the served layout), moved out of
    trust-tasks-codegen so the registry and third parties share one
    builder. The codegen's official bundles and trust-tasks-rs modules are
    byte-identical.

  trust-tasks-rs

  • TypeUri parses every SPEC §6.1 form — https and other path forms, DID
    URLs, and urn:::spec::…:<M.N> — and prints each back
    exactly; http stays refused (its error text claimed otherwise).
  • The dispatchers and read_as decide unsupportedVersion vs
    unsupportedType by authority and slug, so another authority's acl/show
    is an unsupported type, not an unsupported version of the registry's.

  examples/consumer-app pins acme:vault/get/0.3 — the registry's slug and
  version under https://tasks.example.com — from a fixture registry, and
  dispatches both.