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.
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