Skip to main content

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:

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 on reg_info. Prompted for clarity for
    the reg_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 in reg_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.