Re: [dispatch] IETF 116 - do you have something for DISPATCH?

[Christopher Allen <[e-mail]>]

On Tue, 21 Feb 2023 06:40:27 +0000 "Pengshuping (Peng Shuping)" <
[e-mail]> wrote:

> It's that time again - we're calling for agenda topics for our next
> meeting at IETF 116 (25 - 31 Mar 2023). No matter how big or small, if you
> have something you'd like dispatching or that you think will be of interest
> to the ART AREA, get in touch and get involved.
>

My name is Christopher Allen. I’ve worked with IETF previously as the
editor of the TLS 1.0 standard, but it’s been a number of years since I've
been actively involved with IETF — most of my recent standards work has
been with the W3C.

I’m now the Principal Architect of Blockchain Commons, and I would love to
join your agenda for Dispatching a new project.

Blockchain Commons is working on Gordian Envelope, a “smart document” that
supports the secure, reliable, and deterministic storage and transmission
of data such as seeds, keys, decentralized identifiers, and verifiable
credentials in a way that enables privacy while preserving structure.

We’ve submitted it as an IETF Draft (and plan to have -01 submitted before
the I-D deadline this month):

https://www.ietf.org/id/draft-mcnally-envelope-00.html

Here are some general thoughts:

PROBLEM STATEMENT: Current document formats don’t focus on a user’s ability
to use elision, encryption, herd privacy, and other methods to preserve the
privacy of their data in a granular way.

EXISTING INTEREST: Several companies have seen the need for these
capabilities and have been participating in regular meetings on the topic. (
https://www.youtube.com/playlist?list=PLCkrqxOY1Fbp-P1Yv-7gmu75i2QS2Z6vk)

INTENDED DELIVERABLE: We want to produce a revised draft with more
community input to ensure that the specification meets the requirements of
a larger community.

We’d like to present on Gordian Envelope to Dispatch and get the best
advice on how to move forward. We would obviously like to work with groups
who might want to make use of Envelope for its privacy-preserving document
format. We also think we have critical mass on the US west coast to justify
a BOF there and would like to see if Dispatch would be interested in
supporting that.

As part of our work on the Gordian Envelope, we embraced deterministic CBOR
(dCBOR), which is the foundation of Envelope. dCBOR is an optional variant
of CBOR that lies in the CBOR spec but hasn’t been widely used. Because
determinism is very important for the hashing that we use at the center of
the Envelope format, we’ve created and released what we believe are the
only reference libraries focused on dCBOR as part of our intersectional
work on the topic. We’d love to get advice from Dispatch on how to work
with other CBOR-focused groups who might be interested in the work we’ve
done to support the deterministic subset defined in the IETF CBOR
specification. (We’ve tried to contact some on our own, but we appear to
getting stuck in email filters.)

Finally, we would like advice from Dispatch on the best way to register our
cryptographic-focused CBOR tags used in Envelope with IANA, namely whether
we should do so now, or whether we should wait for later in the IETF
process.

Thank you very much for your advice and support. Please let us know of
anything else we can tell you and what else we’d need to do in order to
schedule a presentation with Dispatch.

-- Christopher Allen
   Blockchain Commons