IETF 117 SCITT AGENDA

San Francisco

Monday, July 24, 2023, 09:30-11:30

Chairs: Hannes Tschofenig, Jon Geater

Welcome and Status Update (5 min) Chairs

• Hannes went through the chair slide deck.
• Roman: reminder of keeping agendas and meeting reports current

Hackathon Report (25 mins) Jon Geater

• Jon talked about the hackathon.

• Explore an application use case on top of SCITT, it's the building
  blocks

  • Hackathon use case for publishing and verifying vendor response
    forms (for a notional medical device)

• Ray Lutz discussed voting election record use case

  • Roman had questions about how the voting election verification
    fits within narrow charter of software-only focus

• A.J. and others considered using emulator for vulnerability
  management of software

• Roy: when we got chartered, we intented to look at a wider set of
  use cases. Hence, the voting use case is absolutely in scope.
• Jon: During the chartering we said we would be focusing on the
  software use case.
• Ray: There is no need for special extension for support for the
  voting use case. I will jump in later about the identity use cases.
• Henk: There are other use cases that are software lifecycle
  specific. If Roman feels uncomfortable, we should re-charter.
• Neal: Sigstore is doing some similar work. I wonder if Sigstore
  would fit the bill for the voting use case.
• Jon: They are welcome to pile into the interop-client. We had a
  couple of discussions with the folks and it seemed aligned.
• Christopher Allen: I have concerns about engineers and human rights.
  I have concerns that we are not including privacy considerations. I
  don't see anything specifics. VRFs were designed to address privacy.
  I saw that there is some work on merkle tree. There are some very
  specific concerns about intrusions. Christopher mentioned examples
  of people who go into trouble.
• Jon: At the SCITT level we are stricly payload agnostic. We do not
  dig into what is in the payload. On the keys and correlation we are
  looking the company level. I believe we are capable
• Christopher: If you do not have certain features included at the
  bottom then you cannot fix it at higher layers.
• Hannes clarification: there is a difference between VRF (vendor
  response form vs. verifiable random function), this hackathon use
  case regards vendor response forms.
• Mike: The identity at SCITT is more at the application layer.
• Ray: Sigstore uses the email address of the user and that is not a
  good idea to put this information into immutable storage. I think we
  intentionally took it out. I am very sensitive to the human rights
  and privacy aspects given my work in the voting space.
• Cedric: There are more advanced constructions regardig privacy.
  There is room to define algorithm providing added privacy features.
  Regarding Sigstore: The focus is very different. Sigstore is about
  the transparency of signatures.
• Mike: scenario with VS Code compiler with a trojan backdoor and
  privacy implications regarding DIDs?
• Roy: We are just notarizing data. On top of it we have advanced
  applications doing search and analytics.
• Dick: It would be good to describe what is in scope and what is not
  in scope. I want to talk about the identity. You are interested in
  identities of organizations/companies.
• Hannes: group has not been chartered to solve that problem, it would
  exceed our lifetime. We are working towards coordinating with other
  interested parties, especially in other IETF working groups, for
  feedback. Also, we have a challenge in better identifying our layers
  (what is in the scope of SCITT and what related but separate in
  application layer on top of it).
• Orie: covered everything I stood up to say, reiterated emphasis on
  layering for identity and other complex elements of application of
  use cases in software utilizing these SCITT building blocks. I will
  be going through a whole section on identity you can approach me
  later.
• Jon recommends building up a rock collection for Orie.
• Jon summarized future focus on feeds, what they are, what they are
  not.

Architecture (60 mins) Orie Steele, Mike Prorock

• Mike says things are coalescing and people are using the SCITT
  emulator (=the name of an open source software program) for use
  cases.

  • Recap of the architectural context.

• "We are not the curators of a thousand semantics"

  • Use cases are often bound to particular stakeholders, often
    regulatory, so being payload agnostic is an important theme to
    continue following.

https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/

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

Volunteers to review the use case document A.J. Stein, Eliot, Dick, Dave
Waltermire.
Hannes: Please provide your review during August.

Mike started the architecture presentation and then Orie continued with
the APIs, feeds, and identity topic.

Dick: When the iss claim was created and I want to verify a token that
was not long-lived compared to the statements that you use. The use case
in SCITT is different on how these identifiers are typically used. For
the kid I typically saw the use of some random number. Here it is a bit
different when you talked about a URI. In typical applications, the kid
gets rotated on a regular basis.

Orie: COSE and JOSE have different support in libraries. The presence of
header parameters expected to support in JOSE are not necessarily
available in COSE.

Leif: If you include these name to key mapping features, then you
increase the attack vector. But it is probably unavoidable to use them.

Eliot: Be careful what you are specifying in other people's name spaces.
(References this RFC: https://datatracker.ietf.org/doc/html/rfc7320
updated by https://datatracker.ietf.org/doc/rfc8820/). If you really
want to standardize this functionality, then you can use .well-known
functionality.

Hannes: How do you want the feed to look like? Currently it is a string.

Orie: We want it to be something different to a string. It should have a
structure - a URL. Not sure what structure.

Jon: ?

Mike: We need to provide a path towards interoperability for the feed.
We can use a string or a URI. In a separate draft we can define
approaches for defining ways to use it.

Dick: The term "feed" is a bit unclear. I think about RSS when I hear
the term feedback.

?: What is the use case of SCITT? Does the application receive a live
feedback?

Orie: SCITT offers building blocks and applications may define
publish/subscribe concepts.

DaveW describes how Atom works (in the context of feeds). Maybe you
could re-use this work.

Orie: It is hard to think about this topic and not to re-use existing
technologies.

Ben: +1 on the use of URLs

Orie: We did not talk about the COSE proofs. Those will be discussed
later in the COSE WG

Hannes: How will the specification have to change to take the new
thinking about identity into account?

Orie: We should probably reference identity-related specifications and
instead of describing it in length.
The mechanism used for the issuer and the TS does not need to be the
same.

Mike: For software supply we need to pick one mechanism and we need a
history of public keys.
In the software supply chain world we often have to deal with
individuals and DID web may not deal with that properly. We need to
describe this. DID:web is not perfect for this.

Roy: ?

Bob: When talking about identity we should focus on classes of identity.
For example, are we talking about identity of individuals, companies,
devices, etc. Let the chaos follow the classes.

Orie: There are cases where the identity of developers get encoded in
payloads. We want to avoid these cases.

Ben: ?

Dick: I am confused about the role of TS.

Orie: The purpose of the TS is to authenticate the issuer. It is not the
purpose of the TS to verify the payloads.

Allen: In the Golden gate 4 meeting room we will talk about the
requirements of our drafts.

Open Mic (25) All

Wrap-up and Conclusion (5 min) Chairs