| Internet-Draft | DIEM Architecture Example | July 2026 |
| Jensen | Expires 7 January 2027 | [Page] |
This document defines the architecture for Digital Emblems. Standards that define Digital Emblems are expected to do so by mapping their mechanisms to the required and optional componented defined by this document.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tojens-diem-arch-visual-aid/.¶
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/tojens-ietf/draft-tojens-diem-arch-visual-aid.¶
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 7 January 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.¶
Various use cases for Digital Emblems and the requirements those use cases present are defined in (link to it). This document builds on those requirements to define an architecture that can accommodate a diverse set of use cases (hopefully generalized such that as-of-yet unknown use cases can reuse this same architecture).¶
The subsections of the next two sections outline the checklist of things a Digital Emblem standard MUST define to be considered a Digital Emblem (even if to say that the optional element is being omitted).¶
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 section defines the elements that are common to all Digital Emblems. Therefore, standards that define a Digital Emblem MUST define how that emblem fulfills each part of this section.¶
TODO: the current text presumes some custom binary format for simplicity of defining an example architecture. In reality, this should probably be some existing data structure format standard, but the proposed fields remain the same¶
To accommodate Digital Emblem standards that may require extensive data payloads, the base format of a Digital Emblem is purposefully kept as small as possible with an extensible payload. Digital Emblem standards MUST define the semantics of that payload.¶
Format: - FQDN: the asset identifier, a length-prefixed UTF-8 string - Digital Emblem Type: 16-bit integer from IANA Digital Emblem Type registry - Payload: length-prefixed data field whose semantics are defined by the Digital Emblem Type¶
The Digital Emblem Type of 0 is defined by this document to provide standards with a reusable parsable format. This format of the payload is defined as: - a length-prefixed string: this is a MIME type identifier - the rest of the payload: in the format defined by the MIME type¶
Because Digital Emblems are defined as being identified by FQDNs, discovering them via the DNS is likely to be a common scenario. This document defines such a mechanism that Digital Emblem standards can use. They MUST define how their emblems are discovered either by using this mechanism, building on this mechanism, or defining a new mechanism of their own. Use of this mechanism is simply defined as using standard DNS queries to retrieve the DIEM records associated with the FQDN of the asset bearing the emblem.¶
<< Normative Reference: second doc defining new DIEM RR type >>¶
Use cases that wish to use the DIEM RR type can. Others may see fit to define use of an existing record for (reasons). Others may use the DIEM record but signal in a SVCB/HTTPS record that it is available. Some may use specific labels (like a future "_de" label) while others may not. This architecture does not define or limit these choices. This document requires that Digital Emblem standards MUST define how their emblems are discovered and retrieved, even if it is as simple as "QTYPE=DIEM for the asset's FQDN".¶
This section defines the elements that a Digital Emblem might have if its use case requires them, but otherwise does not have to have just because it is a Digital Emblem. Standards that define a Digital Emblem MUST indicate whether each of these apply or not.¶
Some Digital Emblem standards MAY require some specific verification of emblem integrity, such as having subsets of their payload signed and verified through a different source of authority than the authorization. If so, they MUST define how this is to function. As this document defines the generic Digital Emblem format, there is no data integrity verification provided by the format.¶
Some Digital Emblems MAY require that bearers cannot reasonable detect when validators are checking for their asset's emblem (or who is checking). Others MAY require that this is known because they have a strong audit requirement of when emblems were verified. Many will require neither, which is why this component is optional.¶
If a Digital Emblem standard does either require or forbid bearer awareness of validators checking for their asset's emblem, it MUST define how this is to be achieved, including any necessary modifications to other components (such as discovery). Otherwise, it MUST simply declare that neither case applies.¶
The security considerations of Digital Emblem standards will be dependent on the way they choose to implement the elements defined in this document. However, this document uniquely introduces¶
This document defines a new registry called the Digital Emblem Type registry. This is intended to be a low bar to entry, FCFS, so that implementors can tell which parsers to use for the emblem payload. The zero value is reserved for a special case where the payload is the MIME type payload defined earlier.¶
N/A¶