SCITT Virtual Interim Meeting 31. July 2023

Hannes was quite happy with the progress at the hackathon.

Jon pointed out that there is a desire to move the API description into
a separate document. We will have to update the SCITT emulator and I
have some resources.

Ray was quite happy with the progress at the hackathon. It was well run!
It is fine to pull the API out of the architecture document and to make
progress on the main specifications independently. The VRF gives us a
lot to cew on. I will be looking at the election application and will
develop a similar document for this application. How it will have to get
integrated into the base document has to be explored.

Roy: It is clear that we have to close down the architecture document.
One topic that came up was the physical supply chain where we have more
than one receipt. I will post something to the list. There was a side
meeting for the Elision & Gordian Envelope there was a side meeting I
will post a summary to the list. Here is the link to their document:
https://www.ietf.org/archive/id/draft-mcnally-envelope-02.html

Henk: There was some resistance against the ideas proposed by the group
working on Elision & Gordian Envelope. There was a lot of feedback. A
design rational was requested.

Hannes: Is it clear what the privacy benefit was?

Roy: It is about hiding of data. It is not directly applicable to SCITT
as such.

Ray: What was the outcome of the discussion with KEYTRANS?

Henk: KEYTRANS is happening -- just the BOF was cancelled. It is focused
to group messaging.

Hannes explained that he met Brian McMillion to talk about the scope of
KEYTRANS. KEYTRANS is focused on messaging and stores key-value pairs
into an append-only log whereby the key is the username and the value is
the public key using a combination of log- and prefix trees.

Dick: I wrote an article about the hackathon success:
https://energycentral.com/c/iu/international-trust-registry-demonstration-success
If we failed the integrity of the TS, then we failed.

Hannes: What happened to the call for adoption for the COSE receipts
draft?

Orie: It went out already on the COSE list.

Hannes will forward it to the SCITT list.

Ray: The issue of the feed was discussed quite a bit. Jon was pulling it
together to accomodate different designs.

Jon: For those who watched the hackathon summary, I failed to do a
unified submission of claims. I worked on it (in the emulator) during
the IETF week and it is in a branch on Github. I have been implementing
feeds into my implementation. At the moment the client does not take a
feed at all. I want to fix that.

Hannes: We also need specification in the architecture specification as
well.

Orie: The next steps for the feeds are. We need to expose URLs from the
API and explain how to interact with the API. It will be worthwhile to
evaluate whehter we want to support data URIs as well for QR codes.

Hannes: What is the plan for the API draft work? (Link:
https://github.com/ietf-scitt/draft-birkholz-scitt-scrapi)

Orie: Don't know the timeline. The client currently does signing locally
but we might want to think about the remote signing use case as well. We
should be able to make parallel progress by separating the two items.

Dick: There is currently work ongoing on trustmarks and the QR codes are
important items. It should be possible to put a QR code into the SCITT
trust registry. This is a high-priority use case.

Henk: There is now a draft on the API draft with the text copied from
the architecture draft. As soon as Jon & Orie agree on the core API
elements, we can submit it. Start of September (?)

Neal: What is a trust label?

Dick: EU CSRA (called CE Mark) and new initiative US cyber security mark
(QR mark on an IoT package with information about the trustworthiness of
the device)

Links provided by Dick:
US Cybersecurity Label FAR updates for IoT device labels due September
30, 2023:
https://energycentral.com/c/pip/biden-harris-administration-announces-cybersecurity-labeling-program-smart

\
EU CRA CE Mark (label requirement)
https://data.consilium.europa.eu/doc/document/ST-11726-2023-INIT/en/pdf

Roy: Is QR code based on this static or dynamic evaluation?

Dick: Singapore & Finland have static labels. Don't know about the EU &
US labels. I suggested to use dynamic labels.

Link by Dick: Example from Finland showing attestation from a trusted
device (with a trust label)
https://tietoturvamerkki.fi/sites/default/files/media/file/Ruuvi-statement-of-compliance-for-the-cybersecurity-label.pdf

Roy: You are looking for an identifier that takes you to the label.

Dick: They use the term "label". Ultimately it points to some
information so that people can use it to make a risk-based buying
decision.

Neal: It is not useful to use the term "trust" for this purpose. We
should push back. The value of SCITT is to have statements out there and
have them tied back to the person who made these claims.

Dick: I agree with you. The thing about SCITT is that it does not talk
about static or dynamic information - SCITT can use both.

Roy: I agree with pushing back.

Dick: It is difficult to change the language of the regulation.

Roy: It is misleading to consumers.

Dick: I completely agree. Trust in software is ephemeral. We are giving
consumers a false sense of security.

Ray: Imaging we had this label on a product and use it. What do I get?
If we have a clear idea what we get then we could work down from that
problem. What we got so far is a core building block (with SCITT) and we
need to position this building block. Is there any real response to this
QR code idea? When you click on the QR code, you cannot get back the
VRF.

Henk: We talked about dynamic information. The feed structure is pretty
close to this concept.

Hannes: did I hear you correctly that the QR code would translate to the
feed and the feed would be used for the look up?

Henk: Yes, or the MUD URL.

Roy: Where are we with the company / organizational id?

Hannes: Still ongoing.

Neal: I had the same idea, Henk. It needs to be dynamic and
interoperable. A real person needs to be able to click on it. A vendor
needs to be responsible to keep the feed up-to-date. In some sense this
could be a way to verify what vendors are claiming. It should be a
yes/no answer. This would be a really useful usecase.

Neal: Could be in the use case draft?

Hannes: It has to contain normative text as well. So, the use case is
not best.

Dick: Could put something together but would appreciate to do it in a
collaborative fashion.

Henk: I had some thoughts about this in the context of RATS. SCITT has
the same issue. We want to make sure that the TS is trustworthy. What
are the requirements? We have a lot of experience with the QR codes with
vaccines. There are multiple ways to do this. We can visibility for the
SCITT group with the proposal.