Minutes IETF121: diem
minutes-121-diem-00

DIEM BoF 2

11/5/24

Martin Thomson and Russ Housley, chairing

DIEM BOF Agenda at IETF 121

1. Introduction [Chairs]

2. Summary of previous BoF and progress since [Chairs]

3. Perspectives on problem scope and terminology [Brian]

4. Charter discussion [Tommy]
   -- https://github.com/mstojens/diem-unified-charter/blob/main/diem-unified-charter.md

5. BoF questions [Chairs]

Russ: boilerplate

Martin: last BoF we went over use cases, so that’s done. This discussion is for narrowing down the scope of the potential work; is there one scope we can agree on? Today’s agenda is specifically about WG scope/charter.

Brian Haberman: “Perspectives: Scope and Terminology”

• How distinct?
• Lots of building blocks already available
• Chat: could be a lot of overlap with existing WGs

Open mic: up to slide 5 for Brian, scope & terminology bash

Michael Prorock: overlap w/ SPICE, incl cross-border links; doesn’t mean we shouldn’t have a WG, just need to be aware of those overlaps

Brian: common definition?; ack the point re: overlapping WGs

Ted Hardie: “working backwards from solutions”-- define relationships; define emblem in terms of attestation that validator might use

Juan-Carlos: legal definition required/assumed?

Brian: not nec’y specific to law

Martin: Does a DE nec’y include protection in law?

Bill Woodcock: no reason to require that any more than http is about websites about cats; there are use cases that don’t; it’s a communications protocol for information issuer->validator about an asset”-- what information needs to be communicated? – a bundle of records about an asset, incl bindings and maybe other stuff; no more prescriptive needed

Nick Doty: describing physical or digital assets? How different are they? [STW: remote, some noise, not sure of this] – instead of information of all kinds, protection from digital action

Rohan Mahy: def of an asset: BW is right it could be anything but a WG needs a narrower scope; would avoid the term “protection”; limited set of bindings for digital asset; support for diem to go forward with multiple use cases and small scope; charter should say other WGs can work on other use cases, but this WG will do the more limited thing.

Brian: [?]

Rohan: signal specific treatment that applies to this object, no need for special casing

Tommy Jensen: scope incl recognition by law; we don’t want anything we invent to inform/constrain later behavior based on that. Suggests defining “sub-scopes” of useful types of DE

Warren: (slide 5): doesn’t need to be treatment by law, but needs to include spec of how it’s treated

Micahela (Article 19): concerned about scope; hard to untangle attributes w/ respect to impact on users of how attributes are constructed; not just verification/authentication; “aimed at a very particular type of asset”

Brian: exactly why we’re trying to narrow use cases to be handled; cf international humanitarian law; what’s the unique niche for DIEM and what normative frameworks might help?

Mike Christie (“international press”): not technical; user perspective: leave data to be carried very open and flexible

Martin, summarizing: nobody said digital is an important limit; question about how much to lean on legal definitions and protections; what *are* the important limits?

Stephen Farrell: “digital” in “digital asset” is irrelevant; Martin agrees

Nick Doty: reiterates dramatic difference between physical and digital

Brian (paraphrasing Nick): different attributes here; they may be specific to use cases, so we have to be careful; there are also other functions that may be specific to use cases; Q: is there anything to specify about physical vs. digital besides making it part of the bundle of attributes/data?

Nick: what makes it an emblem is the metadata, and generalization is too big for a WG

Arnaud Taddei: how can a digital emblem ensures that it is visible from any attack so that the attacker has a chance to realize it is crossing a red line?

Tommy Jensen: potential charter discussion found 3 areas: format, source of authority are probably generic for discovery/communication; but distinctions are too big for one solution or one WG for different attributes for distinct types of entities (history, identity of validator, etc.)

Dennis Jackson: abstract Q, doesn’t love focus on terminology; instead “what should this WG do?”-- slightly different, lots harder. Any of the def in slide 5 is fine, but know what we mean; don’t base charter or other decisions on def of DE

Rahel Fainchtein: too much focus on terminology makes things over-complicated

Rick Wilhelm: perspective on unifying digital and physical; we probably already have such use cases, e.g. drones operated by media in war zones; how to treat DEs and objects is conrext-dependent, so not everything we need to spec may be in the DE itself.

Michael Rosa: [STW: hard to hear] leaning away from overspecifying [?]

Jessica Krynitsky: what line crossed has consequences? CF SPICE WG, with similar issues; need to specify how this asset should be treated

Brian: is it signaled or encoded in attributes? How much dependence on law/normative framework?

Jessica; not clear how much detail to put into the emblem

Nalini Elkins: so far assuming we’re assuming good will; Martin refers back to BOF 1

DKG: question of “what is a DE?” is a distraction from the work; a WG should address protective vs. audit; digital vs. physical; should be talking about indicator ,with clear scope, of protective information without the validator revealing itself. Protective, digitally scoped use case is the place to start if we want to finish something

Ronan: reminder re: identify at the mic! Also: more people seem to want to include physical assets, but good thing to poll

Samit D’Cunha: ICRC; this matters to us; the key info being shared is that the object is protected (somehow) and needs to be respected.

Brian: one bit to convey that yes the asset is protected

Samit: display of emblem is the key

Martin, summarizing disagreements in polls:

• Y \= physical & digital; N \= digital only (nature of the asset)
• Is “protected in law” essential for our scope?
• Rohan rephrases as “only cases codified in law”
• Y \= codified in law; N \= not necessarily coded in law”

Proposed Charter

“Introduction Section”

Tommy introduces potential charter (pp 7-8 in his deck)

Previous discussion did touch on whether the scope must be narrow or a broader one is the only way to get value

Russ: proposed charter text has been out for awhile; issues with Intro section?

Rohan: unless we establish a scope of use cases, we’ll never establish requirements and never finish; need a “bucket” of use cases to define a scope.

Peter Koch: boundary around scope strong enough to push back extra complexity?

Orie Steele: current charter text: looking for revisions to text and/or indicators of consensus

Roman Danyliw: clarify whether “success of the WG is predicated on draft-haberman”

Arnaud Taddei: current introduction very difficult to read, 1st sentence 'ok' but legal aspect difficult to read. 2nd and 3rd sentence have a logical issue especially the 2nd one. The flow doesn't work

David Somers-Harris: will anyone actually use legal definitions if the WG uses them, or do we enable those attributes and laws will follow

Ted Hardie: totally different reading than Arnaud; if the driving use case is that emblems already recognized and we’re expanding scope to include other attestations vs. specifying further; rewrite final sentence of Intro

Arnaud: about "recognized under international law" and a "cyber mark" coming back to the mention of the EU Cyber Resiliency Act (CRA) will be very difficult to implement if at all; back to the flow, what are we trying to achieve? we are willing to do 2 things: protection and audit but none of these points are represented in the introduction. Requesting the introduction to be more direct to those points.

Jim Reid: +1 Peter; this should be narrow and straightforward if it’s to be completed or used.

“Problem Statement” Section

Nick Doty: Still too broad, should make the WG narrow it as first item

Roman: not sure how this holds together

Michael Rosa: implicit requirements here?

Arnaud: incomplete, e.g. where is audit function?

“Goals” Section

Tommy Jensen (as proponent): text here notes that 3 areas of work (ID’d later, Goals) will depend on context; if some of that work is done before the WG charter, a lot of this text goes away

Eric Vyncke: current text is limited to legally defined emblems?

Ted Hardie: “discovery mechanisms” needs specificity: how to bind and how to access?

Roman: Consensus question under first milestone: do we mean IETF consensus? If not, what consensus

“Deliverables” Section

Henk Birkholz: [?? remote]

Kathleen: disagree with Henk, doesn’t matter where your keys come from

Roman: Data model and validation fit in one standards track doc?

Eric Vyncke: use cases first vs solution later?– prefers to start with use cases

Andrew Campling: agree with Eric, solutions w/out use cases seems “bold”

Felix Linker: reinforces limited use cases if we’re to ever finish. Why ISSE[??] came to the IETF in the first place: complex space, “could generalize into oblivion”

Arnaud we are missing the big action, where is the red line crossing? where is protection and audit? how good look like: a "naive attacker" sees the emblems and backup. how bad looks like: a nation state on purpose sees the red line and crosses the red line. The deliverable could represent that better.

Tommy Jensen: “we need a WG we can dedicate to doing this, it’s ok if the first milestone is scope”; agrees use cases & requirements should be first milestone, focus on which ones actually have different requirements. We can make deliverables more specific but should do it now.

DKG: no description of “the emblem’s scope” here and it’s an important omission; “ICRC emblem on your sleeve applies to person, not the arm”; what exactly does the emblem refer to?

Samit: ICRC conference last week decided this digital emblems thing is important and must be pursued

Ronan: limited relation to physical objects but focused on digital; get a use case that the largest number of interested people can agree on is a good place to start.

Michael Rosa: now we’re talking about data in transit vs. digital object vs. physical object; is that also in scope?

Michael Christie: need to include distinctions: some have central authorities, some don’t; media protect photos, somebody else protects servers

Brent Zundel: we’re over-complicating this; just “a way to digitally display a marker” is the main deliverable

Orie Steele: + 1 Roman data model & discovery are linked and should be addressed together

David Somers-Harris: people struggling to understand what’s required for what? Govts already know what protected assets are and that there are consequences for attacking them; what goal does this work really meet?

Housley, summarizing: start with international humanitarian assets, expand scope from there if needed/wanted

“BOF Questions”

Martin: does the narrower scope need to be specified in the charter, or is it okay to make that the first deliverable?

Roman: +1 Martin

Brent: broader charter, but a place to start

Dennis: extensive discussion and support for narrow charter is a good argument for a WG; narrow one is still pretty complex

DKG: narrow charter is in fact still pretty complex, and whatever we create could be used against the owners of the assets too; let’s start with protective use case and only

Stephen Farrell: disagree w/ last 2; broader and more flexible charter is better bc so much of the issues are not specific to any use case

Arnaud: agrees to narrow the scope to Red Cross only use case but a broad charter to make sure we have a good design for the longer term including protection and audit

Rohan: bindings of physical assets can wait until use cases are reasonably well-firmed

Bill Woodcock: pushing back on effort to narrow the charter; open, not specific to individual organizations, communications

Martin: main question is whether to start with a narrow charter and milestones for narrowing it to specific use cases?

• Y \= narrow charter; N \= broad charter & narrow first deliverable
• Practical version [Richard Barnes?]: is a recharter necessary before expanding use cases?

Now on to BOF questions; “is the problem well understood?”

• split

Is the scope well understood?

• Also split

Is the IETF the right place?

• Paraphrase as “continue discussion?”
• Strong support
• Eric doesn’t want to take it to the IESG yet
• Housley suggests keep working on the charter on the list and see if progress occurs

Felix: other uses cases besides ICRC might already be in scope for other WGs