SMART Trust HCERT library tools
SMART Trust Tools
WHO SMART Trust · HCERT libraries · Kotlin first, Rust second

From the QR Code Generation spec to a library you can build

Requirements, API contract, wire format and payload models for the Kotlin (JVM, Android, Node) and Rust (WebAssembly) HCERT libraries. Everything here is derived from, and links back to, the smart-trust QR Code Generation page (PR 129) and the deployed WHO SMART Trust specifications.

Requirements
95
92 SHALL, 1 SHOULD, 2 SHALL NOT
smart-trust statements cited
7/7
FHIR Requirements
Open issues
35
26 to fix upstream

The HCERT pipeline

One skill per step; each opens its requirements, Tool and processes in the explorer
  1. 1hcert-select-payload
  2. 2hcert-assemble-payload
  3. 3hcert-build-cwt
  4. 4hcert-encode-cbor
  5. 5hcert-sign-cose
  6. 6hcert-compress
  7. 7hcert-encode-base45
  8. 8hcert-prefix-context
  9. 9hcert-verify
  10. 10hcert-trust-list

Viewers

External tools, prefilled

Provenance

The upstream commits the library pins:

Open issues

  • OI-01 Reference script output is not reproducible byte for byte fix upstream
  • OI-02 One payload per hcert, or several? fix upstream
  • OI-03 EKU certificate type for non-DCC payloads is undefined fix upstream
  • OI-04 Base45 reference points at an expired Internet-Draft fix upstream
  • OI-05 CBOR reference RFC 7049 is obsoleted by RFC 8949 fix upstream
  • OI-06 Subclaim 5 is called VHL in one place and SHL in another fix upstream
  • OI-07 iss is a string in the spec but a Coding in the logical model fix upstream
  • OI-08 Logical model link in hcert_spec uses a different case fix upstream
  • OI-09 DVC subclaim -6 is in the development range
  • OI-10 Deployed section anchors and preview paths need checking
  • OI-12 Base64 variant of kid in the DID trustlist is unspecified fix upstream
  • OI-13 Mapping between GDHCN participant codes (alpha-3) and iss (alpha-2) fix upstream
  • OI-14 Package coordinates and licence for the libraries
  • OI-15 Asynchronous crypto and I/O across the WIT boundary
  • OI-16 WIT type-system limits
  • OI-17 The example issues an abstract logical model fix upstream
  • OI-18 Sex binding in DVCMin points at a CodeSystem, not a ValueSet fix upstream
  • OI-19 Upstream home for the CDDL and JSON-LD artefacts fix upstream
  • OI-20 CDDL validator deviations (cddl-rs / pycddl)
  • OI-21 IHE ITI-YY3 puts a vhlink:/ string at HCERT key 5; ITI-YY4 reads an object fix upstream
  • OI-22 IHE VHL examples break their own rules fix upstream
  • OI-23 trust-phw Health Link payload types exp and v as strings and requires type fix upstream
  • OI-24 IHE VHL leaves JWE alg/enc non-normative fix upstream
  • OI-25 Manifest URL is List? in one place and List/_search? in another fix upstream
  • OI-26 IHE's Content-Digest example is not RFC 9530 syntax fix upstream
  • OI-27 No signed manifest in IHE VHL or SMART Health Links fix upstream
  • OI-28 How a receiver's keyid, and a DID trust list entry, map to keys fix upstream
  • OI-29 $generate-vhl sends the passcode in a GET query string fix upstream
  • OI-30 smart-trust states two different licences fix upstream
  • OI-31 The instance audit ignores the actors a downstream declares
  • OI-32 Requirements no test verifies yet
  • OI-33 WHO-ITB track data is not held as vectors
  • OI-34 The DEV trust list DIDs name a different host from the guide fix upstream
  • OI-35 The trust list signer departs from JOSE and does not publish its contexts fix upstream
  • OI-36 DVCMin.s is bound to the administrative-gender CodeSystem, not a ValueSet fix upstream