Input documents to the requirements:

draft-diem-fainchtein-use-cases
draft-linker-diem-requirements

Preliminaries - 5 minutes (Chairs)

Welcome

Note Well
Request for Scribe
Introduction - 15 minutes (Chairs)
Note takers: Daniel Kahn Gillmor and Sarah Jennings
co-chairs: Tommy Jensen and Rohan Mahy

We are a Working Group

Scope and Our Chartered Milestones
Focus on Requirements
Next Steps
Chairs - Expect use cases and requirements doc to be relatively
comprehensive and not restricted to the charter. Prioritisation will
take place as the protocol specification is worked on, and the protocol
specification will be constrained by the charter.

Requirements Presentation - 40 minutes (Rahel Fainchtein and Felix Linker)

Discussion about Requirements - 60 minutes (Open mic)

Jim Reid - good starting point for work. Concern about trying to have
comprehensive list of use cases which could delay things. May need to
triage based on scope. Preference to split requirements docs for each
use case and compartmentalise work.

Andrew Campling - Charter requires adoption of requirements by July 25.
(Note from Chairs, that is not absolute). Slide 14 - is the implication
that anything below the line would not be progressed in the short term.
Answer - yes.

Éric Vyncke - just two drafts, or a third? Rahel says a third draft.
If there are requirements that conflict, what do we do? Felix: i see a
tension between undetectable validation and selective disclosure.
What laws will we focus on? Will we handle press? Rohan: there are laws
that govern special treatment for press in some locations.

Rohan: selective disclosure: depending on what i need to reveal and who
i want to reveal it to, i might scope the emblem differently, but the
charter probably shouldn't use the term "Selective disclosure" because
that refers to a specific technology. there may be other ways to meet
that need.

Éric Vyncke - How will we map between laws and certain requirements?
Felix - We will engage relevant stakeholders.

Samit D'Chuna - Where did the requirements come from? What stakeholders
did you speak to for this? Felix - ICRC has done engagement and
reported. Blue Shield - have spoken to UNESCO, would want more input
from them. Rahel - RAMSAR have reached out to, but hoping for more
input. Tommy - encouraged authors to be brave with info available. The
goal is to bring more people to this discussion.

Chantal Joris - Concern about including press as use of emblem may make
them a target. There is no conflict that Article 19 has seen where
freedom of press has not been targeted - risk assessment of including
this use case needs to be done. Rohan - Had presentation from former
Reuters head of protection unit who advocated for this work. Press are
not under obligation to use this, and they have asked for this use case.

Chantal - extensive stakeholder consultation is needed to know if this
would actually be protective.

Tommy - Appeal for text suggestions on third draft. Agreement that more
representation is needed.

Roman Danyliw - Red Cross, Blue Shield and press are all the same emblem
affixed in different places. For the Ramsar and OPCW use case, is the
metadata dyanmic.
Felix - yes, that's an accurate distinction.
Rahel - for RAMSAR/OPCW the DNS might not be the best way to search for
this. There might be some way to do a lookup to some DNS label

Roman - for the additional metadata cases, is the additional data in the
emblem, or will it be something that the emblem points to?
Rahel - will define that for each use case when it comes to protocol
specification, but want to allow space for some bridging mechanism for
more info than will fit safely in a DNS record.

Richard Wilhelm - in
https://www.ietf.org/archive/id/draft-diem-fainchtein-use-cases-00.html#name-international-committee-of-
it only contemplates a digital emblem for webservers/personal devices,
but doesn't include marking of physical assets. doesn't a real-world red
cross emblem protect my laptop from being smashed as well?

Samit - For physical assets, we do put the emblem on it. But you don't
need the emblem to protect the asset. You put it as closely as possible
to make the connection meaningful.

Orie Steele as AD requests sticking to the charter. i don't want to hear
a rechartering discussion right now.

Bill Woodcock - Support for including people and objects above the line
(i.e. in scope). Emblem needs to have capacity for variable data.

Nick Doty - Found the selective discolure definition confusing. In
credentials work it is about only revealing certain parts of a document.
That's different to not always presenting, presenting different things
to different people. Prefer we don't use overloaded language and
describe the requirement in more detail.
Felix - Thanks for feedback, will incorporate.

Alex Rosenberg - Want to see the line come down and include person,
place and thing. Well formed standard would be extensible - we're
building a family of RFCs. Rahel - noted, will move scope.

Leif Johansson - Argue to not include people in scope as the press use
case is diverse and there are clearly many perspectives. Treat the press
use case as a digital credential issue and work with the spice wg.
Rohan - we have a divided community that have different views on
identifying press, do you see an issue with doing work that serves some
portion of that group?
Leif - need universal concept of press protection, so don't think it's
ok to do work that works only for some.

Leif - a digital emblem applied to a physical object is potentially a
tracking mechanism.

Rohan - there is a specific requirement to be able to turn the emblem
off for the press use case in the draft.

Simone Onofri - consider malicious use cases in the document like
mapping high level targets easily using emblems.

Felix Linker - of opinion that line should not move down. Not too hard
to find place in the DNS for place markers, tying to a person or object
is much more complicated and doesn't match initial scope of this wg.

Chantal Joris - hard for the average journalist to make an informed
assessment of what a digital emblem will mean for them. Need to do
proper consultation with affected journalists, not just present finished
emblem work.
Tommy - Need to bring those people here to join this conversation. If
people know of those who could contribute who face barriers, raise it to
the chairs' attention.
Rohan - they can make mailing list contributions without facing barriers
like travel costs.

Jim Reid - if we talk about emblems for people we will raise data
protection concerns, something to be aware of. Bad actors issue is
relatively easy to solve - if Red Cross is responsible for issuing
emblems for their own agents, then they can do the validation required.

Leif - Prior experience with difficulties getting end users into the
room leading to wg closing (tigress). The burden is on IETF to get those
people into the room, if we can't should we be doing this.
Rohan - In agreement.

Consensus Questions about Requirements - (Chairs)

Rahel - one additional idea worth considering is whether some form of
ledger is needed to verify if a particular emblem was visible at a
particular time for forensics purposes.

Loic Kliemann - why isn't critical infrastructure not included?
Rahel - set of use cases is not comprehensive. Critical infrastructure
could have a digital emblem.
Felix - Intend to add dangerous forces emblems to the third draft which
marks, for example, nuclear plants.
Roahn - had even less stakeholder engagement for some use cases than the
ones presented, so this is just a sample.

Nick - Querying by geographic location seems like a large universe of
work on discovery. Would be a lot more work for the group, so should
think about that while describing this doc.

Bill Woodcock - Support for including civil defence and dangeous forces
emblems.

dkg - worry about the document overreaching the charter and derailling,
so we should prune where we can.

Samit - agree with dangerous forces being included, also civil defense.
Focus on red cross, crescent and crystal stems for prior big
multi-stakeholder consultation, but agree other uses cases should be in.

article 56 of section 1 -- civil defense is article 66.

Tommy - do people want to split by use cases and have multiple
documents, or just one big document.

Andrew Campling - Prefer multiple shorter documents.

Éric Vyncke (not as AD) - Prefer one large document describing use
cases, then set out requirements at the end, having consistency between
all the drafts. It is hard to ensure consistency if requirements are not
fixed when writing the use cases and vice-versa.

Gurshabad Grover - are the use cases defined by things that have
specific protection under international law?
Tommy - Exclusion is based on the charter, which includes things that
are not protected by international law.

Roman - Prefer one use case document, try to document some subset of use
cases and then move onto the actual protocol work.

Erum Welling - agree with having one document setting out use cases -
helps to see patterns and similarities, giving better list of
requirements.

Jim - Happy to go with the flow.

Orie (as AD) - first deliverable is constrained by initial scope,
suggest focusing use cases document around things that are in initial
scope to help make better progress.
Rohan - if we have a use case for Ramsar and some number of requirements
are covered by scope and some are not, would that be ok.
Orie - interested in the part of those requirements that overlaps with
the scope. Don't want to read document that has a lot of elaboration of
details not in the initial scope of the charter.

Andrew Campling - the phrase minimum viable product comes to mind.

Rahel - question to those who say it should be limited to the scope, how
would they balance that necessity vs the priming effect of working on a
certain use case and having a pre-conceived notion of the structure the
emblem should take. How to account for that?
Orie (hat off) - IETF good place for building on existing widely
deployed protocols and using the knowledge in the community. Need to
lean into that strength - the initial charter focused on what the IETF
has expertise in, the DNS. Focus on use cases that are tied into the
DNS. The question of whether this is a pointer or carrying attributes,
that's the kind of question we need to work through and think about.
Roman - Concerned that we're over-generalising the solution and so
overcomplicting it, and may not get to the early, simple, better
understood use cases for the technologies we understand well.

Erum - if we're brainstorming, we shouldn't limit ourselves and should
think about wider use cases.

Leif - Keep it simple, do something that is tractable and that we can do
with the expertise in the room. Solve some problems well and then see
where we are.

Rohan (hat off) - clarifying point - use cases should be able to define
what is required for an emblem type, and then address or not address it.
If a mechanism doesn't fit a use particular case, we can address that
use case later.

Questions

Q: Can we limit the emblem types (use cases) we consider to ones where
we can get stakeholder participation?

• Yes
• No
• No opinion

Bill Woodcock - if we say that participation a a single meeting but no
further participation means views can be disregarded, we have moving
goalposts.
Tommy - want to see list involvement
Bill - If people feel frustrated they are not being listened to, we have
an issue
Jim - If there's drop off in participation from certain groups, chairs
should follow up on that

Result - majority yes

Bill - voted no as don't want active participation to be a barrier to
consideration
dkg - only hearing from bearers, not attackers
Bill - had members of military forces in the meeting previously

Tommy - (action for chairs) to continue working on getting more
participants involved in the work

Avri Dora - voted no based on language of 'can we' - have to be aware
that there will be groups who are not engaged. If someone comes through
with an opinion we have not yet heard, we cannot say 'too late'

Felix - every use case reflected in the document needs to have a
reasonable case for being evaluated by relevant stakeholders. Attackers
- have discussed trying to reach out via various challenges, know its a
weakness, are aware and working on it.

Samit - Mandate of ICRC includes confidential bilateral dialogue with
range of actors but cannot speak on behalf of attackers. Explore having
public statements of support for work.

Andrew - if there is little engagement from a group, we should be
cautious about doing this work as there may not be uptake.

Bill Woodcock - Don't understand fixation on individual users. HTTPS,
etc, aren't special-cased based on whether they're used by the ICRC or
other agencies.
Rohan - given this is governed by laws, we do need to understand those
requirements.

Q: Should we attempt to include a concise but full set of requirements
for an emblem type that has partial support in the initial charter?

• Yes
• No
• No opinion
  Majority yes

Clarification from chairs - assuming you can still do something useful
with the partial set of requirements.

dkg - think it's excessive to make a full description of something that
only has partial support in the charter.
Clarification from chairs, take two - as an example, if a use case has
five requirements {1,2,3,4,5} and only {1,2,3} are in charter, but
implementing {1,2,3} provides functionality even without {4,5} being
implemented, should we include it? We are not asking about use cases
where {1,2,3} do not provide value independent of {4,5}.

Roman - what do we do with the use cases and requirements that we're not
servicing?
Rohan (as an individual) - avoiding specific technology bias by asking
the question in the beginning, rather than after we've started building
something. Knowing wider range of requirements allows some future
proofing of design work.

Felix - the initial scope of the charter is fairly broad and many
requirements are common across emblems.
Rohan - the wetland emblem is an example of what we clarified: it has at
least one requirement that is out of charter, but would you want to see
it included?
Felix - yes, but would benefit on some limit on use cases included

Roman - have a lot of concerns about scope creep. Leading to shadow
requirements which acts as an impediment to progress.

Mirja - Hard to talk about this in abstract. Concentrate working group
work on things that are fully in scope and move on. If you reach
agreement on other use cases at the same time then that's good, but
focus for now.

Q:The working group shall concentrate discussion on requirements covered
by the initial scope but will not prevent inclusion of out-of-scope
requirements which are non controversial

• Yes
• No
• No opinion

Large majority yes

Tommy, summarising: Definitely including those use cases in scope from
the charter, opportunisticaly going for those out of scope.

Orie as AD: Thanks chairs and see you all on the mailing list focusing
on the drafts and our working group progress!