DIEM Architecture Example
draft-tojens-diem-arch-visual-aid-00

Digital Emblems                                                T. Jensen
Internet-Draft                                                Cloudflare
Intended status: Informational                               6 July 2026
Expires: 7 January 2027

                       DIEM Architecture Example
                  draft-tojens-diem-arch-visual-aid-00

Abstract

   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.

About 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.

Status of This Memo

   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.

Jensen                   Expires 7 January 2027                 [Page 1]
Internet-Draft          DIEM Architecture Example              July 2026

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Foundation and Required Components of a Digital Emblem  . . .   3
     3.1.  Digital Emblem Format . . . . . . . . . . . . . . . . . .   3
     3.2.  Digital Emblem Discovery  . . . . . . . . . . . . . . . .   3
   4.  Optional Architecture Elements  . . . . . . . . . . . . . . .   4
     4.1.  Authorization . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Verification  . . . . . . . . . . . . . . . . . . . . . .   4
     4.3.  Detection of Validation . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   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).

Jensen                   Expires 7 January 2027                 [Page 2]
Internet-Draft          DIEM Architecture Example              July 2026

2.  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.

3.  Foundation and Required Components of a Digital Emblem

   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.

3.1.  Digital Emblem Format

   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

3.2.  Digital Emblem Discovery

   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.

Jensen                   Expires 7 January 2027                 [Page 3]
Internet-Draft          DIEM Architecture Example              July 2026

   << 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".

4.  Optional Architecture Elements

   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.

4.1.  Authorization

   Some Digital Emblem standards MAY require bearers to have and
   demonstrate proper authorization to bear their emblem.  If so, they
   MUST define the following: - what parties are authorities - how trust
   in an authority is established by a validator - how a bearer presents
   its authorization within its emblem's payload

   Because FQDNs are used to identify assets bearing emblems, a natural
   solution can be the use of DNSSEC.  This inherits the trust model
   already defined for DNSSEC, which then requires validators to perform
   DNSSEC validation.  The use of PKI is another possibility.  This
   document does not define how this or other approaches could be done.

4.2.  Verification

   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.

4.3.  Detection of Validation

   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.

Jensen                   Expires 7 January 2027                 [Page 4]
Internet-Draft          DIEM Architecture Example              July 2026

   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.

5.  Security Considerations

   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

6.  IANA Considerations

   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.

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

   N/A

Author's Address

   Tommy Jensen
   Cloudflare
   Email: tojens.ietf@gmail.com

Jensen                   Expires 7 January 2027                 [Page 5]