| Internet-Draft | Earmark | August 2026 |
| Hood | Expires 13 February 2027 | [Page] |
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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:¶
<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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
A Detector processing content:¶
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.¶
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.¶
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.¶
Where holder.domain is present, MAY corroborate the key via DNS.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶