]> Nomotic AI

chris@nomotic.ai

Web and Internet Transport AI Preferences earmark AI preferences provenance training rights holders 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.

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

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 defines what preferences mean; the attachment mechanisms 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.

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

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.

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

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 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 . 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 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 signature by the holder key over the JCS-canonicalized 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.

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 (). A compromised key allows false assertion in the holder's name until expiry, which is the argument for short-lived Marks stated above.

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

Examples A Mark Object (line breaks for readability, sig truncated): The pref values above are illustrative and track the categories and values of as it evolves. HTML, external reference form: ]]> HTML, inline form: { "v": 1, "holder": {...}, "content": {...}, "pref": {"train-ai":"n"}, "iat": 1765430400, "sig": "..." } ]]> Plain text, trailer form (the final line of the document): 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.

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.

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

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

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 , and the preference content aligns with the CAWG training and data mining assertion : 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.

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 , and its header name and syntax SHOULD align with that document as it stabilizes, so the perimeter and embedded forms stay one family.

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 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 Bindings Statistical and steganographic text embedding is an active research area. This document reserves a Binding registry slot () so such techniques register as they mature, and deliberately standardizes none of them now.

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.

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.
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 , applying 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.

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.

Relationship to Existing Mechanisms Robots.txt and the aipref attachment mechanisms govern the fetch, and remain the right tools for the perimeter. The AI Preference vocabulary supplies preference semantics and is reused here unchanged. C2PA and the CAWG training and data mining assertion supply signed, content-bound statements for media, and the media Binding rides them rather than duplicating them. 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.

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 (), and registration that survives circulation (). 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.

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.

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.

IANA Considerations This document requests a registry for Earmark Bindings (Specification Required), initial entries per ; an earmark link relation; the application/earmark+json media type; and the Earmark HTTP header field, with final header syntax to be aligned with . 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.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Informative References This document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control how content served by their services may be accessed, if at all, by automatic clients known as crawlers. Specifically, it adds definition language for the protocol, instructions for handling errors, and instructions for caching. n.d. n.d. n.d. n.d. n.d.

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.