Earmark: Embedded Attribution and Rights Marks for AI Usage Preferences
draft-hood-aipref-earmark-00

AI Preferences                                                   C. Hood
Internet-Draft                                                Nomotic AI
Intended status: Standards Track                          12 August 2026
Expires: 13 February 2027

Earmark: Embedded Attribution and Rights Marks for AI Usage Preferences
                      draft-hood-aipref-earmark-00

Abstract

   This document defines Earmark (Embedded Attribution and Rights
   Marks), a mechanism by which publishers and rights holders embed
   signed usage preferences directly into published content.  To earmark
   content is to reserve it for designated uses, and the mark travels
   with what it covers, surviving republication and aggregation, so the
   preference remains discoverable wherever the content arrives,
   including where perimeter signals such as robots.txt no longer apply.
   Marks carry the identity of the rights holder, the preferences
   asserted, and a signature, and are verifiable offline by any party.
   An individual signed statement is a Mark; the mechanism as a whole is
   Earmark.  This document defines the Mark Object, embedding bindings
   for common content types, and the detection and verification
   procedure.  It reuses the AI Preference vocabulary for preference
   semantics and the C2PA and CAWG assertion infrastructure for media,
   defining new machinery only where none exists.  Earmarks make ignored
   preferences observable and attributable.  Enforcement remains with
   law, contract, and the market.

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 13 February 2027.

Hood                    Expires 13 February 2027                [Page 1]
Internet-Draft                   Earmark                     August 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Positioning . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Document Roadmap  . . . . . . . . . . . . . . . . . . . .   3
     1.3.  What Earmarks Do and Do Not Provide . . . . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  The Mark Object . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Key Lifecycle . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Multiple Marks and Conflicts  . . . . . . . . . . . . . .   6
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Bindings  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  HTML Binding  . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Plain Text Binding  . . . . . . . . . . . . . . . . . . .   8
     5.3.  Media Binding . . . . . . . . . . . . . . . . . . . . . .   8
     5.4.  HTTP Binding  . . . . . . . . . . . . . . . . . . . . . .   8
     5.5.  AGTP Binding  . . . . . . . . . . . . . . . . . . . . . .   8
     5.6.  Statistical Bindings  . . . . . . . . . . . . . . . . . .   9
     5.7.  Covert Bindings . . . . . . . . . . . . . . . . . . . . .   9
   6.  Detection and Verification  . . . . . . . . . . . . . . . . .   9
   7.  Mark Registration . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Relationship to Existing Mechanisms . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
   11. Legal Context (Informative) . . . . . . . . . . . . . . . . .  12
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     13.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

Hood                    Expires 13 February 2027                [Page 2]
Internet-Draft                   Earmark                     August 2026

1.  Introduction

   An Earmark is a signed statement by a rights holder about a piece of
   content: who asserts the preference, what content it covers, what
   uses are reserved or granted, and when the statement was made.  The
   name is defined here precisely once: an Earmark is an embedded
   attribution and rights mark, and to earmark content is to reserve it
   for designated uses.

   Publishers today express usage preferences at the perimeter.  A
   robots.txt file [RFC9309], an HTTP response header, or a well-known
   URI describes what automated clients may do with content served from
   one location.  Perimeter signals share one failure mode.  The
   preference attaches to the location rather than to the content, so
   the moment content is copied, scraped, syndicated, or aggregated, the
   preference stays behind and the content travels on unencumbered.

   Recent regulation and industry practice have demonstrated the
   complementary direction.  Providers of generative systems now embed
   machine-readable marks into generated output, so synthetic content is
   detectable wherever it travels.  This document defines the reverse.
   Publishers embed marks into original content, so usage preferences
   are detectable wherever the content travels, including inside corpora
   assembled for model training.

1.1.  Positioning

   This document is an individual submission complementary to the AI
   Preferences working group's deliverables, and it deliberately does
   NOT propose expanding that group's current charter.  The vocabulary
   [AIPREF-VOCAB] defines what preferences mean; the attachment
   mechanisms [AIPREF-ATTACH] serve the perimeter case.  Earmark is the
   next layer, the content-bound carrier for the same vocabulary,
   offered for consideration once the core deliverables are stable.

1.2.  Document Roadmap

   The core of this document is the Mark Object (Section 3) and the
   overt bindings (Section 5).  Covert bindings (Section 5.7), the
   statistical binding registry, and mark registration (Section 7) are
   described at the concept level and are candidates for companion
   documents, so the core can advance independently.

Hood                    Expires 13 February 2027                [Page 3]
Internet-Draft                   Earmark                     August 2026

1.3.  What Earmarks Do and Do Not Provide

   Earmarks make preferences portable, attributable, and verifiable.
   They do NOT make preferences self-enforcing.  A mark is removable by
   a sufficiently motivated party, and no mark prevents any use.  What a
   mark changes is observability.  Content that arrives marked and is
   used against its preference produces evidence.  Content whose mark
   was stripped produces evidence of the stripping wherever an
   unstripped copy or a registered record exists.  This document
   provides the technical artifact; consequences remain with legal and
   commercial regimes.

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.

   *Rights Holder*: The party asserting preferences over content,
   identified by a verification key.

   *Earmark (Mark)*: A signed preference statement embedded in or bound
   to content.

   *Binding*: A method of attaching a Mark to a specific content type,
   including that binding's canonicalization rules.

   *Detector*: Any party extracting and verifying Marks from content.

3.  The Mark Object

   A Mark Object is a JSON document with the following members:

   *  v (REQUIRED): Mark format version.  This document defines version
      1.  Detectors MUST ignore unrecognized members within a known
      version, and MUST treat Marks with an unknown v as unverifiable
      rather than invalid.

   *  holder (REQUIRED): An object containing key (a JWK [RFC7517] or
      key thumbprint) and OPTIONAL name, uri, and domain.  Where domain
      is present, Detectors MAY corroborate the key through DNS-based
      publication at that domain.

   *  content (REQUIRED): An object containing digests, an array of
      digest entries, each with alg, form, and hash.  Two forms are
      defined: exact, the digest of the content octets as published, and

Hood                    Expires 13 February 2027                [Page 4]
Internet-Draft                   Earmark                     August 2026

      canonical, the digest of the content in the canonical form defined
      by the Binding that carries the Mark.  A Mark MUST include at
      least one entry, and SHOULD include both forms, so exact copies
      and reformatted copies both verify.  The exact form MAY be omitted
      where the publishing pipeline cannot produce final octets at
      marking time.  Algorithm agility: Detectors SHOULD support the
      algorithms present in the digests array and MAY treat a Mark as
      unverifiable when its only entries use algorithms the Detector
      considers broken.

   *  pref (REQUIRED): The asserted preferences, using the category
      identifiers and values of the AI Preference vocabulary
      [AIPREF-VOCAB].  Detectors MUST interpret pref according to that
      vocabulary as published; a Mark MAY pin a vocabulary version with
      an OPTIONAL pref_v member, in which case Detectors MUST interpret
      against the pinned version.  Both the object form shown in
      Section 4 and the vocabulary's serialized string form are valid
      carriers, and the mapping between them is the vocabulary's,
      unchanged here.  Additional vocabularies MAY be referenced by URI.

   *  license (OPTIONAL): URI of terms under which reserved uses may be
      granted.

   *  iat (REQUIRED): Issuance timestamp.

   *  exp (OPTIONAL): Expiry, after which the Mark asserts nothing.
      Short-lived Marks with routine reissuance are RECOMMENDED where
      the publishing workflow allows, since expiry bounds the
      consequences of key compromise.

   *  sig (REQUIRED): A JWS [RFC7515] signature by the holder key over
      the JCS-canonicalized [RFC8785] Mark Object with sig absent.

   A Mark asserts, verifiably: this key holder stated these preferences
   over content with these digests at this time.  It asserts nothing
   else.  In particular, a Mark does NOT prove copyright ownership; it
   proves who made the assertion, so that disputes have a named
   counterparty.

3.1.  Key Lifecycle

   Holder keys require lifecycle treatment.  Publishers SHOULD rotate
   keys periodically and use exp to bound each Mark's validity.
   Detectors MAY check key status through DNS corroboration and, where
   the holder participates, through transparency-log inclusion of the
   key (Section 7).  A compromised key allows false assertion in the
   holder's name until expiry, which is the argument for short-lived
   Marks stated above.

Hood                    Expires 13 February 2027                [Page 5]
Internet-Draft                   Earmark                     August 2026

3.2.  Multiple Marks and Conflicts

   A Detector may find more than one valid Mark for the same content.
   The rules:

   *  Marks from the same holder: the Mark with the latest iat
      supersedes, and earlier Marks are historical record.

   *  Marks from different holders: all verified Marks MUST be recorded.
      For automated decisions, the most restrictive applicable
      preference applies, consistent with the conflict handling of
      [AIPREF-VOCAB].  Competing assertions of rights over the same
      content are a dispute between named parties, which is precisely
      what signed Marks make possible, and resolution is out of scope
      for the protocol.

   One verified Mark suffices to establish that its assertion was made;
   it never suffices to silence other verified Marks.

4.  Examples

   A Mark Object (line breaks for readability, sig truncated):

   {
     "v": 1,
     "holder": {
       "key": {"kty":"OKP","crv":"Ed25519","x":"Jc...s4"},
       "name": "Example News LLC",
       "domain": "news.example"
     },
     "content": {
       "digests": [
         {"alg":"sha-256","form":"exact","hash":"9f3a...c210"},
         {"alg":"sha-256","form":"canonical","hash":"77b1...e9d4"}
       ]
     },
     "pref": {"train-ai":"n","search":"y"},
     "license": "https://news.example/licensing",
     "iat": 1765430400,
     "exp": 1797000000,
     "sig": "eyJhbGciOiJFZERTQSJ9..xu3k"
   }

   The pref values above are illustrative and track the categories and
   values of [AIPREF-VOCAB] as it evolves.

   HTML, external reference form:

Hood                    Expires 13 February 2027                [Page 6]
Internet-Draft                   Earmark                     August 2026

   <link rel="earmark"
         href="https://news.example/marks/article-123.json">

   HTML, inline form:

   <script type="application/earmark+json">
   { "v": 1, "holder": {...}, "content": {...},
     "pref": {"train-ai":"n"}, "iat": 1765430400, "sig": "..." }
   </script>

   Plain text, trailer form (the final line of the document):

   Earmark: https://news.example/marks/essay.json sha-256:9f3a

   Verification flow: a Detector fetching the article extracts the
   inline Mark, verifies sig over the canonicalized object, computes the
   canonical digest of the article body per the HTML Binding, matches it
   against the canonical entry, optionally corroborates the key at
   news.example, and interprets pref per the vocabulary.  No step after
   retrieval requires the network.

5.  Bindings

   Each Binding defines where the Mark travels and the canonicalization
   rules for the canonical digest form.  Publishers MAY apply multiple
   Bindings with the same Mark Object, providing survivability in depth.

5.1.  HTML Binding

   A Mark is carried in a link element with rel="earmark" referencing an
   external Mark, or inline in a script element with type="application/
   earmark+json", as in Section 4.  The canonical digest covers the text
   content of the element identified by the OPTIONAL content.scope
   member (a CSS selector carried in the Mark Object itself, so the
   selector travels with the assertion), defaulting to main, then
   article, then body.  The selector is evaluated against the parsed DOM
   under standard HTML parsing rules, and only text nodes within the
   selected element contribute to the canonical form, concatenated in
   document order, after Unicode NFC normalization and whitespace
   collapse.  If content.scope is present and matches nothing, the
   canonical digest is unverifiable for that document and Detectors MUST
   fall back to the exact form where present.  If the selector matches
   multiple elements, the first match in document order is the scope.
   The exact digest covers the document octets as served.  These rules
   MUST be deterministic: different Detectors MUST produce identical
   digests for identical logical content, and any ambiguity discovered
   in the rules is a defect to be resolved in this specification rather
   than by Detector convention.

Hood                    Expires 13 February 2027                [Page 7]
Internet-Draft                   Earmark                     August 2026

5.2.  Plain Text Binding

   For text distributed without markup, the primary form is the trailer:
   a final line carrying the Earmark: label, the Mark URI, and a digest
   prefix, as in Section 4.  The trailer is visible, survives copy and
   paste, and is honest about being present.

   A secondary, OPTIONAL form encodes the same reference using Unicode
   tag and zero-width characters distributed through the text.  Its
   limitations are significant and MUST be documented wherever it is
   offered: sanitizers strip it, some editors drop it in transit,
   accessibility tools may expose or mangle it, and security scanners
   may flag invisible characters as steganography.  Publishers SHOULD
   prefer the trailer and treat the invisible form as defense in depth
   rather than a primary carrier.

5.3.  Media Binding

   For images, audio, and video, this Binding is the strongest in the
   document, because the infrastructure already exists.  The Mark
   travels within a C2PA manifest [C2PA], and the preference content
   aligns with the CAWG training and data mining assertion [CAWG]: where
   that assertion can carry the preference, the Earmark places the AI
   Preference vocabulary terms inside or alongside it rather than
   inventing a parallel preference model for media.  Earmark's
   contribution for media is the common Mark Object and verification
   procedure shared with text; the embedding, signing, and manifest
   handling are C2PA's.

5.4.  HTTP Binding

   For transit, an Earmark response header carries the Mark Object or
   its URI, providing the perimeter form of the same assertion for
   direct fetches.  This Binding is complementary to the attachment
   mechanisms of [AIPREF-ATTACH], and its header name and syntax SHOULD
   align with that document as it stabilizes, so the perimeter and
   embedded forms stay one family.

5.5.  AGTP Binding

   For content retrieved over the Agent Transfer Protocol, the Mark
   Object or its URI travels as an Earmark field in the response
   envelope, and the reservation is surfaced in discovery metadata, so
   an agent learns that content is earmarked before fetching it.

   The agent-native case differs from the HTTP case in one important
   way.  On the web, honoring a Mark is a choice each consumer makes
   after parsing.  On a transport that supplies verifiable agent

Hood                    Expires 13 February 2027                [Page 8]
Internet-Draft                   Earmark                     August 2026

   identity, Mark handling is specifiable as protocol behavior, and the
   normative requirements in this paragraph apply only on such
   transports.  An agent receiving earmarked content MUST evaluate pref
   before using the content for any reserved purpose, SHOULD skip
   ingestion of content whose reservation excludes its purpose, MAY
   follow license to negotiate a grant where one is offered, and MUST
   record verified Marks for content it retains.  An agent that ingests
   earmarked content against its reservation is identifiable and
   attributable, because the transport carries the agent's verifiable
   identity.  The Mark states the preference; the transport supplies the
   accountable party.  The behavioral profile above is a candidate for a
   short companion applicability note, keeping this document's core
   transport-neutral.

5.6.  Statistical Bindings

   Statistical and steganographic text embedding is an active research
   area.  This document reserves a Binding registry slot (Section 12) so
   such techniques register as they mature, and deliberately
   standardizes none of them now.

5.7.  Covert Bindings

   The Bindings above are overt.  Publishers MAY additionally apply a
   covert Binding, an embedding detectable only with a detection key
   held by the rights holder or, optionally and by the holder's explicit
   choice, escrowed to a detection service.  The purpose is rights
   protection for the publisher's own content, and the asymmetry is the
   value: an adversary who strips every overt Mark cannot be confident a
   covert Mark is gone, so content found stripped of overt Marks while
   carrying a verifiable covert Mark demonstrates both the assertion and
   the deliberate removal.  Covert Bindings register in the same
   registry with their detection-key model stated.  This section is a
   concept-level description and a candidate for a companion document.

6.  Detection and Verification

   A Detector processing content:

   1.  Extracts candidate Marks from each supported Binding.  Where a
       Binding carries a Mark URI rather than the Mark Object, the
       Detector retrieves the Mark Object from that URI; retrieval alone
       establishes nothing.

   2.  Verifies the signature over the canonicalized Mark Object.  For
       retrieved external Marks this step and the digest comparison in
       step 3 apply in full: the URI is a pointer, and only the digest
       match binds the retrieved Mark to the content in hand.

Hood                    Expires 13 February 2027                [Page 9]
Internet-Draft                   Earmark                     August 2026

   3.  Computes the applicable digest per the Binding's rules and
       compares against content.digests.  An exact match verifies the
       copy in hand.  A canonical match verifies the logical content
       across reformatting.  A valid signature with no digest match
       means the content was modified after marking, and the Mark still
       establishes the assertion over the original content; Detectors
       MUST treat it as exactly that, an assertion about different
       content, rather than as verification of the content in hand.

   4.  Where holder.domain is present, MAY corroborate the key via DNS.

   5.  Interprets pref per [AIPREF-VOCAB], applying Section 3.2 where
       multiple Marks verify.

   Verification requires no network access except optional corroboration
   and external Mark retrieval.  Offline verifiability is a design
   requirement of this document, so that detection scales to corpus
   assembly and functions in pipelines with no live connectivity to
   publishers.

   Parties assembling training corpora SHOULD run detection at ingestion
   and SHOULD record verified Marks alongside retained content, so
   preference state is queryable for the corpus.  The rationale:
   ingestion is the single point where detection is cheapest and
   preference state is still attached to acquisition context.  Stronger
   obligations on corpus assemblers are a matter for an applicability
   statement or best-practices document rather than this specification.

7.  Mark Registration

   A rights holder MAY register a Mark at publication by submitting the
   Mark Object and content digests to an append-only, publicly
   verifiable transparency log, following the pattern established for
   certificates and supply-chain statements.  Registration is among the
   highest-value options in this document, because it turns stripping
   into evidence and survives total removal of every circulating copy:
   any party holding any copy of the content can compute its digest and
   query the log, and the timestamped original assertion answers,
   regardless of what the copy in hand carries.  Log formats and
   inclusion-proof mechanics are out of scope and MAY reuse existing
   transparency-log specifications.  This section is a concept-level
   description and a candidate for a companion document.

Hood                    Expires 13 February 2027               [Page 10]
Internet-Draft                   Earmark                     August 2026

8.  Relationship to Existing Mechanisms

   Robots.txt [RFC9309] and the aipref attachment mechanisms
   [AIPREF-ATTACH] govern the fetch, and remain the right tools for the
   perimeter.  The AI Preference vocabulary [AIPREF-VOCAB] supplies
   preference semantics and is reused here unchanged.  C2PA [C2PA] and
   the CAWG training and data mining assertion [CAWG] supply signed,
   content-bound statements for media, and the media Binding rides them
   rather than duplicating them.  TDMRep [TDMREP] expresses reservation
   at the perimeter in web-integrated form.  What the ecosystem lacks,
   and what this document adds, is the portable, signed, offline-
   verifiable carrier for text and other formats outside the C2PA
   family, under one Mark Object shared across all content types.

9.  Security Considerations

   Earmark encrypts nothing, controls no player, and prevents no use.
   It protects an assertion by making it verifiable, portable, and
   evidentiary, layered in the manner of physical currency: overt
   features anyone checks, covert features that defeat removal
   (Section 5.7), and registration that survives circulation
   (Section 7).

   Marks are removable, and the economics of removal matter.  Casual
   republishers, aggregators, and syndication pipelines preserve marks
   by default, because removal requires effort; the population that
   strips marks is the motivated one, and for that population the covert
   and registration layers convert stripping from erasure into evidence.
   Key compromise allows false assertion in the holder's name until
   expiry; short-lived Marks and corroboration bound the exposure.
   False Marks over content the asserter holds no rights to are
   possible, and a Mark names its asserter precisely so such claims have
   an accountable source.  Detectors MUST treat the digests array as the
   sole association between Mark and content.

10.  Privacy Considerations

   Marks identify rights holders by design, and the identification is
   durable and travels with the content.  Individuals publishing under
   this mechanism SHOULD understand that property before adopting it.
   Pseudonymous keys are supported; the assertion is then pseudonymous,
   and its utility in disputes is correspondingly reduced, which is the
   honest trade.

Hood                    Expires 13 February 2027               [Page 11]
Internet-Draft                   Earmark                     August 2026

11.  Legal Context (Informative)

   This section records context rather than making legal claims.  In
   several jurisdictions, removal or alteration of rights management
   information carries independent legal significance, and text-and-
   data-mining reservation regimes require preferences to be expressed
   by machine-readable means.  An Earmark is a machine-readable
   expression of reservation, embedded so it accompanies the content it
   reserves, and its removal is a distinguishable act.  The mark
   supplies the artifact those regimes reference; the regimes supply the
   consequences this document deliberately does NOT.

12.  IANA Considerations

   This document requests a registry for Earmark Bindings (Specification
   Required), initial entries per Section 5; an earmark link relation;
   the application/earmark+json media type; and the Earmark HTTP header
   field, with final header syntax to be aligned with [AIPREF-ATTACH].
   The media type and link relation registrations reference the Security
   Considerations of this document, in particular the stripping and
   false-assertion discussion, as their security considerations.

13.  References

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

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

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

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8785>.

Hood                    Expires 13 February 2027               [Page 12]
Internet-Draft                   Earmark                     August 2026

13.2.  Informative References

   [AIPREF-ATTACH]
              "Attaching AI Preferences", n.d.,
              <https://datatracker.ietf.org/doc/draft-ietf-aipref-
              attach/>.

   [AIPREF-VOCAB]
              "AI Preference Vocabulary", n.d.,
              <https://datatracker.ietf.org/doc/draft-ietf-aipref-
              vocab/>.

   [C2PA]     "Coalition for Content Provenance and Authenticity", n.d.,
              <https://c2pa.org/specifications/>.

   [CAWG]     "Creator Assertions Working Group, Training and Data
              Mining Assertion", n.d., <https://cawg.io/>.

   [RFC9309]  Koster, M., Illyes, G., Zeller, H., and L. Sassman,
              "Robots Exclusion Protocol", RFC 9309,
              DOI 10.17487/RFC9309, September 2022,
              <https://www.rfc-editor.org/rfc/rfc9309>.

   [TDMREP]   "TDM Reservation Protocol", n.d.,
              <https://www.w3.org/community/reports/tdmrep/>.

Appendix A.  Acknowledgments

   The AI Preferences working group's vocabulary, the C2PA and CAWG
   specifications, and the deployment of provider-side output marking
   each demonstrate a piece of the machinery this document composes.

Author's Address

   Chris Hood
   Nomotic AI
   Email: chris@nomotic.ai

Hood                    Expires 13 February 2027               [Page 13]