Welcome and Introduction

• A.J. Stein and Steve Lasker volunteered to take notes for this
  session
• Roman ("AD Emeritus") signalled transition to new AD, Deb Cooley
• Thanks to previous chair Hannes Tschofenig
• Welcome to replacement chair, Chris Inacio

SCITT Overview

• Review of charter scope

• Discussion of key principles of SCITT architecture

  • Interoperability
  • Opaque artifacts
  • Inclusion into Transparency Service
  • Identities register artifacts, artifact content is not important
    to TS operation

• Review of payload design

Document Status

• draft-ietf-scitt-architecture-06

  • This is the main document of the WG

• draft-ietf-scitt-software-use-cases

• draft-ietf-scitt-scrapi-01

  • This is one way to interact with transparency service(s)
  • Few required endpoints, optional endpoints for useful but not
    mandatory functionality

• draft-ietf-cose-merkle-tree-proofs is related and relevant (it
  is a normative dependency) but dotted line relationship, not
  maintained in this working group

  • Originated from similar CT architecture and proof design
    https://datatracker.ietf.org/doc/html/rfc9162#name-merkle-consistency-proofs
  • Inacio asks for status
  • Orie confirms this document is approaching last call
  • More work to hammer out consistency proofs in spec, specifically
    cose-wg/draft-ietf-cose-merkle-tree-proofs#13
  • Orie requests additional reviewers from SCITT WG chairs (COSE WG
    chairs asked prior)

• Question from Yaron: are semantics in scope? Only APIs and payloads?

  • Orie: semantics are mostly out of scope

Recap since 118

• Henk
• A lot of the changes reflect cleaning up teh spec
• Receipts were pulled out to anothe spc
• SCIIT Architecture profiles the Receipt
• Receipts are returned asyncronously, to resolve large scale
  solutions
• Cleaned up terminology, such as Consumer which can be consfusing in
  a Supply Chain.
• Mike Prorock: Is verifier and relying parties aligned with NIST
  terminology?
• Henk: no, it was defined within the scope of SCITT to avoid reused
  words and provide definitions in the terminolgy
• Justin Richer: naming is hard. Doing the correct thing to qualify as
  used in this document. Which is what (I) told NIST and the W3C. Can
  never get away from these clashes. Encourage to use the defined
  names, but can define the term as used in other spaces.
• Orie: feed and subject - the subject identifier is of the opinion of
  the issuer. It's chosen by the issuer. How do two issuers talk about
  the same identifier?
• Justin: without comment on feed as a structure. Brought up in many
  different spaces. The idea that issuer and subject need to be
  paired. Not a unique problem to this space. (NIST 800-63c regarding
  issuer and subject.)
• Mike Prorock: believing its an application level thing. If it could
  be pulled out to a separate document
• Henk: might pu in the use-case document, that we may not publish as
  a ID
• A.J.: Is the use-case going to be published.
• Henk: it's up to the authors
• Chris/Chair: There's questions on the value of publishing use-case
  documents. But, you can extract parts of the use-case into
  subsequent documents. however, the community has questions about
  publishing use-case documents. However, referencing use-case
  documents will continue to exist as an expired document.
• Orie: my understanding was to settle the architecture documents.

SCRAPI

• Specification of sample API endpoints longstanding part of the
  charter
• Not the only method for interaction with TS
• Orie: if you are looking at the key discovery endpoints, they are
  optional, and they based on OAuth SD-JWT designs and not invented
  originally here, we are trying to follow pre-existing designs and
  practices from OAuth, SPICE, and others. We need more expertise on
  key discovery protocols, feedback welcome.
• Jon and Orie: DIDs are deprecated now, no longer mandatory for SCITT
  TS implementation.
• Henk: thanks to HTTPDIR for review of the draft. Important
  terminology and edits to document made as a result.

• Reviewers:

  • A.J. Stein
  • Monty Wiseman
  • Thomas McCarthy-How
  • Roy Williams

• Orie: test suites, we have some Python code for early SCITT arch
  components. It's drifted from arch spec. Considering test suite for
  SCRAPI for conformance testing and spec validation.

  • Chris: historically, once you advance on standards track, you do
    an interop, provide evidence of interop of multiple
    implementations, advance from proposed to full standards track.
    My tl;dr
  • Michael Richardson: that is correct, increasing commonality of
    publishing a 2nd information doc with test vectors in it. Likely
    makes more sense for TLS and key exchange protocols, but SCITT
    could do that with throwaway private keys.
  • Hannes: I've organized a few interop events, there is no process
    from the IETF point of view, but costs a lot in terms of time
    and resources.
  • Orie: we make cookbooks, like HKPE cookbook for JOSE
    workbook (in chat)
  • Roman: you request AD perspective, I appear. AD preference will
    be flexible. You can publish RFCs with test vectors, that's ok.
    You can have interop events, also ok. Think about goals and
    outcome (where you want results), and AD guidance and process
    will flex for you.

• Thomas McCarthy-Howe: works in VCON WG and sees similarities,
  tracking artifacts in conversations often for AI processing. I like
  this work.

Hackathon

• Contributions from remote folks (Jon and A.J.)

• Jon: SCRAPI

  • Keen to make sure SCRAPI does it's job well and quickly
  • Getting back to a position of solid good running code, proving
    the architecture is in good shape
  • Consistent with RFC3552, added security considerations

• Remote Signing by Corey at DigiCert

  • Copied the datatrails scitt-action, adding remote signing
  • Focused on the properties set in the protected header.
  • Moved the x5chain to the unprotected header
  • Had started with DIDs, got a lot of "feedback", and removed it
    to use X.509
  • Moving to the unprotected header allowed the header to be
    stripped, and reduce the size of the protected headers
  • Sounds like moving it out of the protected header has support
  • Made some opinioated choices to the properties
  • Made the kid the digicert guid. Could likely remoe it as we have
    the thumbprint

  • Hannes:

    • The security model is: when the issuer creates statements,
      how does that get to digicert?

  • Corey: the scitt-action has integration with the REST API

  • The analog of the CI/CD pipeline can create a hash of the
    artifact and sign it.
  • Orie: why -16 for the protected headers in the example from
    this system in Hackaton? Let's talk offline and work to correct
    that.
  • Mike Prorock: agreed.
  • Steve Lasker: during the build or other workflows, you're
    testing the software and then you want to make an attestation at
    that time and want to provision identity but not leave it too
    easily available in the build environment
  • Orie: concurs with the impressions of others at the queue
  • Orie: apologizes for all of Jenkins

• Exploration: election data use-case

  • Roman: excited about SCITT interest in different domains, but
    charter scopes us to software supply chain
  • Deb: as current AD, I'll say the same

Next Steps 30

• Call for reviews from WG chairs
  • draft-ietf-scitt-architecture-06
    • Corey Bonnell
    • Brent Zundel
    • Roy Williams

AOB Open Mic

• A.J.: There are emerging adjacent (non-IETF) efforts showing up
  (e.g. sunlight; litelog). Is there a way of
  comparing/contrasting/learning from these external things?
• Orie: There are a number of technologies that have evolved for TS in
  other services. (Key Trans, Cert). There's a lot of OSS work that's
  directly mappable to COSE Receripts. It would be awesome to see
  compatibility with the receipt draft
• If you're interested in doing interoperability with SCITT receipts,
  Orie is happy to chat about that mapping. Thank you to A.J. for
  mentioning the Open Source Community. Always happy to chat.

Wrap-up and Conclusion