Diem IETF 124

Co-chairs:

• Rohan Mahy
• Tommy Jensen

Notetaking:

• Daniel Kahn Gillmor

Agenda

Requirements Document Changes - 20 minutes (Rahel Fainchtein and Felix Linker)

• earlier Document
• WG-adopted document
• Working through github.

PR: Charter definitions

#1

Felix Linker:

• this copies text from the charter; cut this out, and define a few
  terms for bearer and validation.

Rahel Fainchtein:

• The goal was to make things clearer even without the context from
  the charter.

Orie Steele:

• Charter text doesn't need to be copied verbatim, use text that the
  WG comes to consensus on

Rohan:

• maybe we can move stuff from the charter in here, and use it as an
  opportunity to workshop those definitions.

Andrew Campling:

• it seems weird to define things but not to define the thing you're
  trying to work on.

Felix:

• i'm not going to block on this, it seems messy to me, but if there's
  no mess to others, let's just merge it.

Rohan:

• Objections to merging as an initial definition?

Felix:

• i don't want to spend 10 more cycles refining and iterating on this
  definition. we need to get to the followup work.

Alison:

• i like having the definition. it's a good working definition. if it
  gets refined as we refine the use cases, that's ok.

Conclusion: no one is blocking merging #1

Simpler phrasing of undetectable validation

#4

Felix:

• we want to make sure that the parties who didn't get an emblem can't
  detect an attempt at validation

Andrew Campling:

• why not just drop the identity of the party. Why don't we just say
  it's not discoverable by anyone.

Felix:

• If you scope undetectability to the world then you'll never achieve
  it. Maybe we can say that the best case is that the verification is
  detectable to no one, but we might havee to make some tradeoffs.

Allison Mankin:

• maybe we can switch out the requirements for bearers, authorizers,
  and issuers. Can we enumerate the use cases? if we take them out
  entirely, we might miss some cases.

Samit D'Cunha:

• agree with Andrew

Andrew:

• maybe we can call this "Oblivious Discovery" as a concept

Felix will follow up on the PR.

IHL Use Case

#5

Felix:

• we need an actionable list of requirements, we need to be able to
  invite stakeholders to see whether they actually make sense. the way
  to do that is fleshing out the use cases. This is an example aiming
  at #11

Andrew:

• we should focus on the priority use cases. In particular, iirc, Red
  Cross/Red Crescent should be prioritize.

Allison:

• happy to see digital assets included here. I think this is a
  reasonable starting point for the use cases that Andrew Campling was
  talking about.

Outcome: with the lack of feedback, we're not sure what to do. Felix
should followup on list to draw attention.

Security Considerations

#7

Allison:

• There really are some security requirements already. I think we can
  refer to those things.

Rohan:

• With chair hat on, we'll need a more detailed security
  considerations section, even if it points to or repeats specific
  other parts of the document. Can we make an outline?

Tommy:

• Should we not accept this PR? should we trade it for an outline?

Rohan:

• The outline makes it clearer what needs to be done.

Allison:

• I'll do a new PR so that we have an outline.

Outcome: Allison will revise this with an outline

Acknowledgements

#8

Orie:

• I don't disagree with this, i'm just hoping to get people's consent
  before they're included in the datatracker.

Outcome: this will be merged, but editors should confirm from folks who
are named before submitting to the datatracker

Requirements Open Issues - 60 minutes (Open mic)

Bearer and assets

#6

Andrew:

• bearer is a legal thing, and an asset is a physical(?) thing

Lars:

• if they're the same, we should use one term.

Stuart Card:

• I'm the bearer. My passport is the asset, which is distinct from me.
  It seems like they're distinct.

Daniel Kahn Gillmor (dkg):

• maybe all bearers are assets, but not all assets are bearers? (e.g.
  an asset without an emblem isn't a bearer)

Allison:

• there could be groups of assets and the bearer might be the grouping
  of assets. maybe the bearer is a person, but the asset is the thing?
  We should write it down explicitly though.

Rohan:

• a wetland is an asset but isn't likely to be a be a bearer

dkg:

• i think we're at least as interested in assets that don't have an
  emblem, because that's what the attacker/verifier is trying to
  target.

Andrew:

• a physical asset doesn't have an emblem.

Rohan:

• the first thing that we do is digital emblems. We didn't say that
  there is no such thing as a physical asset that might want an
  emblem.

Felix:

• Footnote: "bearer" sounds a lot like "emblem issuer" which we
  already have in the document

Allison:

• I now think we should keep them separate, so that we can keep in
  mind the non-bearer assets. we don't have enough attackers present
  among the WG.

Outcome: Tommy says there seems to be a consensus that they're distinct,
but we're not sure what the exact distinction is.

Felix:

• I don't have a strong opinion, just want to avoid confusion.

Stuart Card:

• Black's law dictionary: a bearer is a person who physically holds a
  document that identifies that the bearer is entitled to something.

Tommy:

• so the person is the bearer, and the document is the asset?

Rahel:

• This feels a lot like the term "subject". The distinction is
  important, because it's a question of where the authorization is
  being placed or issued.

dkg:

• I think in Stuart's example, the document is the emblem, not the
  asset.

Rohan:

• somehow we need to characterize the distinction between the entity
  that has legal opportunities here and the things that the emblems
  are attached to.

dkg:

• what about "authorized parties" (as in the subject of the
  "authorizing parties"), and those authorized parties hold assets,
  and some of those assets are bearers.

Jim:

• I'm concerned that we're ratholing here a bit. let's not pretend
  that we're lawyers. please send text. and let's get some useful
  definitions.

Samit:

• to my mind, the hospital is the bearer, but their equipment (and
  their staff) is the asset. In the passport example, the passport is
  like the emblem. the individual is the asset. the authorizing party
  is the state that issued the passport. I'm volunteering to propose
  text, if someone can show me how.

Andrew:

• Because it's very abstract still, we maybe need to review each use
  case to ensure that they're using the terms in a sensible way.

Resolution: Samit, Allison and Natasha (and others) will try to
contribute text to clarify these distinctions.

5-author limit convention

Orie:

• as AD, IESG doesn't like going over the limit. when there's this
  many editors listed, you miss the opportunity to distinguish between
  editors (on the one hand) and authors (on the other) . Authors
  should be listed in the acknowledgement section. Please respect the
  limit.

More discussion?

Rahel:

• fleshing out use cases: can we get more input on the use cases?

Andrew:

• Did you agree with my earlier comment that we're prioritizing the
  small subset of use cases?

Rohan:

• no, there was never any agreement on that before, but mayb there
  could be consensus to do that.

Allison:

• might be a need for forensic collection of digital emblems,
  sometimes they need some kinds of timestamps, etc. can we put that
  in to the draft?

Felix:

• there is something in §4.5 on "proof of presence" -- it's not
  adequate to address it yet, but that's where it should go. please
  help us get adequate text there.

Jim:

• i thought when we started this group, we were going to focus on
  those use cases.

Tommy:

• our consensus from previous WG was to focus on scenarios which are
  fully within the charter (digital, using DNS). This did not manage
  to reach consensus on focusing on humanitarian use cases.

Felix:

• IESG review for this document?

Orie:

• as an AD, a use case doc doesn't need to go all the way through the
  IESG. As an individual, don't spend too much time in the use cases
  doc.

Felix:

• i want to make sure that the use cases are useful, because they let
  us measure the success of the ultimate document.

Rahel:

• please be specific about what "humanitarian" means, because some use
  casees (like marking aircraft as civilian) could be "humanitarian"
  though they aren't applicable to ICRC

Tommy:

• as an individual: please specify use cases by name, rather than by
  category, because we might not all agree on which cases fall into
  which category.

Samit:

• agree with Tommy

Stuart:

• thank you for the ICAO use case. in WWII, the "friend or foe" was
  created. ADSB is a similar thing. ICAO needs to be able to do this
  as well. there are many civilian use cases that need a digital
  emblem.

Rohan:

• do you have a contact that we can talk to with this requirement?

Stuart:

• it's right here in Montreal, but as an international treaty
  organization we probably can't cut through the bureacracy to get an
  official statement, but i can try to get some unofficial feedback.

Allison:

• A19 used to do some press safety work, i don't know whether they're
  here or not. We had a roundtable where that was discussed, but that
  case might be useful. i'd like to ensure we keep that in. Marshlands
  also has a designated science and tech committee that we might be
  able to get involved. ICAO might have something similar, which makes
  non-binding comments.

Samit:

• in the 1970s ICAO developed standards for lights for medical
  aircraft. in Annex 1 of additional protocol 1. digital
  infrastructure of medical aircraft would also be covered under
  international humanitarian law.

dkg:

• chairs, please note the document lineage ("replaces") in the
  datatracker is broken. draft-feinchetine… should be in the history
  of the adopted draft.

Rohan:

• github redirects should be working, but i agree the datatracker
  repalces info is broken. i'll fix that in the datatracker.

Cory:

• from freedom of the press foundation, we don't currently see a use
  case for this.

Samit:

• how do we approach verifiers? ICRC was able to have ADEM tested by
  NATO cybersecurity command, so we have some progress on that front.
• the international committee on military medicine sees huge value in
  this work, and is following the discussion and wants to share it
  with their offices. we hope to share that letter soon.
• world medical congress (civilian, not military) invited VP of ICRC
  to speak about digital emblem work.

Orie:

• thanks for the work here, it's great to hear about active work.
  remember that the mailing list is a good place for that kind of
  technical discussion as well. getting the technical stuff rolling on
  the mailng list in parallel to this document work is perfectly fine.

Closing and Summary - 10 minutes (Chairs)