Minutes interim-2023-scitt-36: Mon 15:00
minutes-interim-2023-scitt-36-202310091500-00
Meeting Minutes | Supply Chain Integrity, Transparency, and Trust (scitt) WG | |
---|---|---|
Date and time | 2023-10-09 15:00 | |
Title | Minutes interim-2023-scitt-36: Mon 15:00 | |
State | Active | |
Other versions | markdown | |
Last updated | 2023-11-20 |
minutes-interim-2023-scitt-36-202310091500-00
Minutes 2023-10-09
Agenda:
-
Picking up from last week's items:
- Add OAS definition to emulator: Add OAS definition #2
-
New PRs discussed duign the week:
- Attempt to clarify Feed vs header vs reg_info: Attempt
clarification of Feed purpose and differentiate from reg_info
#107 - Suggestion to move Feed to be a 'special' member of CWT claims:
Use CWT Claims in Headers #108
- Attempt to clarify Feed vs header vs reg_info: Attempt
Feeds:
- Jon - If we remove feed, we lose the ability to simply correlate a
collection of statements on a known property. If a user has a signed
thing in their hands, how do they discover what other statements
have been made about this artifact? How can users understand the
collection of statements about the artifact? How to get the latest
or newest information to make the most current decisions. - Yogesh - Logically grouping statements made about an artifact, from
different entities. Need flexbility to group those in a meaningful
way. Feed provides that. - Ray - Read more about non-equivcation. Believe there's no way to
achive this, withtout the othe party having all copies of all prior
statements. Ray to post a link to the article. Believe feed is
needed, but something like feed. Trying to come up with feed becomes
confusing. Having the metadata allows users to construct their view
of a feed. If you assume the machine (service) isn't failing, you
can use the statements.
(https://itu.dk/people/debois/papers/podc20.pdf) - Jon - The failure modes need to be documented. If a transparency
service doesn't give you the full list, it's a problem and a deeper
topic. - Roy - believes there's a storage and query system over the SCITT
instance. There will be authorative points of views about artifacts,
with well-known endpoints. Within corporate firewalls, consumers can
make determiniations about the artifacts. Should you support
multiple SCITT instances, or one? -
| Steve - Today we already have the concept of multiple parties making "statements of quality" about products from other entites. NIST makes "statements of quality" on products | projects from multiple entities. Security companies make "statements of quality" on products | projects. It's up to the consumer to choose who to trust. |
-
Yogesh - how to coorelate across different SCITT instances? These
are separate problems. Is the bare information for the end users to
construct the feed to get associated statements from the registry
(TS) to get the data. Can provide an example in the SCITT guidance
documents. - Jon - what we've discussed today sounds like a profile atop a spec.
Does the spec make it usable to enable profiles. May be best to add
to the usecases document for how you'd discover and validate. - Yogesh - appears to be a profile type parameter. Perhaps make the
feed a base type, keeping it at high level where a profile can
rationalize the type. - Jon - highlights the
reg_info
was not well documented. Highlights
the challenges for indexing onreg_info
. Prompted for clarity for
thereg_info
. Based on 117, we don't beleive we need to have a
complex structure, that a single property would do. The subsquent PR
provides a means to link them together, avoiding the need to make a
complex structure. - Yogesh - need more clarity on
reg_info
and registration policy. - Jon - yes, there's a lot of clarity that can be added there.
- Ray - it seems helpful to split
reg_info
into two parts. Split out
common names for the attributes, with the other part for information
about registration policy to the SCITT registry (TS). I think that
would solve the anguish about having metadata inreg_info
,
providing separation between the two. Feed may be still necessary,
so there is some type of "name" to propigate across multiple
locations to enable multiple people to track artifacts. - Jon - has to be possible for transparency services to find
artifacts. Do we have to specify how that can be done, or metadata
can achieve that? - PR 107 simplifies the language, with PR 108 provide more
structure. - AJ - PR 107 clarifies a lot of the outstanding questions.
- Orie - Would like to preserve the behaivor in the document, with
language the role of the TS and the issuer being well defined.
CWT may solve these problems. We already have a way to add
issuerer. Is this duplicative with what is defined in CWT (1). The
way we define feed is duplicative of CWT subject. The terminology
we've been using for feed is very similar to what CWT subject uses.
We're not losing the normative behaivor by replacing feed with
subject. The subject is the identifier for the artifact, for the
statements being made. Can reuse the IANA registry for SCITT. There
are many RATS entries that could be used.
A lot of folks are concerned around tokens. Confirmed with the
authors of the RFC, you can use this structure for arbitrary content
types. That's important for SCITT, to support multiple
content-types. We want to secure the content-types we can see. - AJ - if we use subject, how do we know multiple parties are talking
about one artifact, or a subset trying to make statemetns about
multiple artifacts. - Orie - if we use string values, due to casing and other string
concerns, we will have challenges.