Markdown Version | Session Recording

Session Date/Time: 07 Nov 2025 19:30

DIEM

Summary

The DIEM working group held a working session focused on its adopted Use Cases and Requirements draft. The primary goal was to make progress towards a "call ready state" for this document, which is a prerequisite for subsequent architectural work. Discussions revolved around refining terminology (digital emblem, bearer, asset), clarifying security considerations, addressing the use of GitHub for contributions, and reaffirming the scope of use cases. Several pull requests and open issues were reviewed, leading to specific action items for the editors and a renewed call for community contributions in the form of suggested text. Updates on external engagements and prototype testing were also shared, highlighting real-world application contexts.

Key Discussion Points

• Logistics: Chairs Rowan May and Tommy Jensen welcomed participants. DKG volunteered as note-taker, and Allison volunteered to monitor the Zulip chat. Standard IETF Note Well reminder was given.
• Agenda Focus: The session was dedicated to a live working session on the adopted working group draft, "DIEM Use Cases and Requirements." The chairs emphasized the goal of getting the document to a "call ready state" with working group rough consensus before proceeding to the architecture document.
• GitHub Contribution Workflow: Encouragement was given for contributors to create a corresponding GitHub issue for any pull request (PR), even for minor changes, to facilitate triaging and discussion.
• PR 1: Adding Charter Definitions:
  • This PR proposed adding definitions for "digital emblem," "bearer," and "validation" by copying text from the charter.
  • Felix expressed concern that the charter's "digital emblem" text wasn't a true definition and feared prolonged debate.
  • Rahel clarified the motivation was to provide a lasting reference within the document, independent of charter changes.
  • Ory Steele (AD) noted that the working group is not strictly bound by charter wording if better terminology can achieve consensus.
  • A sense of those present indicated a preference to merge the definitions as an initial starting point, acknowledging they could be refined later. Andrew Campbelling specifically supported defining "digital emblem" if other terms were defined.
  • Decision: Merge PR 1 as an initial set of definitions, with the understanding that they are subject to future refinement based on suggested text.
• PR 4: Simpler Phrasing of Undetectable Validation:
  • This PR aimed to refine the "undetectable validation" requirement, changing "bearers" to "potential bearers" and focusing on bearers rather than "all parties" to avoid assuming an internet threat model.
  • DKG questioned why "issuers or authorizing parties" were removed, suggesting undetectable validation should apply to them too.
  • Andrew Campbelling suggested focusing on "malicious parties" and the concept of "oblivious discovery."
  • Tommy Jensen noted the "may require" language provided flexibility, and suggested re-including other parties with a modular approach.
  • A sense of those present indicated a desire to retain all previous parties (issuers, authorizers) and incorporate the "potential" aspect. No specific decision on merging this PR, editors to consider the feedback.
• PR 5: Details on IHL Use Case:
  • Felix introduced this PR as an example of adding more detail to use cases, aiming for actionable requirements and stakeholder evaluation.
  • Andrew Campbelling suggested focusing this energy on previously agreed priority use cases (e.g., Red Cross/Red Crescent) rather than all use cases simultaneously.
  • No strong signal from the room to merge or leave unmerged. Discussion encouraged to continue on GitHub and the mailing list.
• PR 7: Removes TODO in Security Section:
  • Allison proposed replacing a "TODO" placeholder in the security section with initial text.
  • Rowan May (Chair) suggested that a comprehensive Security Considerations section, including an outline, would be needed for Working Group Last Call (WGLC).
  • Decision: The PR was not merged. Allison volunteered to propose a new PR with an outline for the security section.
• PR 8: Add Acknowledgments Section:
  • Allison proposed adding an acknowledgment section.
  • Ory Steele (AD) reminded the group to obtain consent from individuals before listing them in acknowledgments, referencing IESG guidance.
  • Decision: Editors should manage consent for acknowledged individuals before submitting to the data tracker.
• Issue: Bearer vs. Asset:
  • Discussion on clarifying the difference between "a bearer of a digital emblem" and "an asset that bears a digital emblem."
  • Andrew Campbelling suggested a bearer is a legal entity, and an asset is a physical/virtual thing.
  • Stuart agreed there's a distinction, citing a passport as an asset and himself as the bearer.
  • DKG noted that all bearers might be assets, but not all assets are bearers, and the group should also consider assets of non-bearers (targets for attackers).
  • Samin Isirsi (lawyer) provided detailed legal context and examples from IHL (hospital as bearer, ambulance/staff as assets, state as authorizing party), emphasizing the importance of these distinctions for stakeholders.
  • Decision: Editors require concrete input. Samin, Allison, and Natasha volunteered to propose text to clarify the distinction between "bearer" and "asset" terminology.
• Author Limit for Documents:
  • Discussion on respecting the IETF convention of limiting authors to five.
  • Ory Steele (AD) recommended respecting the limit and making a clear distinction between document editors (integrating feedback) and contributors (substantial text), utilizing the contributor and acknowledgment sections for additional credit.
  • Decision: Editors to limit co-authors to five in future revisions submitted to the data tracker, using the contributor section for others.
• Use Case Prioritization and Scope:
  • Andrew Campbelling reiterated a past sense of the room to prioritize a small subset of use cases, particularly humanitarian ones, and defer others.
  • Tommy Jensen (Chair) clarified the consensus from the previous meeting: "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."
  • Ory Steele (AD) advised against spending excessive time on the use cases document, encouraging the group to move towards proposed standards, and that the document isn't required to go all the way to the IESG if it serves its purpose for the architecture document.
  • Rahel cautioned against overly narrow definitions of "humanitarian use cases," pointing out that civil aviation or chemical transport could also be considered humanitarian. She urged using specific use case names.
  • Stuart provided ICAO (International Civil Aviation Organization) as a specific use case example, noting its global standardization efforts for digital assets in civil aviation.
  • Alison mentioned Article 19's interest in press safety and suggested contacting specific committees (like ICMM's Science and Technology Committee) for stakeholder input.
• Forensic Collection of Digital Emblems: Allison suggested including a "may require" for forensic collection. Felix noted this was intended to be covered in Section 4.5 on "proof of presence."
• Document Lineage Issue: DKG pointed out that the adopted draft's lineage on the Datatracker was incorrect, referencing an older draft name. Rowan May (Chair) acknowledged this was likely an accidental omission during submission and committed to correcting it.

Decisions and Action Items

• PR 1 (Charter Definitions): Merged as an initial set of definitions.
• PR 8 (Acknowledgments): Editors to ensure consent from named individuals before submitting to the Datatracker.
• Author Limit: Editors to limit co-authors to five in future Datatracker submissions, using the contributor section for others.
• Bearer vs. Asset Definition: Samin Isirsi, Allison, and Natasha will collaborate on proposing text to clarify the distinction between "bearer" and "asset" within the document.
• Security Considerations Section: Editors to draft an outline for a more comprehensive security section in a new PR.
• Document Lineage: Chairs to correct the lineage information for the adopted draft on the Datatracker.
• General: For any contentious points or areas requiring clarification, the working group strongly encourages individuals to "send text" (i.e., submit GitHub PRs or suggested wording to the mailing list).

Next Steps

• Continue discussions and issue resolution on GitHub and the mailing list.
• Editors to incorporate feedback and prepare revisions based on the action items, particularly for definitions and the security section outline.
• The working group will aim for Working Group Last Call (WGLC) readiness for the Use Cases and Requirements document.
• Samin Isirsi shared updates on external engagements with NATO Cyber Excellence Centre (prototype testing), International Committee of Military Medicine (ICMM), and the World Medical Congress, all providing valuable feedback and potential stakeholder input. The community is encouraged to discuss prototype work and technical details on the mailing list.
• The chairs expressed appreciation for the group's productivity and encouraged continued engagement to move the document forward.