Agenda

Published agenda

On 16th October we'll continue our regular agenda of marching towards a
good state for -118.
With only a couple of weeks to go we'll also need to take candidates for
a hackathon target.

The main topic of this work in the interims is centred around getting
Feed ID and Feed strucuture
into a good shape so that the SCITT building blocks are practically
useful for our target use cases
such as software release tracking.

Revised agenda:
• Discussion on hackathon targets(10 minutes)
• Review open PRs
• Progress of SCRAPI
• Update and discussion on Feed structure

Agenda hacking

Roy requested to push the Feed discussion to the back half of the
meeting to accommodate late arrivals. This was accepted by the chairs
and in any case is a good fit for the planned agenda.

-118 readiness

Document submission deadlines

Draft submission deadline is next Monday.

Presenters and topics

Roy suggests a talk at the SPICE BoF (Secure Patterns for Internet
CrEdentials) about how SCITT relates to SPICE.

Roy also believes that the work by Henk on epoch-markers is relevant.
Henk briefly talked about the secure timestamp and the epoch-marker.

Jon will go to the mailing lists and try to get some input from RATS and
COSE.

Roy raises Endorsements - moving away from self-signed claims. It's been
parked for a long time but this could help with finding the 'needle in
the haystack', not seeing 200 pieces of independent evidence but rather
having

Cedric raises Registration Policies as a potential next topic along with
Endorsements

He is also asking whether we need to present at the KEYTRANS WG. Orie is
a co-chair of KEYTRANS, and says that there is currently no need to do
anything. If there is something to align, he will reach out. Yogesh
believes that their work is remarkably similar. Hannes shares his view
about what they are doing. Yogesh asked why we cannot collaborate.

Henk believes there is no interoperability beyond a given system: if a
messenger A has users and messenger B has users, then the users of B are
not supposed to use the keytrans system of A.

Orie follows a different model with different priorities. There is
currently no interest in alignment (even at the level of encoding
formats).

Ray: It would be counterproductive for us to make KEYTRANS work within
SCITT. I would avoid it to focus our attention to it. (Ray notes that he
cannot attend the next IETF due to conflicts with other events related
to the upcoming elections in the US.)

Dick: I agree with Ray 100%. The API will be a critical success factor.
This is where our attention should go to.

Hackathon targets

Jon: Focus on getting the identification and the fetching of the
statements/receipts out of a usable API. John Anderson put
authentication to the front-end.
My plan is to implement SCRAPI in multiple implementations. Other ideas:
epochs, registration policies, endorsements.

Orie: Implementing the APIs is a good idea and to add tests around them.
Exploring QR codes. Command line tool hacking. John Anderson also had
some policy pieces that could be added. (Orie stated that he will be
there in person.)

Charlie: Run though the various user functions that need to be
developed, such as enter a statement, upload a signed statement,
retrieve receipt, etc. There are a lot of un-sophisticated users and
what steps they need to perform. It might be more a table-top exercise
rather than a hackathon. He will not be at the IETF meeting.

Jon: This is an important thing to do - as a sort of activity diagram.
It would also be useful to present during the meeting

Dick: I agree with Charlie. It goes back to the need to make it
practical. Here is an example of what we do (posted into the chat
window): "QR codes are just an alternative representation of an API
call; here is a QR code example of a cybersecurity label lookup API
call: https://reliableenergyanalytics.com/products"
People need to be able to make clims into the 'trust registry',
reviewers need to be able to find things, both need to be able to get
appropriate access.

Yogesh, Cedric, Henk, Steve will also attend the hackathon.

Steve pointed out that there are two implementations:

• https://github.com/scitt-community/scitt-api-emulator
• scitt.xyz

A.J. will be at the hackathon as well.

PRs

https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pulls

Editorial PR

https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/110

approved. Not controversial.

Remove Feed

https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/104

Ray: The concept of feed is not obvious to people when they come to
SCITT. The idea that a feed is a product name or a reference to a
product is not something that people will associate as a feed. I believe
the submitters to SCITT should only provide immutable attributes of the
actual submission. When an issuer submits something into SCITT it should
be immutable information.

Cedric: I agree with Ray but it applies equally to the registration
info. We should discuss whether the feed should be separated from the
registration info.
I think this is the core of the argument. We cannot agree where to put
the info.

Yogesh: A side question: Cannot we keep both data types in the feed
database. Main question: If we cannot define the scope of the feed then
should we really keep it?

Sylvan: A signed statement needs to indicate that it is from the issuer.
We must have a purpose and it has to be in the header otherwise we lose
a core piece of the transparency piece. The feed allows to associate a
sequence of statements. If we have an issuer A making a statement then
we need put information in there. Maybe we don't want to call it feed.
But we must have somewhere to clearly identify the purpose of a signed
statement.

Steve: I agree with Sylvan. The main argument was related to the data
type of the feed. Losing the feed functionality would be a problem. If
we later want to change the name "feed" into the "topic" that's OK for
me.

Ray: Yes, it should be named something else. Reg-info is a named-value
pair and it could have additional structure (product, feed, topic,
etc.). We really only need one of those in the protected header. Having
two structured descriptors is too much. We only need one.

Dick: Agree with concept of "purpose". It has to be some understanding
of what the statement is about.

Yogesh: I am not against the concept. The way Ray put it, we should keep
it at the level of key-value pairs, and we should not restrict it. Keep
it abstract.

Roy: What Sylvan is proposing is a bit different.

Sylvan: A feed is an issuer statement that the SCITT instance is
evaluating prior to registration.

Charlie: How is this a feed? My understand is that it is a time-based
thing: starts at time A and finishes at time Z. Purpose is orthogonal
about the feed.

Sylvan: Feed is, for me, time-bound. It is a time-based sequence of
purpose.

Charlie: Someone mentioned a "selection" previously and I like that
concept. "feed" does not capture the meaning.

Sylvan: Feed is not about how the user establishes a collection. It is
created by the issuer.