IETF SCITT Virtual Interim Meeting - February 12, 2024

Attendees

• Orie Steele
• Steve Lasker
• Ray Lutz
• Hannes Tschofenig
• Henk Birkholz
• Rich Salz
• Carsten Bormann
• Jon Geater
• Robin Bryce
• A.J.Stein
• Greg Schumacher

Agenda

Interim catch up on status of work since -118, review issues.

Specifics:

• Status of architecture doc, recent PRs and open issues
• Status of SCRAPI, recent PRs and open issues.
• Readiness for submission for -119 (one month away). Do we need
  another interim in 2 weeks?
• Hackathon planning for -119

Existence is pain to a meeseeks.

• draft-ietf-scitt-architecture-05

Chairs re-iterate the motto: "Rough consensus and running code": let's
get to useful consensus on items that can be coded up, not seek
perfection on 2 sides of a polar debate.

Notes

• Registration & Initialization Policy: Henk: key before signature.
  The first thing you'd liekly want on the transparency service is the
  key
• Jon: Thought we landed the configuration aspect from 118.
• Steve: if a registration policy can be minimal, should we allow no
  registration policy?
• Jon: There's a good difference between no policy referenced, or
  specifically saying there is no policy. Advocating for keeping the
  registration policy reference
• Henk: Should this be part of SCRAPI
• Jon offers to draft a PR on the Initialization section to (mostly
  editorially) address the concerns for rough consensus on something
  that should be possible to get to SCRAPI and then to running code.
  In parallel A.J. will prepare a PR removing Initialization
  altogether. Then we'll see which the group prefers
• Steve: What are we going to persist, the signed statements, hashes,
  receipts
• Orie: The COMETRE draft discusses merkle trees, but it's really
  about getting receipts, supporting inclusion proofs. You have bytes
  coming in that are a signed stateemnt, and async returns a reciept.
  Anything else are adjecent services.
• Robin: Are we supporting the implementation that's in the emulator.
  Where you register a statement, get an event ID back, and at some
  point later get a receipt based on that identifier.
• Henk: The archtecture is silent about the latency (1 ms or 1 year).
  However, you can still get a receipt, with an undefined latency. A
  year later is still valid to retrieve a duplicative receipt.
• Jon: Pushing to SCRAP would be great.
• Jon: With the simplifications, the spec provides the building blocks
• Ray: if you have the receipt, how do you know it's a valid receipt,
  as opposed to a forged receipt.
• Jon: The verifiable data structures make it nearly completely stand
  alone. Depending on your threat model, you need some small number of
  facts.
• Ray: Brisbane is right around the corner, should we start planning
  for that now?
• Jon: never too early to talk about the hackathon. For 119, we'd like
  to have a candidate draft.

• Robin: Does the spec state the identity of the issuer must be
  verified live?

  • Henk clarifies not (on the grounds that the architecture can't
    really say anything about latency or internal mechanics of of an
    implementation). Coupled with Orie's responses on the mailing
    list about DID hang-overs we can probably simply remove this.

• Jon: Two PRs queued as a result.

  • A.J. to trim the initialization

• Are there other questions or concerns for getting to a last call for
  119.

  • Hearing none, meeting adjourned at 08:40