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
HTML, inline form:
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,
.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, .
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
.
Hood Expires 13 February 2027 [Page 12]
Internet-Draft Earmark August 2026
13.2. Informative References
[AIPREF-ATTACH]
"Attaching AI Preferences", n.d.,
.
[AIPREF-VOCAB]
"AI Preference Vocabulary", n.d.,
.
[C2PA] "Coalition for Content Provenance and Authenticity", n.d.,
.
[CAWG] "Creator Assertions Working Group, Training and Data
Mining Assertion", n.d., .
[RFC9309] Koster, M., Illyes, G., Zeller, H., and L. Sassman,
"Robots Exclusion Protocol", RFC 9309,
DOI 10.17487/RFC9309, September 2022,
.
[TDMREP] "TDM Reservation Protocol", n.d.,
.
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]