SCITT Virtual Interim Meeting 14th August 2023

Agenda

Published items

• Review open PRs
• Progress of emulator reflecting -117 results
• Progress of SCRAPI
• Update and discussion on Feed structure

Additional items (agenda bashing)

• (Jon) Session request for -118 is open. Any constraints?
• (Ray) New agenda item "Data Packaging"

Notes

Progress of emulator reflecting -117 results

Jon committed coding work on the emulator to the Github repo:
https://github.com/scitt-community/scitt-api-emulator
For transmission of CBOR, Jon's implementation uses armored JSON to
transmit data over the wire.

Progress of SCRAPI

Orie suggested to use YAML for the API description.

Henk: Added himself as a reviewer, Got blocked on Jon's comment
questioning the value of a YAML version. YAML is a good diagnostic
language for CBOR but it's not resiliant to transmission over the wire
so...not against it, but it can cause some niggles.

Orie: Developers misparse the binary and they re-encode the binary as
text. Lots of API tooling is not yet ready for CBOR and COSE. You can
say that: Here is the JSON encoding of it. I prefer to wrap COSE/CBOR
structures in YAML or JSON for easier processing. I would be concerned
about only using CBOR/COSE.

Hannes asking a clarifying question.

Ray: Complete agree with Orie. Ease of use is important. CBOR replaces
ASN.1 and it was at a time when bandwidth was limited. This is not so
important today. If we can leave it as JSON, why go to CBOR?

Jon: I got hung-up with a similar question as Ray - if we have JSON why
bother with YAML? But that's not really important: all this makes a lot
of sense in terms of debugging, wire transport etc.

Henk: One reason to stick with COSE/COSE is the signature checking. The
support for COSE/CBOR in the web context is not great but we need to
look into the future. Henk believes that JOSE cannot provide the same
functionality as COSE.

Neal: Agree with Henk having seen the problems with two ways of
presenting things. Sticking to something is better than supporting
multiple options.

Orie: We should distinguish between the payload and the API response. If
the API is implemented in a real-world deployment then JSON and YAML are
off-the-plate.

Ray: If you look at major providers today, they are using JSON. I want
to talk a bit about the QR code work done in Europe, they used a
simplified JSON structure to allow readability. Nobody cares about how
it is encoded.

Henk: I am with Ray. The European Health Certificates is a CBOR
structure -
https://github.com/ehn-dcc-development/eu-dcc-hcert-spec/blob/main/README.md.
When the QR code is shown to a reader it is displayed to the human. On
the reference API we can have two versions (CBOR and JSON).

Orie: I make a strong statement. There is a MTI CBOR API. You shouldn't
need anything else. Optionally, we could add YAML encodings for
human-readable versions and debugging. There should be no expectation of
interoperability from the YAML-based API.

Data Packaging

Background: I had previously reviewed various packaging trends here:
https://docs.google.com/document/d/1xfU_s1Eu51z_WGg5VYBsQtjsKcrV6_TvFXj2WxBcj90/edit?usp=sharing
-- packaging data for SCITT.
And the idea is to consider that we would leave the scitt machine very
minimal and push everything, including identity into a higher level.

Ray argues to work on a draft describing the VRF. No document exists yet
but the plan is to work on one. Hannes encouraged him to work with Dick
on such a document.

Update and discussion on Feed structure

Postponed

Review open PRs

Postponed

Agenda items for next week

Steve: Feed structure
Henk: Issues & PRs
Dick: SCRAPI API

Roy: A query API is out of scope and not in the charter.

Yogesh: I sent a mail to the list about CISA on how to secure the
software supply chain. I suggest to reply to the call for comments.