Session Date/Time: 22 Jan 2026 16:00

DIEM

Summary

The DIEM interim meeting focused on reviewing the latest version of the draft-ietf-diem-usecases-requirements document, specifically the changes introduced in draft-ietf-diem-usecases-requirements-01. Key discussions revolved around updated terminology, the generalization of "undetectable validation," expanded use case details for International Humanitarian Law (IHL), and the initial security considerations. The meeting also addressed a range of open GitHub issues, with a strong emphasis from the chairs on assigning ownership and making tangible progress towards the Working Group Last Call (WGLC) of the requirements document. The working group also discussed the possibility of starting work on the architecture document and engagement with other standards bodies.

Key Discussion Points

Review of draft-ietf-diem-usecases-requirements-01 Diff:
- Felix presented the main changes:
  - Terminology: Replaced "bearer" with "asset" throughout the document for clarity, addressing previous confusion. The terminology section was expanded with definitions for "digital emblem," "asset emblem," "emblem issuer," "authorizing entity," "validator," and "validation," incorporating input from legal experts (ICRC, Australian Red Cross).
  - Undetectable Validation: The requirement was rephrased more generally. Previously, a specific list of parties (bearers, issuers, authorizing parties) was explicitly unable to detect discovery. The new text states a digital emblem may require undetectable discovery and validation, but acknowledges that for specific use cases and designs, it may be acceptable for certain parties (e.g., DNS authoritative name servers) to detect emblem usage, provided the threat model is made explicit.
  - International Humanitarian Law (IHL) Use Case (Section 4.5): This section was expanded to include a general background, a domain model explaining stakeholders (emblem issuers, authorizing parties, validators), and specific requirements for the use case.
  - Security Considerations: A new section was added, prepared by Allison. It is acknowledged as a "bare bones" start, with more specific paragraphs in preparation to outline varying security considerations across different use cases.
- The chairs confirmed that draft-ietf-diem-usecases-requirements-01 has been published on the DataTracker.
Open GitHub Issues Discussion:
- Issues 17 & 18 (ISO Shipping Containers & Diplomatic Bag Use Cases):
  - Alex raised these pre-charter use cases, questioning if they should be further developed in the requirements document.
  - Felix noted that many existing use cases (e.g., WHO) are loosely specified and require more scrutiny, emphasizing the need for quality text and clarity on how use cases influence architecture/protocol design.
  - Allison and Alex discussed outreach to stakeholders (IAEA, OPCW, French companies for ISO containers, PCH/Bill Woodcock for diplomatic bags) to gain more input.
  - It was agreed that new use cases need high-quality text and ideally, an identified person to drive them or a representative stakeholder to validate requirements.
  - Jim sought clarification on the scope, and chairs clarified that the requirements document needs a reasonable set of use cases to inform architecture, not necessarily a comprehensive list, but quality is paramount.
  - The possibility of using "placeholder" text for use cases where expertise is lacking was discussed, with the consensus that some level of moderate quality text is needed for inclusion.
- Issue 14 (DKG's request for stakeholder roles/interoperation in use cases):
  - Felix believed the IHL use case's domain model section partially addressed this, but acknowledged it applies more broadly.
  - Allison suggested adding a top-level section defining general roles (verifier, issuer, holder, authorizer) to guide future use case descriptions, potentially as a template within the security considerations.
- Issue 11 (Forensic records of emblems):
  - Allison found the current text insufficient. She explained the need for clearer text on recording the past presence and timeframes of emblems for enforcement and protecting against plausible deniability, particularly in IHL contexts.
  - Alex suggested including historical records of who created/edited emblems (with non-public IDs) and how temporal fields in the record (e.g., GPS coordinates) should be handled.
  - Allison reached out to Timo (White Flag project, Netherlands military) for his expertise on forensic records, given their use of blockchain for similar purposes.
- Issue: "Bearer" vs. "Asset": This issue was addressed by the document changes and subsequently closed.
- Issue: Security Considerations (lack of confidentiality/privacy): Allison reiterated that the current security considerations are a work in progress and need significant expansion to cover aspects like confidentiality and privacy, potentially using a template approach for roles.
Acknowledgements and Contributors:
- Discussion ensued about tracking consent for names in the acknowledgements section. The chairs suggested using GitHub checkboxes to manage this process.
- Rohan will prompt the mailing list for consent.
- The "Contributors" section (as seen in the MLS extensions document) was suggested as an alternative to the main author list for accommodating numerous contributors, allowing the primary author list to remain concise (max 5 authors).
Working Group Timeline and Progress:
- Felix inquired about a timeline for completing the requirements document, noting the two-year duration of work.
- The chairs emphasized that establishing a concrete timeline requires working group consensus. They will pose this as a direct question to the group at the upcoming March meeting.
- The chairs stressed the need for active engagement and ownership of open issues, stating the working group is past the point of merely listing "interesting" topics without concrete work.
- Discussion confirmed that while architecture drafts can be developed and discussed, formal adoption of an architecture document is contingent on the completion of the requirements document.
- Chairs cautioned that a lack of progress could lead to intervention from the Area Directors.
Other Business:
- Jim apologized for delays on his DNS architecture document and committed to publishing it soon.
- Jim reported on ongoing work in the ITU regarding DiEM, including the adoption of a "DM use cases and requirements" document, and expressed concern about potential competitive rather than complementary efforts.
- Chairs (Tommy) acknowledged Jim's heads-up and reinforced the IETF's official liaison relationship with the ITU. They reminded participants to encourage individuals to contribute to the IETF directly and to direct formal organizational engagement through official liaison channels. The chairs confirmed they are actively managing the liaison relationship and are aware of the ITU's activities, aiming to ensure IETF-owned protocols (like DNS) remain central to DiEM standards.

Decisions and Action Items

Decision: The term "bearer" has been consistently replaced with "asset" in draft-ietf-diem-usecases-requirements-01. (GitHub issue closed).
Action Item: Alex to propose text for the ISO Shipping Container use case (GitHub Issue 17).
Action Item: Rahel to propose more specific text for forensic record capabilities, potentially collaborating with Alex (GitHub Issue 11).
Action Item: Allison to create a Pull Request (PR) with top-level guiding text on general roles (verifier, issuer, holder, authorizer) for use cases, possibly as a template (GitHub Issue 14).
Action Item: Allison to collaborate with co-authors to expand the security considerations section to cover confidentiality, privacy, and other relevant security properties, incorporating the idea of a template for roles.
Action Item: Working Group (Chairs and Editors) to track consent for names in the acknowledgements section using GitHub checkboxes within a PR or issue.
Action Item: Editors to move some names from the main author list to the "Contributors" section of the document, aiming to keep the primary author list to five names or fewer.
Action Item: Jim to publish the DNS architecture document shortly (within two weeks).
Action Item: Chairs will explicitly poll the working group at the March meeting to establish a timeline for completing the requirements document.
Action Item: Jim to continue updating the working group on the mailing list regarding ITU engagement with DiEM.

Next Steps

Prepare for March Meeting: Working group members should review open GitHub issues and identify areas where they can contribute text or take ownership to ensure progress on the requirements document.
Requirements Document Timeline: Be prepared to discuss and agree upon a timeline for the draft-ietf-diem-usecases-requirements document's progression to Working Group Last Call at the March meeting.
Stakeholder Engagement: Authors and interested individuals should continue engaging with stakeholders for various use cases (IAEA, OPCW, ISO shipping containers, diplomatic bags, White Flag project) to gather high-quality input and drive text creation.
Architecture Document: While the requirements document is prioritized, list discussion on any proposed architecture drafts is encouraged.