| Internet-Draft | DIEM Use Cases and Requirements | June 2026 |
| Fainchtein, et al. | Expires 8 December 2026 | [Page] |
Digital emblems are a means for an asset to signal to validating entities that it should be protected or treated in a specific way, using some normative framework. This document lists the requirements and use cases that an architecture for digital emblems must accommodate.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://ietf-wg-diem.github.io/diem-requirements/draft-ietf-diem-requirements.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-diem-requirements/.¶
Discussion of this document takes place on the Digital Emblems Working Group mailing list (mailto:diem@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/diem. Subscribe at https://www.ietf.org/mailman/listinfo/diem/.¶
Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-diem/diem-requirements.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Digital emblems are a means for an asset to signal to validating entities that it should be protected or treated in a specific way, using some normative framework. The DIEM WG will define a set of standards for an architecture that enables discovery and validation of digital emblems. This document lists the requirements that the architecture must accommodate. These requirements were identified across different use cases. Not all use cases share all requirements. We envision an architecture system comprising multiple standards, which can be flexibly profiled for different use cases. We use the terms "(digital) emblem" and "validation" in accordance with the DIEM charter as of this writing [CHARTER]. These definitions have been reproduced in section Conventions and Definitions.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The definitions for terms "(digital) emblem" and "validation" are reproduced from the charter [CHARTER] as of this writing.¶
Emblems such as the Red Cross, Red Crescent, Red Crystal, and Blue Shield can be symbols of protection governed by International Humanitarian Law (IHL). Emblems can also be identified by other laws, agreements, or standards. There is a need to present emblems through digital communication channels. Emblems presented in such ways are called digital emblems. Digital emblems extend the range of identifying marks from the physical (visual and tactile) to the digital realm.¶
A physical resource -- such as place or thing; or a digital resource, system, or service - such as a server, data repository, or networked device - that can present a digital emblem.¶
The entity that operates or controls an asset that bears a digital emblem. Depending on the applicable emblem, the issuer may have received authorization to issue emblems, and in such cases, emblem issuers are also called authorized entities. For example, emblem issuers could be a medical or humanitarian organization, a cultural institution, or an operator of installations containing dangerous forces, among others.¶
An entity competent to grant authorization for the use, by an authorized entity, of a digital emblem. The authorizing entity ensures that such authorization is issued and recorded in accordance with applicable legal requirements, enabling technical and operational verification. In certain specific cases, the authorizing entity is also the authorized entity.¶
An entity that queries, inspects, or otherwise interacts with assets to determine whether they are marked with a valid digital emblem. Validators may include technical systems, network operators, or other actors implementing protective or non-interference measures consistent with the emblem's purpose.¶
"To validate an emblem" means to confirm the authenticity or legitimacy of a particular symbol or design, often by checking its details against a known standard or reference point. Validation may include ensuring that the emblem has not been forged, stolen, or tampered with.¶
The DIEM architecture will allow validators to discover and validate digital emblems that are associated with assets. This section contains the requirements that this architecture will address. They are based on use cases identified thus far (see Section Use Cases), but note that not all use cases share all requirements. We categorize these requirements into: requirements on digital emblems and their format, on their discovery, on their validation, and other requirements.¶
Digital emblems MUST identify the marked asset and their kind of digital emblem. Beyond that, digital emblems MAY include other data, for example, an issuer or a validity window. To accommodate use cases requiring extensible data, a digital emblem architecture SHOULD introduce minimal overhead size except for fields required to fulfil other requirements in this document.¶
Each emblem type will make use of a subset of the requirements set out in this document. The requirements for individual digital emblem types are independent and the requirements for an individual emblem type MUST NOT constrain, override, or otherwise affect the requirements, design, or use of any other digital emblem.¶
Where a use case specifies a limited domain of application (e.g. only digital or physical assets, a narrow scope of valid issuers or validators, or specific discovery mechanism) for a particular emblem, such a limitation SHOULD be understood as reflecting current use case constraints only. It SHOULD NOT be interpreted as precluding future use cases from applying that emblem under a different or expanded domain of application, provided that the emblem’s core semantics remain intact.¶
As of this writing, the DIEM charter requires that digital emblems MUST explicitly identify the marked asset by a Fully Qualified Domain Name (FQDN).¶
Individual use cases MUST specify the semantics of the emblem. It must be clearly stated how discovery and validation of a digital emblem should inform validator behavior.¶
Digital emblems MUST specify how validators can check for the presence of a digital emblem. That is, given an asset a validator must be able to determine whether it has an associated emblem. For example, verifying whether a FQDN has an emblem associated with it could be realized by fetching digital emblem-associated records for said FQDN.¶
Specifications for each use case MUST each determine how servers must respond to queries for Digital Emblems of their specified type. Specifically, they must determine the responsiveness and consistency requirements for emblems of their given type and provide explanations of how the chosen requirements apply and the rationales for their selection.¶
For responsiveness, an instance of a specific type of digital emblem can either be required to respond to all queries for it (Assured Response), or allowed to selectively respond to a specific subset of incoming queries (Selective Response).¶
For consistency of response, specifications for a given type of Digital Emblem T must denote whether all queries for an asset's records (as denoted by its FQDN) must return all Digital Emblems of type T associated with the asset (Consistent Content), or whether the inclusion of emblems of type T in a response may vary based on specific requester attributes (Selective Content).¶
Note that as of this writing, neither the baseline definition for the minimum set of attributes that constitute a unique Digital Emblem, nor the attributes needed to attain Consistent Content have been defined. Given the limited scope of this document, that definition as well as the mechanism to ensure its extensibility across newly defined emblem types will be outlined in the architecture document.¶
Digital emblems MAY require to be removable in that checking for the presence of an asset's emblems results in no emblem. Note that checking for emblem presence is independent of its validation. That is, emblems do not count as removed when they become invalid.¶
A digital emblem MAY require that its discovery and validation is undetectable. This requirement is motivated by emblems that mark its asset as protected and ask validators to not disrupt the marked asset. If emblem discovery were detectable, malicious parties could misuse the digital emblem as an intrusion detection system.¶
For specific use cases and designs, it may be acceptable that certain parties can detect emblem discovery and validation, for example, when the validator can hide in a sufficiently large anonymity set, or it is acceptable that the given party could detect the discovery or validation. Concrete designs MUST specify a threat model for undetectable validation. This threat model must detail which parties can detect emblem discovery and validation, under which conditions, and to what extent.¶
Digital emblems MAY require validation. The digital emblem architecture MUST allow individual standards to support verification of all the digital emblem's data or a defined subset without restriction. This ensures digital emblems can support static or dynamic data without having to account for the pain of frequent re-signing of dynamic data if its validation is not required by a given digital emblem type. In particular, when validation is defined, it MUST ensure that the emblem was issued for the respective asset. Some use cases MAY use unverified digital emblems.¶
The digital emblem architecture should be extensible. The initial work should not preclude future extensions and individual standards should be designed as general as possible.¶
In this section, we sketch how the digital emblem architecture could be extended by future standards to accommodate more use cases, but it is not a comprehensive list.¶
Emblems for additional use cases may be defined via new profiles in future standards, potentially including new types of atomic data elements requiring additional specification.¶
It may be non-obvious for some use cases to learn the identifier associated with an asset, and thus impossible to discover emblems associated with that asset. To accommodate for such use cases, one could specify means to discover identifiers for different types of assets.¶
An alternative approach to the above problem would be to bind emblems implicitly to the marked asset. Implicit binding could identify the marked asset by the emblem's location. For example, if emblems were distributed via NFC, the marked asset could be the asset to which the NFC chip was attached. As of this writing, the current charter scope requires that digital emblems explicitly identify their asset, but such discovery mechanisms could be investigated in future WG work.¶
Some use cases may contain confidential or sensitive data, and may require mechanisms to protect such data. For example, this could be realized with encryption of the general emblem data format that will be part of the architecture or by only serving emblems over channels with access control mechanisms.¶
Since emblems themselves are unable to directly protect assets against attack, emblems indicating assets are entitled to protections may require a mechanism through which violations of their laws or provisions can be verified forensically. This would be particularly relevant in cases where emblems can be applied and removed dynamically. These protections are defined in three different levels, listed from weakest to strongest.¶
Level 1 - presence and verifiability: Establishing that an actor or querying party was able to obtain the emblem at the time of violation. That is forensically demonstrating/proving that the emblem was discoverable and verifiable at the time of an alleged violation.¶
Level 2 - presence, verifiability and access: Establishing the emblem’s presence and verifiability and that the querying party accessed the digital emblem.¶
Level 3 - presence, verifiability access and verification: Demonstrating presence verifiability and access and that the querying party verified the emblem upon accessing it. This level of proof can only be made by the querying party.¶
Note that Levels 2 and 3 are intended to be mutually exclusive requirements with Undetectable Validation Section 3.2.4. An example from the Diplomatic Pouch use case, described in Section Section 5.2, illustrates the Level 3 Proof of Presence requirement, and how it in some cases may need to be part of a chain of custody and/or accompanied by additional security measures to provide adequate security guarantees.¶
Different use cases have different requirements. The purpose of this document is to list the requirements that will be addressed with the initial architecture. The use cases overlap and would benefit from a DIEM architecture developed to provide the requirements listed above, though some may require additional extensions. We alphabetically list use cases here so that relevant stakeholders can provide input whether their use case would indeed benefit from a DIEM architecture, and invite participants to provide use cases or details that we have missed.¶
We provide auxiliary material under Informative References.¶
Regulates the trans-boundary movement of hazardous wastes. Use cases are functionally identical to OPCW and IAEA.¶
Digital emblems can protect diplomatic pouch shipments, diplomatic couriers, and diplomatic envoys. All three of these are protected under the 1961 Vienna Convention on Diplomatic Relations [VIENNACONV], which states that they may not be stopped, delayed, or inspected. This creates the paradox that the validity of their credentials must be evaluated, yet doing so has historically compromised the very rights that are intended to be signaled. Diplomatic markings have also been misappropriated as cover for the smuggling of drugs and other contraband. Digital emblems, which can be validated instantaneously, at a distance, and without interrupting the subject, address both of these problems, while streamlining and automating customs and immigrations processes.¶
The use case for diplomatic pouches involves the following entities: - Point of Entry Country/Customs Agent(s): Validator - Origin Country or Accredited Organization: Issuer and Authorizing entity - Diplomat: Agent of Country or Accredited Organization - Pouch: Asset¶
As noted in Section Section 4.5, a Level 3 Proof of presence record could help demonstrate, for the benefit of the customs service, that a customs agent(s) in a Point of Entry country validated the diplomatic pouch. To that end, the Proof of Presence record of processing a diplomatic pouch's digital emblem could include the following information.¶
Specific point of entry¶
Time/Date of arrival at point of entry¶
identifier(s) of customs agent(s) validating the pouch¶
A baseline record establishing the Emblem's existence and accessibility (or a pointer thereto)¶
Record of the customs agent's attempt to validate the Digital Emblem and its result signed by the customs agent(s)¶
As indicated in Section Section 4.5, Level 3 Proof of Presence alone does not provide proof that no tampering with the diplomatic pouch or inspection of its contents has occured. This is because a proof of presence neither provides a chain of custody nor any mechanisms to detect tampering should it occur. For this reason, Level 3 validation may be used along side or as part of an attested chain of custody and/or accompanied by the use of physical mechanisms for tamper-proofing a physical asset. Any such chain of custody specification or anti-tampering mechanism is out of the scope of the DIEM WG.¶
IAEA administers several treaties, especially related to the controlled shipment of atomic fuels and wastes across borders. Similar use case as OPCW.¶
Requires protection of civil aviation flights and the ability to assert that they are not dual-use (i.e., not carrying military cargo). Digital emblem would carry a geographic description of the flight plan, its current location, and an indicator of its identity (i.e., tail number). Potential need for the emblem to reference a limited or partially redacted flight manifest.¶
The Geneva Conventions and their Additional Protocols constitute the core of International Humanitarian Law (IHL). Some assets enjoy certain specific protections under IHL, including that they must not be attacked. In addition to recognizing other signs, IHL codifies four types of protective emblems for armed conflict, which inform other parties that marked assets benefit from one or several of these specific or special protections. In other words, protective emblems under IHL signal the applicability of a specific or special protection under IHL. Namely, these emblems are:¶
The emblems of the Red Cross, Red Crescent, and Red Crystal, defined in the Geneva Conventions and Additional Protocol III of the Geneva Conventions [GCI1949] [APIII2005]¶
The Blue Shield emblem, defined in the 1954 Hague Convention [HAGUE1954]¶
The international distinctive sign of civil defence, defined in Additional Protocol I of the Geneva Conventions [API1977]¶
The dangerous forces special sign, defined in Additional Protocol I of the Geneva Conventions [API1977]¶
However, these emblems can currently only be used to mark physical assets, and there is no way to mark digital, network-connected infrastructure that enjoys the same protections. A digital emblem using the DIEM architecture could address this gap, and resolutions from UNESCO and the International Conference of the Red Cross and Red Crescent have expressed the support for such a digital emblem [RCRCRES] [UNESCORES].¶
In context of digital, protective emblems under IHL, emblems will mark assets that are digital services and that solely serve protected purposes (for example, a medical unit, a cultural site, or an installation containing dangerous forces). Such emblems will be issued by the party controlling the marked service, and they signal that these assets must be respected and protected. Emblems must only be issued by entities that have been authorized to bear a digital emblem or other distinctive sign under international law. Such authorizations must be issued by a state, other party to an armed conflict, or other entity competent under international law.¶
For digital, protective emblems under IHL, validators will typically be armed forces under the command of either state or non-state actors. In situations of armed conflict, all such actors are under an obligation to check whether assets subject to military activities bear an emblem. Similarly, other malicious ICT actors, whilst not necessarily obligated under IHL, may choose to respect assets bearing the emblem. Concretely, we can assume that they will typically first identify an asset that they plan to engage with and then check whether that asset bears an emblem.¶
The purpose of a digital emblem is to prevent disruptions of assets by informing verifiers that marked assets enjoy protection under IHL. Digital emblems will only be able to do so when verifiers are willing to pay attention to them. As verifiers intend to attack assets that are not protected under IHL, this will only be the case they are confident that their targets cannot fake protection and that they do not alert their target about an imminent attack. Therefore, digital, protective emblems under IHL require validation for authenticity (Section 3.3.1) that is undetectable (Section 3.2.4).¶
At the same time, digital, protective emblems under IHL should fit well into the existing framework of IHL and not put emblem issuers at increased risk. First, IHL requires that, emblem issuers must seek authorization from a competent authority prior to applying them (see Section 3.3.2 and Section 5.5.2). The authorization must be decentralized, i.e., there must be no central authorities that govern the use or distribution of digital emblems. Second, bearing an emblem can increase the risk for targeted attacks. We require that emblem issuers must be able to individually assess that risk and remove emblems whenever they see the risks to outweigh the benefits, i.e., we require that digital emblems are removable (Section 3.2.3).¶
Beyond the DIEM architecture as described in this document, digital, protective emblems under IHL would benefit from other discovery mechanisms than the DNS, as not all assets may have domain names associated with them.¶
Requires protection of Schedule 1 chemicals in transit between signatory countries for research, medical, pharmaceutical, or protective purposes. Emblem would identify place, date, and volume of production, and the emblem can contain confidential data.¶
Journalists in conflict zones use protective markings that indicate their status as a non-combatant. Assets belonging to the press could be digitally marked, and protective markings in conflict zones could be digitized.¶
The Convention on Wetlands of International Importance especially as Waterfowl Habitat "providees the single most global framework for intergovernmental cooperation on wetland issues" and it features a list of geographic areas designated by Member States. A digital emblem for the geographic areas potentially requires¶
Among other things is responsible for the International Plant Protection Convention (IPPC) and International Standards for Phytosanitary Measures standards including ISPM 15 that requires wood packaging materials (pallets, crates, dunnages) to be debarked, heat-treated or fumigated with methyl-bromide, and stamped or branded with a compliance mark known as a "wheat stamp."¶
UN Peacekeepers use protective markings in theater as well as facilities associated with the mission.¶
Specifies "Harmonized Systems" codes [HARMONIZED] that classify items such as livestock, arms and ammunition, chemicals, plastics, machinery, foodstuffs, etc. They also provide a system for labeling origin of items and valuation of items, all enforced by numerous international trade agreements between individual nations and groups of nations.¶
Similar to the use case of the Red Cross, Red Crystal, and Red Crescent.¶
WIPO administers 26+ treaties with different protections for different things. Brands that are protected under international law (e.g., Madrid Protocol) can mark their shipments with an emblem allowing customs agents to positively identify legitimate products.¶
Because this is a requirements document, it does not directly have security considerations. However, multiple of the defined requirements include security properties. The architecture and standards developed need to detail the security properties of validation and authorization especially. Use cases have threat models and discussion of mitigating specific threats is needed. For example, in a use case where removability (Section 3.2.3) is needed, there are security considerations such as the potential for replay of removed emblems.¶
This document has no IANA actions.¶
Brian Haberman and Bill Woodcock created an early version of a use cases and requirements document, from which this draws ideas. We also thank Eric Vynke, Suresh Krishan, Antonio DeSimone, Nick Doty, Tommy Jensen, and Michael Christie for their valuable input.¶