| Internet-Draft | Digital Emblems Architecture Document | October 2026 |
| Linker | Expires 20 April 2027 | [Page] |
TODO Abstract¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://felixlinker.github.io/diem-arch/draft-linker-diem-arch.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-linker-diem-arch/.¶
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/felixlinker/diem-arch.¶
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 20 April 2027.¶
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.¶
The Digital Emblems (diem) WG works on the digitization of physical emblems as digital emblems. Emblems convey some information about a subject that must be interpreted in the context of some normative framework, for example, a law, a treaty, a convention, a government agency's procedures, or a customary law. One famous example of an emblem is that of the Red Cross, which conveys that its bearer serves a medical purpose and thus enjoys specific protections under International Humanitarian Law (IHL). Digital emblems are systems and standards that convey the relevant information by digital means, e.g., by storing it in DNS resource records.¶
Different use cases have been discussed at the diem WG, for example, the labelling of goods in transport by reference to the World Customs Organization's classification, conveying that a wetland is designated as protected under the Convention on Wetlands of International Importance, or the marking of digital services as enjoying specific protections under IHL. (For more details, see [I-D.ietf-diem-requirements].)¶
Intuition suggests that one design ought to be able to address all use cases, and many use cases share some requirements, e.g., authenticating an emblem's information. Discussions on the various use cases, though, have revealed that many use cases have conflicting requirements or have different flavours of requirements that may upon first glance appear to be the same. Thus, it seems to be the most sensible way forward to distinguish different profiles of Digital Emblems, which can address different groups of use cases that share relevant requirements.¶
In this document, we present these different emblem profiles and groups of use cases, outline their domain model and relevant parties, and sketch which drafts will comprise a profile. This document is meant to evolve in parallel to the referenced protocol documents. It serves as an overview of the diem WG work.¶
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.¶
This profile currently comprises the following drafts:¶
In the external registry profile, emblems convey information that is codified by an external registry. For example, the United Nations Economic Commission for Europe (UNECE) defines standardized means to encode data, e.g., areas, time and dates, types of cargo, and much more. This profile provides means to associate such externally codified information with domain names.¶
The domain model of this profile is the following. A validator learns about an asset's associated domain name out-of-band. Using this profile, the validator can query for different groups of codified information by querying for relevant resource record types associated with that domain name. How this information is processed then depends on the use case and application context.¶
Information is published in the DNS by the party controlling the asset with which information is associated. Integrity of the data can be provided straightforwardly by signing the relevant zones using DNSSEC [RFC4033] [RFC4034] [RFC4035].¶
This profile currently comprises the following drafts:¶
The protective emblems use case provides digital means to convey the protective emblems defined in the Geneva Conventions, their Additional Protocols, and the 1954 Hague Convention. These emblems include the Red Cross, Red Crystal, and Red Crescent for medical, humanitarian infrastructure.¶
In this profile, an emblem issuer can signal to a validator that the services associated with a domain name enjoy the specific protections under International Humanitarian Law (IHL), which, for example, implies that they should not be disrupted. To use the emblem on a domain name, this domain name must only be used for purposes that enjoy the specific protections under IHL. We assume that the emblem issuer controls the domain name, though they may have outsourced its operation to a service provider.¶
The audience of such emblems consists of validators: all parties who would generally disrupt digital services but respect services marked with an emblem. We can thus assume that validators obtain a service's domain name out-of-band during the reconnaissance phase of their operations.¶
The use of the emblem requires authorization by a competent authority, typically by a state. How authorization is obtained is outside the scope of this profile for now.¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶