Human Consent Standard 1.0 Draft Specification

By making AI-related creative rights machine-readable and interoperable at web scale, HCS enables creative industries to protect their rights and receive fair compensation for AI uses of their work, while providing AI Systems with a scalable, rights-respecting path to innovate.

This document is published by the Human Consent Standard Governance Board as a Draft for review and comment. It reflects contributions and reviews from the HCS Artist Governance Board, the HCS Industry Governance Board, and the HCS Policy Governance Board.

This Draft is a work in progress, is subject to change, and MUST NOT be used for production implementation.

To improve readability, this specification uses a small number of editorial conventions and choices that differ from those used in more formal technical standards documents, including:

• Some examples in this document show only a subset of the elements and attributes required by this specification for readability.
• JSON-LD examples are shown without XML escaping for readability.
• Figures in this specification are explanatory and non-normative.

The following forward-looking provisions are included in draft normative form to show the intended final HCS 1.0 conformance model and solicit review feedback. This Draft MUST NOT be used for production implementation. The operational dependencies for these provisions will be finalized before publication of the final HCS 1.0 specification:

• Registry authorization by the Human Consent Standard Governance Board, including authorization requirements, authoritative records, suspension, revocation, availability, caching, and verification.
• The Human Consent Registration Authority and authorized Registration Agencies, including identifier assignment, governance, lookup record formats and access protocols, availability, caching, failure handling, and audit mechanisms.
• For purposes of this Draft, a Schema Profile with status Draft satisfies a requirement for a finalized Schema Profile. This exception will not apply in the final HCS 1.0 specification.
• The OLP-HCS protocol and server attribute.

Creative rights associated with expressive Works, Identities, Characters, and protected Marks are administered through a complex ecosystem of individual artists, artist owned entities and estates, organizations, including guilds, collective management organizations, studios, agencies, publishers, and brand owners. While these individuals and entities often operate as sources of record for creative rights, their rights data and licensing processes are typically maintained through proprietary systems, contracts, and human-mediated workflows that do not scale to automated AI use. As a result, AI Systems face persistent challenges in identifying, respecting, and licensing creative rights at scale.

The Human Consent Standard (HCS) 1.0 is an open, XML-based extension module to the Really Simple Licensing (RSL) standard. It defines a profile that extends RSL 1.0 to enable Rights Holders and their authorized Representatives to specify machine-readable usage restrictions and licensing terms that govern how AI Systems may train on, reproduce, generate, adapt, or emulate Rights Subjects, including:

• Works: compositions, sound recordings, films, books, screenplays, visual art, and other protected artistic or literary works, including protected expressive elements and distinctive expressive characteristics.

• Identities: the name, image, likeness, voice, signature, and persona of identifiable natural persons, including performers, authors, public figures, and posthumous personas managed by estates.

• Characters: protected fictional characters, including their names, visual depiction, voice, persona, and specific portrayals associated with particular productions or performers.

• Marks: protected marks and designs, including trademarks, service marks, logos, trade dress, product design and configuration, surface ornamentation, and designs protected under industrial design, design patent, or similar regimes.

HCS supports:

• Rights Subject–Level Licensing: Expression of licensing terms that apply to identified Rights Subjects as abstract legal entities, rather than to individual digital assets, enabling consistent interpretation across training, reuse, redistribution, and AI-generated representations.

• Global Rights Subject Identification: Unambiguous identification of Rights Subjects allowing AI Systems to distinguish Rights Subjects from similarly named or described subjects.

• Registry-Wide Default Policies: Expression of default licensing terms for Rights Subjects represented by a Registry, enabling Registries, trade organizations, policymakers, and other authoritative bodies to publish baseline AI rights policy for the repertoires or populations they represent.

• Certification: Cryptographically verifiable certification by entities such as law firms, guilds, or studios, indicating that a Rights Declaration was reviewed against supporting documentation.

• Standardized Discovery: Discovery and retrieval of Rights Subject licensing statements through interoperable, web-scale publication mechanisms.

• Automated Rights Authorization: Evaluation of Rights Subject licensing terms by AI Systems and, where required, linkage to external authorization, licensing, or Clearance processes through license servers implementing the HCS Open License Protocol (OLP-HCS). OLP-HCS is based on the Open License Protocol defined by RSL 1.0 and will be specified in the final HCS 1.0 specification.

Together, these mechanisms enable HCS conforming AI Systems to identify Rights Subjects, determine the applicable Rights Declarations, and apply their usage restrictions and licensing terms at web scale.

HCS MAY be used to express machine-readable prohibitions or protective limitations for identifiable natural persons under 18 years of age. It MUST NOT be used to grant, signal, condition, or facilitate permission for AI-based training, generation, reproduction, adaptation, emulation, or related uses involving the identity of a minor, whether such permission would otherwise be unconditional, conditional, paid, or subject to a Clearance process. Applicable law may impose additional limits, including different age thresholds, on whether identity-related AI uses may be authorized.

This specification does not define a universal mechanism for determining whether a particular identified natural person is a minor. However, if an AI System can determine from relevant authoritative subject-specific information that the Rights Subject is an identifiable natural person under 18 years of age, the AI System MUST treat any HCS permission, Clearance path, payment mechanism, license server, or other authorizing term for that person’s identity as non-operative. Only prohibitions and other protective limitations MAY be evaluated.

HCS MAY also be used by government authorities, regulators, or other authoritative bodies to publish default protective policies for minors through Registries using Default Declarations under Section 3.1.5.

The absence of a Rights Declaration, or the presence of a declaration that is not operative under this specification, MUST NOT be interpreted as a waiver, abandonment, license, or grant of rights by any Rights Holder, nor does it determine whether a particular use is permissible or impermissible under applicable law.

HCS is an opt-in mechanism for expressing machine-readable licensing terms. It does not require participation and does not modify or diminish legal rights that exist independently of this specification. AI Systems MUST NOT infer permission, authorization, or lack of restriction from the absence of an HCS declaration or from a declaration that is not operative.

Rights Declarations are not permanent grants or transfers of rights. They are revocable declarations of machine-readable AI usage restrictions and licensing terms that may be updated, withdrawn, or limited by time. The absence of a valid-until attribute does not make a declaration irrevocable or permanent, and does not prevent the Rights Holder or authorized Representative from later withdrawing the declaration or issuing a related declaration.

Rights Holders and their authorized Representatives may update or withdraw Rights Declarations. AI Systems MUST confirm that a declaration remains current in accordance with Section 3.1.8 before relying on it, and any update or withdrawal applies only to uses occurring after it takes effect.

Unlike RSL declarations, which apply to specific digital assets identified by a canonical URL, HCS declarations apply to the referenced Rights Subject wherever it may appear, independent of any particular file, page, or distribution. HCS conforming AI Systems MUST interpret and apply operative HCS declarations wherever the Rights Subject is reproduced, generated, adapted, emulated, synthesized, or used for training, fine-tuning, model adaptation, or other model-development activity, subject to any territorial limitation in the declaration.

This section provides non-normative examples that illustrate how HCS expresses common licensing scenarios.

Example: Prohibit Performer Identity AI Use

This example shows an HCS document that prohibits AI Systems from training on or generating digital representations of a performer, including the performer’s name, image, likeness, voice, movement, or signature. The Rights Subject is identified through a Registry record, and the <prohibits> element states that the specified AI uses are not permitted.

<rsl xmlns="https://rslstandard.org/rsl"
    xmlns:hcs="https://humanconsent.org/hcs">

  <hcs:right
    registry="https://agency.example"
    territory="US"
    registration-id="HCRN-0000-0000-0"
    issued="2026-01-01T00:00:00Z"

    subject="identity"
    subject-id="HCSI-0000-0001-1">

    <schema type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@id": "https://id.humanconsent.org/HCSI-0000-0001-1",
        "@type": "Person",
        "additionalType": "https://humanconsent.org/schemas/identity",
        "name": "Example Actor",
        "jobTitle": "Actor",
        "identifier": [
          {
            "@type": "PropertyValue",
            "propertyID": "IMDb",
            "url": "https://www.imdb.com/name/{IMDB_NAME_ID}"
          }
        ]
      }
    </schema>

    <license>
      <prohibits type="usage">hcs:ai-generate hcs:ai-train</prohibits>

      <legal type="attestation">true</legal>
      <legal type="contact">https://agency.example/contact</legal>
    </license>

  </hcs:right>
</rsl>

Example: Creative Work AI Rights Declaration

This example shows an HCS document that permits AI generation use of a musical composition only through the referenced Clearance process. The Rights Subject is identified through a Registry record, and the <payment> element links to the Clearance process.

<rsl xmlns="https://rslstandard.org/rsl"
    xmlns:hcs="https://humanconsent.org/hcs">

  <hcs:right
    registry="https://registry.example"
    territory="CA GB AU"
    registration-id="HCRN-0000-0001-1"
    issued="2026-01-01T00:00:00Z"

    subject="work"
    subject-scope="composition"
    subject-id="HCSI-0000-0001-1">

    <schema type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@id": "https://id.humanconsent.org/HCSI-0000-0001-1",
        "@type": "MusicComposition",
        "additionalType": "https://humanconsent.org/schemas/composition",
        "name": "Example Song",
        "identifier": [
          {
            "@type": "PropertyValue",
            "propertyID": "ISWC",
            "value": "{ISWC}"
          },
          {
            "@type": "PropertyValue",
            "propertyID": "OfficialPage",
            "url": "https://registry.example/works/WORK-123456"
          }
        ],
        "creator": {
          "@type": "Person",
          "name": "Jane Doe"
        }
      }
    </schema>

    <license>
      <permits type="usage">hcs:ai-generate</permits>

      <payment>
        <custom>https://registry.example/ai-clearance.html</custom>
      </payment>

      <legal type="attestation">true</legal>
      <legal type="contact">https://registry.example/contact</legal>
    </license>

  </hcs:right>
</rsl>

The keywords MUST, MUST NOT, REQUIRED, SHOULD, MAY, and OPTIONAL follow [RFC 2119] and [RFC 8174].

Example: Music Licensing

This example shows how these terms might map to a typical music licensing scenario.

The XML namespace name for the HCS extension module is:

https://humanconsent.org/hcs

All HCS documents MUST declare the HCS namespace on the root <rsl> element and SHOULD use the hcs prefix. HCS elements in that namespace MUST be interpreted using XML namespace processing as defined by [XML Namespaces]. Attributes defined by this specification on HCS elements are unprefixed and are not in any XML namespace. XML namespace processing does not apply to literal token strings defined by this specification.

<rsl xmlns="https://rslstandard.org/rsl"
    xmlns:hcs="https://humanconsent.org/hcs">
  ...
</rsl>

Elements defined by RSL 1.0 and reused by this specification are in the RSL namespace, even when they appear within <hcs:right>. These include <schema>, <license>, <permits>, <prohibits>, <payment>, <custom>, and <legal>. HCS-specific elements, including <hcs:right>, <hcs:certification>, <hcs:includes>, and <hcs:included>, are in the HCS namespace.

HCS attribute values and token values defined by this specification are case-sensitive unless otherwise specified. The usage tokens hcs:ai-generate and hcs:ai-train are literal RSL token identifiers, not XML qualified names.

All HCS timestamp attributes and required Sitemap <lastmod> values defined by this specification use the Timestamp format defined in Section 2.1.

HCS documents MUST be encoded as UTF-8 and, when transmitted over HTTP or another Internet protocol, MUST be served with the RSL 1.0 media type application/rsl+xml.

When this specification requires one URL value to match another, the values MUST be identical strings; no URL normalization is applied.

HCS is an extension module of Really Simple Licensing (RSL) 1.0. It defines an RSL document profile for licensing terms that apply to Rights Subjects rather than to specific digital assets.

An HCS document MUST contain one or more <hcs:right> elements as direct children of the RSL <rsl> root element. Each <hcs:right> element defines a Rights Declaration for a Rights Subject or Subject Class and associates it with one or more RSL <license> elements. The RSL <rsl> root element MAY include a max-age attribute that provides the default revalidation period for contained <hcs:right> declarations as defined in Section 3.1.8.

The <hcs:right> element is analogous to an RSL <content> element, but defines a Rights Declaration for a Rights Subject rather than for a specific digital asset. RSL core elements used within <hcs:right>, including <license> and <payment>, retain their RSL 1.0 meanings and are subject to the additional HCS requirements defined by this specification.

All applicable terms in the <license> elements within an operative <hcs:right> declaration are evaluated together under the RSL 1.0 license-evaluation rules.

RSL processors that do not implement HCS MUST ignore <hcs:right> elements as extension content. HCS does not deprecate or alter RSL 1.0 <content> elements, and both models MAY appear in the same RSL document.

An HCS declaration is operative only if the declaration and every contained <license> element satisfy all applicable requirements of this specification, except where this specification expressly defines a more specific effect.

HCS usage tokens are literal, case-sensitive strings. The hcs: prefix is part of the token value, not an XML namespace prefix, and unqualified RSL usage tokens are not aliases. Token order has no significance, and duplicate values MUST be ignored.

Within <hcs:right>, HCS 1.0 permits only the usage tokens listed in the table above. Any other usage token is unrecognized, and the enclosing <hcs:right> declaration is not operative.

HCS usage tokens are independent. A single AI activity may implicate one or both tokens, and AI Systems MUST evaluate each applicable token independently. For subject="identity", AI Systems MUST apply the minor-protection rule in Section 1.1.

The <hcs:right> element defines a Rights Declaration for a Rights Subject or Subject Class. It includes structured metadata for that subject or class and one or more RSL <license> elements that state the applicable terms.

A <hcs:right> element MUST appear as a direct child of the RSL <rsl> root element and MUST contain the following direct children:

• exactly one RSL <schema> element, as defined in Section 3.2
• one or more RSL <license> elements
• no more than one RSL <terms> element
• no more than one <hcs:certification> element, as defined in Section 3.3
• <hcs:includes> or <hcs:included> elements only as permitted by Section 3.4

Each <license> element within a <hcs:right> element MUST include exactly one <legal type="attestation"> element and exactly one <legal type="contact"> element, as defined in Section 6.4.

A <license> child of <hcs:right> MAY contain the RSL 1.0 license child elements permitted by the HCS profile, subject to the HCS-specific requirements and constraints defined by this specification.

The order of <schema>, <license>, <terms>, <hcs:certification>, <hcs:includes>, <hcs:included>, and extension child elements is not significant.

Each <hcs:right> element MUST identify the Registry, declaration, and applicable Rights Subject or Default Declaration class. It MUST contain exactly one of subject-id or subject-class.

AI Systems evaluate <hcs:right> declarations under the lifecycle, revalidation, conflict, and Registry authorization rules defined in Sections 3.1.7, 3.1.8, 3.1.9, and 6.

The issued attribute MUST contain a Timestamp identifying when the Rights Declaration identified by registration-id was first issued.

The issued value is stable for that registration identifier. If the Rights Declaration is updated under the same registration identifier, the issued value remains unchanged. A Rights Declaration assigned a different registration identifier has its own issued value.

The issued value does not identify the time of HCRN assignment, certification, update, or publication.

A <hcs:right> element that contains subject-class is a Default Declaration. Default Declarations allow authoritative bodies that administer a defined set of Rights Subjects to publish baseline AI rights policy through Registries without requiring an individual declaration for every covered subject.

The subject-class attribute identifies a Registry-defined class of Rights Subjects and MUST be interpreted as follows:

• The attribute MUST appear in a Default Declaration, MUST NOT appear with subject-id, and MUST be an absolute HTTPS URL.
• The URL is an identifier and is not required to identify a publicly retrievable resource.
• The publishing Registry defines the class and the method by which an AI System determines membership. The membership method MAY use authenticated Registry services, private data, contractual integrations, published resources, or other Registry-defined processes.

The scope of a Default Declaration is defined by the registry, subject-class, subject, the Schema Profile identified by the <schema> object’s additionalType property, and any limiting subject-scope and territory values. In a Default Declaration, the <schema> element provides machine-readable metadata describing the covered Subject Class rather than a single Rights Subject.

An AI System MUST apply a Default Declaration only where it can determine, using the membership method established by the Registry, that the Rights Subject is covered by the declaration. If an AI System lacks that basis, the Default Declaration does not apply. The <schema> element describes the covered Subject Class but is not sufficient, by itself, to establish membership in that class.

A declaration that identifies a specific Rights Subject using subject-id is more specific than an otherwise applicable Default Declaration. Declaration Conflicts involving Default Declarations are governed by Section 3.1.9.3.

The use of subject-class does not establish that a particular Rights Subject belongs to the covered class. Membership and dispute handling are governed by this section and Section 6.

Example: Guild or industry organization default identity restriction

This example shows an HCS document published by a guild or industry organization that prohibits AI Systems from training on or generating digital representations of represented members, including their name, image, likeness, voice, or movement. The subject-class URL points to a Registry resource that identifies or verifies the people represented by the guild.

<rsl xmlns="https://rslstandard.org/rsl"
    xmlns:hcs="https://humanconsent.org/hcs">

  <hcs:right
    registry="https://guild.example"
    registration-id="HCRN-0000-0008-8"
    issued="2026-01-01T00:00:00Z"

    subject="identity"
    subject-class="https://guild.example/hcs/members">

    <schema type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@id": "https://guild.example/hcs/members",
        "@type": "Collection",
        "additionalType": "https://humanconsent.org/schemas/identity",
        "name": "Example Guild Represented Members",
        "description": "Actors represented by Example Guild for purposes of this Default Declaration.",
        "publisher": {
          "@type": "Organization",
          "name": "Example Guild",
          "url": "https://guild.example"
        }
      }
    </schema>

    <license>
      <prohibits type="usage">hcs:ai-generate hcs:ai-train</prohibits>

      <legal type="attestation">true</legal>
      <legal type="contact">https://guild.example/contact</legal>
    </license>

  </hcs:right>
</rsl>

HCS 1.0 defines four standardized subject values. The subject value classifies the Rights Subject identified by subject-id, or the Rights Subjects covered by subject-class, and determines which category-specific rules apply to the declaration. It also determines the subject-scope vocabulary, if any, that may be used to limit the declaration within that category.

A single AI activity may implicate more than one Rights Subject, and AI Systems MUST evaluate each applicable declaration independently.

HCS 1.0 defines the permitted subject-scope values for the work, identity, and character Rights Subject categories. A subject-scope value identifies a rights component or protected aspect governed by the declaration. It does not classify the Rights Subject, identify another Rights Subject, determine the applicable Schema Profile, or require correspondence with the <schema> metadata.

The subject-scope attribute MUST NOT be used with subject="mark".

The subject-scope attribute MUST contain one or more values defined for the applicable subject category as a whitespace-separated list. A declaration containing any other subject-scope value is not operative. Order has no significance, and duplicate values MUST be ignored. If the subject-scope attribute is absent, the declaration applies to the identified Rights Subject without limitation to any particular Rights Scope.

Each subject-scope value applies only within the subject category of the enclosing <hcs:right> element and only to the identified Rights Subject. It does not extend the declaration to a separately identified component Rights Subject, which is governed by its own declaration and, where applicable, Section 3.4.

Defined subject-scope values are independent unless this specification defines an overlap or containment rule. A declaration applies only to the listed Rights Scope values, or to all Rights Scopes for the identified Rights Subject if subject-scope is absent.

For purposes of Section 3.1.9, a declaration with no subject-scope attribute overlaps any declaration for the same Rights Subject, and declarations with subject-scope attributes overlap for each identical value.

A <hcs:right subject="work"> element represents licensing terms governing AI-based use of protected expressive elements, distinctive expressive characteristics, or asserted style-related rights in an artistic or literary work. It authorizes or prohibits an AI System from training on, reproducing, generating, adapting, or emulating protected works or their distinctive expressive characteristics within the bounds of the Rights Declaration. Permitted or prohibited uses MAY include:

• Reproduction or adaptation of a creative work (e.g., song, painting, book, screenplay, or film)
• “In-the-style-of” synthesis, where outputs emulate expressive elements or distinctive expressive characteristics associated with the work

Standardized subject-scope Values

This specification defines the following standardized subject-scope values for <hcs:right subject="work">.

Example: Creative Work Rights Declaration

<hcs:right
  registry="https://registry.example"
  registration-id="HCRN-0000-0004-4"
  issued="2026-01-01T00:00:00Z"

  subject="work"
  subject-scope="composition"
  subject-id="HCSI-0000-0001-1">

  <schema type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@id": "https://id.humanconsent.org/HCSI-0000-0001-1",
      "@type": "MusicComposition",
      "additionalType": "https://humanconsent.org/schemas/composition",
      "name": "Example Song",
      "identifier": [
        {
          "@type": "PropertyValue",
          "propertyID": "ISWC",
          "value": "{ISWC}"
        }
      ],
      "creator": {
        "@type": "Person",
        "name": "Jane Doe"
      }
    }
  </schema>

  <license>
    <prohibits type="usage">hcs:ai-generate hcs:ai-train</prohibits>

    <legal type="attestation">true</legal>
    <legal type="contact">https://registry.example/contact</legal>
  </license>

</hcs:right>

A <hcs:right subject="identity"> element represents licensing terms governing AI-based representations of an identifiable natural person or professional persona. It authorizes or prohibits an AI System from training on, depicting, or generating representations of an identifiable person within the bounds of the Rights Declaration. Permitted or prohibited uses MAY include:

• Digital or synthetic likeness, image, voice, or distinctive movement (e.g., actor, musician, dancer, athlete, or influencer)
• CGI, motion-capture, AI-generated avatars, or other synthetic representations, including deepfakes
• Posthumous or estate-managed personas

For identifiable natural persons under 18 years of age, HCS MAY be used only to express prohibitions or other protective limitations. As provided in Section 1.1, it MUST NOT be used to grant, signal, or imply permission for AI-based training, generation, reproduction, adaptation, emulation, or related identity uses of such persons.

Professional labels such as actor, writer, musician, performer, athlete, or influencer describe the person or persona; they do not create separate HCS Rights Subject categories.

Standardized subject-scope Values

This specification defines the following standardized subject-scope values for <hcs:right subject="identity">.

For purposes of HCS scope evaluation, image and likeness are independent Rights Scope tokens. A declaration limited to image applies to captured or recorded visual depictions of the individual. A declaration limited to likeness applies to recognizable visual resemblance or evocation of the individual, including synthetic or non-photographic depictions. Rights Holders that intend terms to apply to both SHOULD include both tokens or omit the subject-scope attribute.

Example: Performer Identity Rights Declaration

<hcs:right
  registry="https://agency.example"
  registration-id="HCRN-0000-0005-5"
  issued="2026-01-01T00:00:00Z"

  subject="identity"
  subject-id="HCSI-0000-0001-1">

  <schema type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@id": "https://id.humanconsent.org/HCSI-0000-0001-1",
      "@type": "Person",
      "additionalType": "https://humanconsent.org/schemas/identity",
      "name": "Example Actor",
      "jobTitle": "Actor",
      "identifier": [
        {
          "@type": "PropertyValue",
          "propertyID": "IMDb",
          "url": "https://www.imdb.com/name/{IMDB_NAME_ID}"
        }
      ]
    }
  </schema>

  <license>
    <prohibits type="usage">hcs:ai-generate hcs:ai-train</prohibits>

    <legal type="attestation">true</legal>
    <legal type="contact">https://agency.example/contact</legal>
  </license>

</hcs:right>

A <hcs:right subject="character"> element represents licensing terms governing AI-based representations of a protected fictional character, including the character’s name, likeness, distinctive attributes, persona, and portrayal. It authorizes or prohibits an AI System from training on, depicting, generating, adapting, or emulating the character within the bounds of the Rights Declaration. Covered uses MAY include:

• Visual depictions of the character (illustration, animation, photorealistic rendering)
• Voice, dialogue, or behavior in the character’s persona
• In-universe scenes, stories, or derivative works featuring the character
• Synthetic portrayals that closely imitate the character’s distinctive visual attributes, voice, or persona

Standardized subject-scope Values

This specification defines the following standardized subject-scope values for <hcs:right subject="character">.

Example: Character Rights Declaration

<hcs:right
  registry="https://studio.example"
  registration-id="HCRN-0000-0006-6"
  issued="2026-01-01T00:00:00Z"

  subject="character"
  subject-id="HCSI-0000-0001-1">

  <schema type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@id": "https://id.humanconsent.org/HCSI-0000-0001-1",
      "@type": "Person",
      "additionalType": "https://humanconsent.org/schemas/character",
      "name": "Example Character",
      "description": "A fictional detective appearing in the Example Stories series.",
      "identifier": [
        {
          "@type": "PropertyValue",
          "propertyID": "Wikidata",
          "url": "https://www.wikidata.org/entity/{WIKIDATA_QID}"
        }      
      ]
    }
  </schema>

  <license>
    <prohibits type="usage">hcs:ai-generate hcs:ai-train</prohibits>

    <legal type="attestation">true</legal>
    <legal type="contact">https://studio.example/contact</legal>
  </license>

</hcs:right>

A <hcs:right subject="mark"> element represents licensing terms governing AI-based use of a protected mark or design, including trademarks, service marks, logos, trade dress, product design and configuration, surface ornamentation, and designs protected under industrial design, design patent, registered design, or similar regimes. This includes marks and designs used in fashion, jewelry, luxury goods, consumer products, furniture, automotive products, packaging, retail environments, and other industries.

A mark or design Rights Declaration authorizes or prohibits an AI System from training on, depicting, generating, adapting, or emulating protected marks, trade dress, product designs, surface ornamentation, or other protected design features within the bounds of the Rights Declaration. Covered uses MAY include:

• Model-development uses involving protected marks or designs
• Depictions of branded products, logos, marks, trade dress, product designs, or surface ornamentation
• Emulation of trade dress, product design and configuration, surface ornamentation, or other protected mark or design features
• Synthetic product imagery, virtual try-on assets, or marketing content featuring protected marks or designs
• Brand-referential outputs that could reasonably imply source, sponsorship, endorsement, affiliation, or commercial association

Example: Mark Rights Declaration

<hcs:right
  registry="https://brand.example/registry"
  registration-id="HCRN-0000-0007-7"
  issued="2026-01-01T00:00:00Z"

  subject="mark"
  subject-id="HCSI-0000-0001-1">

  <schema type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@id": "https://id.humanconsent.org/HCSI-0000-0001-1",
      "@type": "Brand",
      "additionalType": "https://humanconsent.org/schemas/trademark",
      "name": "Example Maison",
      "identifier": [
        {
          "@type": "PropertyValue",
          "propertyID": "USPTOTrademark",
          "value": "{USPTO_TRADEMARK_REGISTRATION_NUMBER}"
        }
      ]
    }
  </schema>

  <license>
    <prohibits type="usage">hcs:ai-generate hcs:ai-train</prohibits>

    <legal type="attestation">true</legal>
    <legal type="contact">https://brand.example/contact</legal>
  </license>

</hcs:right>

A Rights Declaration is not a permanent grant or transfer of rights. It is a revocable declaration of machine-readable licensing terms that may be updated, withdrawn, superseded, or limited by time.

The status, valid-from, and valid-until attributes define the declaration lifecycle. The supersedes and superseded-by attributes link related declarations in the provenance chain. AI Systems MUST evaluate lifecycle attributes when they read or re-read a <hcs:right> declaration.

The issued, valid-from, and valid-until attributes are not modification timestamps. AI Systems detect declaration changes through the revalidation rules in Section 3.1.8.

The max-age attribute defines revalidation requirements for the declaration, its HCRN lookup record, any required HCSI lookup record and Rights Subject Record, and the Association Mechanisms used to establish its operativeness; it does not determine whether the declaration is in force.

The status attribute records the declared state of the declaration. If status is absent, active is assumed.

• If status="active", the declaration may be operative, subject to the other requirements of this specification.

• If status="withdrawn" or status="superseded", the declaration is not operative.

Withdrawn and superseded declarations MAY be referenced for historical purposes.

The valid-from and valid-until attributes define the period during which a declaration is in force. Timestamp values are compared as instants after timezone normalization.

If valid-from is absent, the declaration’s effective start time is its issued time. If valid-from is present, it is the effective start time and MUST NOT precede the declaration’s issued value; otherwise, the declaration MUST be treated as not in force. If valid-until is present, it MUST be later than the effective start time; otherwise, the declaration MUST be treated as not in force.

A declaration is in force at time t only if t is at or after the effective start time and, where valid-until is present, before valid-until. The valid-until value is exclusive. An AI System MUST NOT rely on a declaration for activities outside that period. For a same-HCRN update, valid-from identifies the earliest time at which the current published terms are in force.

If a same-HCRN update changes the Declaration Scope or the licensing or Clearance terms for any covered use, the updated declaration MUST include a valid-from value identifying the earliest time at which its current published terms are in force. That valid-from value MUST NOT precede the time at which the updated declaration was first made available at the declaration’s official publication location.

If an AI System first observes a same-HCRN update after its stated valid-from time, has satisfied the revalidation requirements in Section 3.1.8, and cannot determine that the updated declaration was made available at the official publication location no later than the stated valid-from time, it MUST treat the current published terms as effective no earlier than its first observation time. This rule applies whether the update grants, expands, withdraws, narrows, or prohibits permission.

The supersedes and superseded-by attributes define a declaration’s provenance chain by linking replacement Rights Declarations for the same Rights Subject or Subject Class.

The supersedes attribute identifies one or more prior HCRNs in the provenance chain. The superseded-by attribute identifies one or more later HCRNs in the provenance chain and MUST be present when status="superseded". Each value, when present, MUST be a whitespace-separated list of syntactically valid HCRN identifiers.

An AI System MAY use the provenance chain to locate related declarations, cite related HCRNs, maintain audit records, or present declaration history. Each declaration is evaluated independently under the Registry authorization, lifecycle, validity, revalidation, license-evaluation, and conflict rules of this specification.

Provenance-chain references are informational and do not affect the declaration’s lifecycle state.

The max-age attribute defines how long an AI System MAY rely on a previously retrieved <hcs:right> declaration, its HCRN lookup record, any required HCSI lookup record and Rights Subject Record, and each Association Mechanism on which it relied. It is a revalidation rule only and does not determine whether a declaration is in force. The max-age value MUST be a positive integer number of days; for this purpose, one day means 24 hours.

If neither the <rsl> element nor the <hcs:right> element specifies max-age, AI Systems MUST apply a default value of 30. If only the <rsl> element specifies max-age, that value applies to each contained <hcs:right> declaration. If only the <hcs:right> element specifies max-age, that value applies to that declaration. If both specify max-age, the smaller value applies. Rights Holders that require faster propagation of updates, withdrawals, or licensing changes SHOULD specify a shorter max-age value.

Except as provided below, after the effective revalidation period has elapsed, the declaration is not operative until the AI System has revalidated the declaration, its HCRN lookup record, any required HCSI lookup record and Rights Subject Record, and each Association Mechanism on which it relied.

An AI System MAY revalidate a declaration by retrieving it or by using authoritative modification signals, such as Sitemaps <lastmod> values, HTTP Last-Modified or ETag metadata, or equivalent mechanisms.

If the declaration, HCRN lookup record, or any relied-on Association Mechanism has changed, the AI System MUST retrieve and re-evaluate the applicable declaration before relying on it. If a required HCSI lookup record or Rights Subject Record has changed, the AI System MUST re-evaluate the applicable requirements in Sections 4.4 and 4.5. If the Registry that published the declaration is no longer authorized under Section 6.1, or the AI System can no longer verify any applicable Subject Class membership, the declaration is not operative, regardless of the applicable max-age period.

If revalidation fails solely because the declaration, an applicable identifier lookup record or Rights Subject Record, or any relied-on Association Mechanism is unavailable, a previously validated declaration remains operative unless the declaration becomes non-operative for another reason under this specification.

A Declaration Conflict exists when two or more Rights Declarations assert authority to govern the same Rights Subject and overlapping Declaration Scope. This section defines how those competing declarations are identified and handled.

A Declaration Conflict is limited to the overlapping Declaration Scope. When declarations overlap only for particular Rights Scope or geographic areas, the conflict is limited to those scopes and areas.

For example, if one declaration asserts subject-scope="image likeness" and another asserts subject-scope="likeness voice", a Declaration Conflict exists only for the likeness Rights Scope. The image and voice Rights Scopes are unaffected.

A use may implicate more than one Rights Scope. Each operative declaration applicable to an implicated Rights Scope MUST be evaluated independently under RSL 1.0. A permission applicable to one Rights Scope does not override a prohibition applicable to another Rights Scope.

When a Declaration Conflict exists, none of the conflicting declarations is operative within the overlapping Declaration Scope. An AI System MUST treat every HCS usage token as prohibited within that scope until the Declaration Conflict is resolved.

Each conflicting declaration remains part of the declaration record. Portions of its Declaration Scope outside the conflict MAY continue to be evaluated under this specification.

The following figure summarizes the principal stages for evaluating a Rights Declaration. Each stage remains subject to the complete requirements of this specification.

Figure 1. Overview of Rights Declaration evaluation

+----------------------------------------------------------+
| Retrieve candidate Rights Declaration                    |
+----------------------------------------------------------+
                            |
                            v
+----------------------------------------------------------+
| Verify Registry authorization and official HCRN record   |
+----------------------------------------------------------+
                            |
                            v
+----------------------------------------------------------+
| Verify structure, identifiers, Schema Profile, and       |
| required legal elements                                  |
+----------------------------------------------------------+
                            |
                            v
+----------------------------------------------------------+
| If subject-id is present, verify the active HCSI and     |
| Rights Subject Record                                    |
+----------------------------------------------------------+
                            |
                            v
+----------------------------------------------------------+
| Apply lifecycle and revalidation rules                   |
+----------------------------------------------------------+
                            |
                            v
+----------------------------------------------------------+
| Apply Default, component, and territorial scope rules    |
+----------------------------------------------------------+
                            |
                            v
                  +----------------------+
                  | Declaration Conflict?|
                  +----------------------+
                     |                |
                    Yes               No
                     |                |
                     v                v
     +--------------------------+  +-------------------------+
     | Treat affected HCS usage |  | Evaluate applicable     |
     | tokens as prohibited     |  | RSL license terms       |
     +--------------------------+  +-------------------------+

The server attribute identifies the HCS License Server that manages licensing or Clearance for the referenced Rights Subject.

The server value MUST be an absolute HTTPS URL. OLP-HCS defines endpoint discovery, request paths, URL construction, and request semantics.

If the server attribute is present, an AI System MUST obtain authorization from the identified HCS License Server before relying on a permission in the declaration.

For OLP-HCS interactions, the declaration’s registration-id value MUST be used as the stable identifier for the Rights Declaration. OLP-HCS will define any additional request fields, authorization-token formats, payment flows, error handling, and lookup mechanisms.

The optional <hcs:certification> element provides cryptographically verifiable certification for a <hcs:right> declaration. It allows a certifying entity, such as a law firm, guild, collective management organization, studio, registry, or agent, to certify that the declaration has been reviewed against supporting documentation and reflects the claims presented to that entity at the time of certification. The current official Rights Declaration is determined under Section 4.3.2.

A <hcs:right> element MAY contain at most one <hcs:certification> child element.

HCS certifications use JSON Web Signatures (JWS) with an attached XML payload to preserve the integrity of the certified declaration state and provide X.509 certificate material for signer identification and certification-policy evaluation.

The <hcs:certification> element MUST be empty in HCS 1.0 and MUST contain the following attributes.

If present, the role token MUST consist only of ASCII lowercase letters and single hyphens, MUST begin and end with an ASCII lowercase letter, and MUST NOT contain consecutive hyphens.

The jws attribute MUST contain a JWS Compact Serialization value with an attached payload that conforms to Section 3.3.4. A <hcs:certification> element is valid only if it satisfies the requirements of this section. Its validity does not determine whether the enclosing <hcs:right> declaration is operative.

The JWS payload is the UTF-8 byte serialization of the exact <hcs:right> element as it was reviewed and signed by the certifying entity at the time identified by the time attribute. The signer determines the exact serialized form of that element, including attribute order, whitespace, namespace declarations, and character content.

The signed <hcs:right> element MUST be parseable as a standalone HCS element using XML namespace processing. It MUST contain exactly one <hcs:certification> element. That <hcs:certification> element MUST contain a jws attribute with the empty string as its value when the JWS payload bytes are produced.

After signing, the resulting JWS Compact Serialization value is published in the jws attribute of the <hcs:certification> element.

To verify a <hcs:certification> element, a verifier MUST:

1. read the jws attribute value from the <hcs:certification> element in the published HCS document
2. validate the JWS Compact Serialization under Section 3.3.4
3. parse the JWS payload bytes as a well-formed standalone XML <hcs:right> element using XML namespace processing
4. verify that the parsed signed <hcs:right> element contains exactly one <hcs:certification> element and that its jws attribute value is the empty string
5. verify that the registration-id value of the signed <hcs:right> element matches the registration-id value of the enclosing published <hcs:right> element
6. verify that each <hcs:certification> attribute other than jws matches the corresponding attribute in the signed payload

Successful verification confirms that the signed declaration state has not been altered, subject to the signer trust requirements in Section 3.3.3. If verification fails, the <hcs:certification> element is invalid.

Example: Certification Element

<hcs:certification
  name="Example Law Firm"
  contact="https://lawfirm.example/contact"
  role="law-firm"
  time="2026-04-11T15:30:00Z"
  jws="BASE64URL_PROTECTED_HEADER.BASE64URL_PAYLOAD.BASE64URL_SIGNATURE" />

Processors that accept <hcs:certification> signatures MUST validate the x5c certificate path using [RFC 5280] path validation at the certification time identified by the time attribute, subject to the verifier’s trust policy, including any revocation requirements under that policy. A certification is invalid if the signer’s certificate or certificate path was not valid at that time.

The verifier’s trust policy MUST define the certificate trust anchors it accepts. A certification MUST NOT be treated as trusted solely because the signer certificate chains to a public or otherwise accepted certificate authority.

The time attribute identifies the time at which the certifying entity made the certification. The time value MUST NOT precede the issued value in the signed <hcs:right> element and MUST NOT be later than the time of verification.

HCS certifications use JSON Web Signatures (JWS) as defined by [RFC 7515]. The jws attribute value MUST use JWS Compact Serialization with an attached payload. Detached payloads, JWS JSON Serialization, and the unencoded-payload option defined by [RFC 7797] MUST NOT be used.

The JWS payload is the UTF-8 byte serialization defined in Section 3.3.1. The payload MUST be base64url-encoded without padding as the second segment of the JWS Compact Serialization.

HCS 1.0 certifications MUST use the JOSE ES256 algorithm defined by [RFC 7518]. Verifiers MUST reject any JWS where alg is not ES256. Future versions of HCS may define additional permitted signature algorithms.

For ES256, the JWS Signature value MUST use the JOSE ECDSA signature representation defined by RFC 7518: the fixed-length concatenation of the 32-octet unsigned big-endian R value and the 32-octet unsigned big-endian S value, base64url-encoded without padding. DER-encoded ECDSA signatures MUST NOT be used.

The JWS Protected Header MUST contain:

• alg with the value ES256
• cty with the value application/xml
• x5c with a non-empty signer X.509 certificate or certificate chain, as defined by RFC 7515 Section 4.1.6

Each x5c entry MUST be a base64-encoded DER PKIX certificate. The signer’s certificate MUST be the first entry; intermediate CA certificates, if present, MUST follow in chain order. The root certificate MAY be omitted or included, but its presence in x5c does not establish it as a trust anchor. The public key in the signer’s certificate MUST satisfy the ES256 requirements in RFC 7518 Section 3.4.

The JWS Protected Header MUST NOT contain jwk, jku, x5u, b64, or crit. Verifiers MUST reject any JWS whose Protected Header contains any of those parameters. Verifiers MUST also reject any JWS where cty is not application/xml.

Other JWS Protected Header parameters, if present, MUST be ignored for purposes of signer identification and MUST NOT alter the verification rules defined by this profile. The signer’s identity is established solely through x5c.

The optional <hcs:includes> and <hcs:included> elements allow a Rights Declaration for a title, such as a motion picture, book, recording, or game, to identify separately declared component Rights Subjects that appear in that title. For example, a studio’s declaration for a motion picture may identify a component declaration for an actor’s performance in that film.

A title declaration MAY contain one or more <hcs:includes> elements identifying component declarations for that title. A component declaration MUST contain exactly one <hcs:included> element identifying the title in which the component appears. A <hcs:right> element MUST NOT contain both <hcs:includes> and <hcs:included>, and Default Declarations MUST NOT contain either element.

The licensing terms in a component declaration apply only to the component as included in the title identified by <hcs:included>.

The <hcs:includes> element is used in a title declaration to identify a component declaration for that title. For example, a motion picture declaration may use <hcs:includes> to identify a separate declaration for an actor’s performance, song, character, artwork, product design, or mark that appears in the motion picture.

A <hcs:includes> element MUST contain a registration-id attribute identifying the component declaration and MAY contain one RSL <schema> element. If present, the <schema> element is informational only.

The <hcs:included> element is used in a component declaration to identify the title declaration in which the component appears. For example, a component declaration for an identity Rights Subject may use <hcs:included> to identify the motion picture declaration for the film in which the actor appears.

A <hcs:included> element MUST contain a registration-id attribute identifying the title declaration and MAY contain one RSL <schema> element. If present, the <schema> element is informational only.

A component declaration reference is valid only when, after resolving each referenced HCRN to its current official Rights Declaration under Section 4.3.2, the title declaration identifies the component declaration using <hcs:includes>, and the component declaration identifies the title declaration using <hcs:included>.

A component declaration whose reference is invalid is not operative. The title declaration and any other valid component declaration references MAY continue to be evaluated.

Two or more <hcs:includes> references within the same title declaration that identify declarations for the same component Rights Subject and overlapping Declaration Scope are subject to Section 3.1.9.

Example: Movie Declaration Referencing an Actor Performance

This example shows a motion picture Rights Declaration that references a separately declared component identity declaration for an actor’s performance in the movie. The <hcs:includes> element identifies the component declaration, and the component declaration supplies the HCS license terms for the actor’s performance. The <schema> element inside <hcs:includes> is informational only.

<hcs:right
  registry="https://studio.example/registry"
  registration-id="HCRN-0000-0009-9"
  issued="2026-06-01T00:00:00Z"

  subject="work"
  subject-scope="audio-visual"
  subject-id="HCSI-0000-0001-1">

  <schema type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@id": "https://id.humanconsent.org/HCSI-0000-0001-1",
      "@type": "Movie",
      "additionalType": "https://humanconsent.org/schemas/movie",
      "name": "Example Movie",
      "identifier": [
        {
          "@type": "PropertyValue",
          "propertyID": "EIDR",
          "value": "{EIDR}"
        }
      ]
    }
  </schema>

  <!-- Actor performance component declaration -->
  <hcs:includes registration-id="HCRN-0000-000A-A">
    <schema type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@id": "https://id.humanconsent.org/HCSI-0000-0002-2",
        "@type": "Person",
        "additionalType": "https://humanconsent.org/schemas/identity",
        "name": "Example Actor",
        "jobTitle": "Actor",
        "identifier": [
          {
            "@type": "PropertyValue",
            "propertyID": "IMDb",
            "url": "https://www.imdb.com/name/{IMDB_NAME_ID}"
          }
        ]
      }
    </schema>
  </hcs:includes>

  <license>
    <prohibits type="usage">hcs:ai-train hcs:ai-generate</prohibits>

    <legal type="attestation">true</legal>
    <legal type="contact">https://studio.example/legal</legal>
  </license>

</hcs:right>

Example: Component Declaration for an Actor Identity

This example shows a component declaration for an identity Rights Subject as the actor appears in the movie. The <hcs:included> element identifies the movie declaration in which the actor appears. The <schema> element inside <hcs:included> is informational only.

<hcs:right
  registry="https://agency.example/registry"
  registration-id="HCRN-0000-000A-A"
  issued="2026-06-01T00:00:00Z"

  subject="identity"
  subject-scope="image likeness voice movement"
  subject-id="HCSI-0000-0002-2">

  <schema type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@id": "https://id.humanconsent.org/HCSI-0000-0002-2",
      "@type": "Person",
      "additionalType": "https://humanconsent.org/schemas/identity",
      "name": "Example Actor",
      "jobTitle": "Actor",
      "description": "Example Actor as appearing in Example Movie",
      "identifier": [
        {
          "@type": "PropertyValue",
          "propertyID": "IMDb",
          "url": "https://www.imdb.com/name/{IMDB_NAME_ID}"
        }
      ]
    }
  </schema>

  <!-- Movie declaration in which this actor performance appears -->
  <hcs:included registration-id="HCRN-0000-0009-9">
    <schema type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@id": "https://id.humanconsent.org/HCSI-0000-0001-1",
        "@type": "Movie",
        "additionalType": "https://humanconsent.org/schemas/movie",
        "name": "Example Movie",
        "identifier": [
          {
            "@type": "PropertyValue",
            "propertyID": "EIDR",
            "value": "{EIDR}"
          }
        ]
      }
    </schema>
  </hcs:included>

  <license>
    <permits type="usage">hcs:ai-train hcs:ai-generate</permits>

    <payment>
      <custom>https://agency.example/clearance/example-actor-movie-123</custom>
    </payment>

    <legal type="attestation">true</legal>
    <legal type="contact">https://agency.example/legal</legal>
  </license>
</hcs:right>

The hcs:ai-generate usage token governs AI-based generation, reproduction, adaptation, or emulation of the Rights Subject identified by a <hcs:right> declaration. Within a <license>, it indicates whether those uses are permitted or prohibited, subject to the applicable licensing terms.

<permits type="usage">hcs:ai-generate</permits>
<prohibits type="usage">hcs:ai-generate</prohibits>

When evaluated in the context of a <hcs:right> declaration, hcs:ai-generate governs AI uses that include, but are not limited to:

• Generation of visual, audio, textual, or multimodal outputs representing a Rights Subject
• Reproduction or adaptation of distinctive attributes or expressive elements associated with a Rights Subject
• Creation of derivative, emulative, or “in-the-style-of” outputs involving protected expressive elements or distinctive attributes of the Rights Subject
• AI-based uses that may imply association, endorsement, sponsorship, or source with respect to the Rights Subject

The permitted or prohibited scope is determined by the Rights Subject category, the Declaration Scope, the applicable <license> terms, and any linked Clearance mechanism.

AI Systems MUST evaluate hcs:ai-generate independently of any digital asset AI usage categories expressed through RSL <content> elements.

The hcs:ai-train usage token governs AI-based training, pre-training, fine-tuning, model adaptation, or other development or improvement of an AI System using the Rights Subject identified by a <hcs:right> declaration. Within a <license>, it indicates whether those uses are permitted or prohibited, subject to the applicable licensing terms.

<permits type="usage">hcs:ai-train</permits>
<prohibits type="usage">hcs:ai-train</prohibits>

When evaluated in the context of a <hcs:right> element, hcs:ai-train governs AI uses that include, but are not limited to:

• Use of the Rights Subject, or recognizable attributes of it, for training, pre-training, fine-tuning, evaluation, or benchmarking used to develop, tune, adapt, align, select, or improve model weights, model behavior, or system configuration
• Use of the Rights Subject in datasets or other model-development inputs derived from or based on the Rights Subject

The permitted or prohibited scope is determined by the Rights Subject category, the Declaration Scope, the applicable <license> terms, and any linked Clearance mechanism.

AI Systems MUST evaluate hcs:ai-train independently of any digital asset AI usage categories expressed through RSL <content> elements.

RSL 1.0 defines standard, web-native discovery mechanisms that associate rights declarations with specific digital assets. Those mechanisms may locate an RSL document containing HCS declarations, but they do not associate an HCS declaration with an asset or limit its application to that asset.

In contrast to websites, which typically publish a small number of RSL documents that govern their content, Registries may need to publish Rights Declarations for thousands or millions of Rights Subjects. To support discovery and synchronization at that scale, HCS defines a Bulk Publication model based on the Sitemaps Protocol. This model allows AI Systems to locate Rights Declarations, enumerate them for synchronization, and detect changes without refetching unchanged declarations.

Registries publishing large volumes of HCS documents SHOULD organize them using standard XML Sitemaps or Sitemap indexes, served either uncompressed or gzip-compressed. An HCS Sitemap resource is either an XML Sitemap whose <url><loc> entries identify HCS document URLs, or a Sitemap index whose <sitemap><loc> entries identify XML Sitemaps that directly enumerate HCS document URLs. Each <hcs:right> declaration in a referenced HCS document is evaluated independently under this specification.

HCS uses the standard Sitemaps Protocol and does not define a new Sitemap format, but tightens the base Sitemap profile by requiring <lastmod> values for HCS Sitemap resources and requiring those values to use Timestamps. An HCS Sitemap resource MUST satisfy the Sitemaps Protocol and the following additional requirements:

• each <url><loc> entry in an HCS Sitemap MUST use https and point to an HCS document served as application/rsl+xml
• each <sitemap><loc> entry in an HCS Sitemap index MUST use https and point to an XML Sitemap that directly enumerates HCS document URLs
• each <url> and <sitemap> entry MUST include a <lastmod> value using a Timestamp, and MUST update that value when the referenced file changes

An entry that does not satisfy these requirements MUST be ignored for HCS discovery and revalidation.

Removal of an HCS document URL from the most recently retrieved Sitemap or Sitemap index that satisfies the AI System’s revalidation requirement does not change the status of any previously published <hcs:right> declaration. Withdrawal or supersession MUST be expressed through the lifecycle attributes defined in Section 3.1.7.

Removal changes the Association Mechanism. Before relying on the affected declaration, an AI System MUST revalidate the declaration under Section 3.1.8. If revalidation succeeds through the original URL, a redirect, the official declaration URL, or another verified Association Mechanism, the declaration MAY continue to be evaluated under its lifecycle attributes.

Registries SHOULD continue to provide affected declarations, redirects, or equivalent status information at the original URL for at least the applicable revalidation period after withdrawal, supersession, relocation, reorganization, or removal.

Example: HCS Sitemap

<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

  <url>
    <loc>https://registry.example/hcs/licenses-001.xml</loc>
    <lastmod>2026-04-15T00:00:00Z</lastmod>
  </url>

  <url>
    <loc>https://registry.example/hcs/licenses-002.xml</loc>
    <lastmod>2026-04-15T00:00:00Z</lastmod>
  </url>

</urlset>

A Registry that publishes HCS documents SHOULD make an HCS discovery document available at the following well-known URI on each HTTPS origin from which it publishes those documents:

https://<origin>/.well-known/hcs.xml

The HCS discovery document MUST be served as application/xml and MUST be UTF-8 encoded. Its document element MUST be <sitemaps> in the HCS namespace. It MUST contain one or more sitemap child elements in the HCS namespace, each containing the absolute HTTPS URL of an HCS Sitemap resource after XML Schema token whitespace normalization.

<?xml version="1.0" encoding="UTF-8"?>

<hcs:sitemaps xmlns:hcs="https://humanconsent.org/hcs">
  <hcs:sitemap>
    https://registry.example/hcs/sitemap-1.xml
  </hcs:sitemap>
  <hcs:sitemap>
    https://registry.example/hcs/sitemap-2.xml
  </hcs:sitemap>
</hcs:sitemaps>

Each referenced resource MAY be an XML Sitemap or Sitemap index conforming to Section 5.1. Registries publishing more HCS document URLs than may be contained in one Sitemap SHOULD reference a Sitemap index.

Each referenced HCS Sitemap resource MUST use the same origin as the HCS discovery document. Sitemap URL scope is determined from the URL of the referenced Sitemap or Sitemap index under the Sitemaps Protocol.

An AI System discovering HCS documents on an origin SHOULD retrieve /.well-known/hcs.xml, parse each <hcs:sitemap> element in the HCS discovery document, and retrieve every identified HCS Sitemap resource.

If more than one HCS Sitemap resource is discovered through supported discovery mechanisms, the AI System MUST retrieve and evaluate all discovered resources. Duplicate HCS document URLs SHOULD be treated as references to the same resource.

An HCS discovery document, Sitemap, or other discovery mechanism does not establish Registry authorization. Registry authorization is determined under Section 6.1.

Because HCS Sitemaps and declaration files are static XML resources, Registries SHOULD serve them using standard HTTP caching headers such as ETag, Last-Modified, and Cache-Control. AI Systems SHOULD use those headers, including conditional requests, to avoid refetching unchanged HCS Sitemaps and documents.

HTTP caching metadata MAY be used to reduce unnecessary retrievals, but HTTP caching directives MUST NOT extend the effective HCS revalidation period defined by Section 3.1.8. If the effective max-age period has elapsed, an AI System MUST complete the revalidation required by Section 3.1.8 before relying on the declaration.

HCS requires the RSL 1.0 legal-element model for each HCS <license> element. Each HCS <license> element MUST include exactly one <legal type="attestation"> element and exactly one <legal type="contact"> element.

If any <license> within a <hcs:right> fails an applicable requirement of this section, the enclosing <hcs:right> declaration is not operative.

Example: Required Legal Elements

<license>
  <prohibits type="usage">hcs:ai-generate hcs:ai-train</prohibits>

  <legal type="attestation">true</legal>
  <legal type="contact">https://agency.example/contact</legal>
</license>

This Draft includes the proposed HCS 1.0 conformance model for review. The conformance requirements and operational dependencies will be finalized before publication of the final HCS 1.0 specification.

• HCS processors MUST disable external entity resolution and MUST NOT fetch external DTDs or external entities when processing HCS documents, discovery documents, or Sitemap resources. Processors MUST reject any such resource containing a DOCTYPE declaration.

• HCS processors SHOULD apply implementation-defined resource limits to XML parsing, JWS processing, and certificate validation.

• AI Systems retrieving HCS resources over HTTPS MUST validate the server certificate and hostname according to current HTTPS/TLS best practices.

Upon final publication, this specification requests registration of the following entries in the IANA “Well-Known URIs” registry defined by [RFC 8615].

• [RSL 1.0] RSL Technical Steering Committee, "Really Simple Licensing (RSL) 1.0 Specification", 10 December 2025.

• [RFC 2119] S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

• [RFC 3339] G. Klyne and C. Newman, “Date and Time on the Internet: Timestamps”, RFC 3339, July 2002.

• [RFC 3986] T. Berners-Lee, R. Fielding, and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, RFC 3986, January 2005.

• [RFC 5280] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 5280, May 2008.

• [RFC 6068] M. Duerst, L. Masinter, and J. Zawinski, “The 'mailto' URI Scheme”, RFC 6068, October 2010.

• [RFC 7515] M. Jones, J. Bradley, and N. Sakimura, “JSON Web Signature (JWS)”, RFC 7515, May 2015.

• [RFC 7518] M. Jones, “JSON Web Algorithms (JWA)”, RFC 7518, May 2015.

• [RFC 7797] M. Jones, “JSON Web Signature (JWS) Unencoded Payload Option”, RFC 7797, February 2016.

• [RFC 8174] B. Leiba, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, May 2017.

• [RFC 8615] M. Nottingham, “Well-Known Uniform Resource Identifiers (URIs)”, RFC 8615, May 2019, https://www.rfc-editor.org/rfc/rfc8615.

• [ISO 3166-1] ISO, "Codes for the representation of names of countries and their subdivisions — Part 1: Country code", ISO 3166-1:2020, 2020.

• [Sitemaps Protocol] sitemaps.org, "Sitemaps XML Format".

• [W3C XML 1.0] W3C, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", November 2008.

• [XML Namespaces] W3C, "Namespaces in XML 1.0 (Third Edition)", December 2009.

• [XML Schema Datatypes] W3C, "XML Schema Part 2: Datatypes Second Edition", 28 October 2004.

• [Schema.org] Schema.org, "Schema.org Vocabulary, Version 30.0", 19 March 2026. Latest version available at https://schema.org/.

• [JSON-LD 1.1] G. Kellogg, P.-A. Champin, and D. Longley, “JSON-LD 1.1: A JSON-based Serialization for Linked Data”, W3C Recommendation, 16 July 2020, https://www.w3.org/TR/json-ld11/.

• [HCS Schema Profile Registry] Human Consent Standard Governance Board, “HCS Schema Profile Registry 1.0 Draft Specification”, 2026.

• [Crockford Base32] D. Crockford, "Base 32", 4 March 2019.

• [RELAX NG Compact Syntax] OASIS, "RELAX NG Compact Syntax", 21 November 2002.

• [ISNI] ISO, "International Standard Name Identifier (ISO 27729)", 2024.

• [ISWC] ISO, "International Standard Musical Work Code (ISO 15707)", 2022.

• [ISRC] ISO, "International Standard Recording Code (ISO 3901)", 2019.

• [Crockford Base32 IETF] D. Crockford and K. R. Davis, "Base32 for Humans", Internet-Draft, 10 April 2026, work in progress.

The Human Consent Standard was developed by the Human Consent Standard Governance Board, with valuable input from the Artist, Industry, and Policy Governance Boards and participants across the entertainment, publishing, technology, legal, and policy communities.

The editors gratefully acknowledge the advocacy, support, and contributions of Javier Bardem, George Clooney, Viola Davis, Tom Hanks, Dame Helen Mirren, Kristen Stewart, Meryl Streep, Dame Emma Thompson, Creative Artists Agency, and the Music Artists Coalition.

The editors also thank David Hornik, Dominique Shelton Leipzig, and Steven Soderbergh for their significant contributions and advice in shaping the standard.

This work reflects a shared commitment to protecting creative rights, supporting fair compensation, and enabling responsible AI innovation.

This Relax NG Compact schema defines a structural profile validator for HCS documents. It is intended to be used with the RSL 1.0 Relax NG schema to validate selected structural requirements of the HCS profile.

The schema introduces the https://humanconsent.org/hcs namespace, requires one or more <hcs:right> elements, and constrains selected uses of base RSL elements within <hcs:right> declarations. A combined schema MUST include the base RSL schema and override its start and foreignElement patterns with the definitions in this profile.

A <license> within <hcs:right> remains subject to applicable RSL 1.0 license requirements, except where this profile imposes additional or more specific constraints. HCS permits RSL 1.0 license child elements within <hcs:right> declarations, subject to the HCS-specific constraints defined by this specification.

This schema validates the HCS 1.0 base profile only. It recognizes only the usage tokens defined by this specification.

The HCS base profile permits foreign elements where allowed by this schema, but HCS-defined elements do not permit foreign attributes. This prevents unknown extension attributes from silently changing or limiting the meaning of a Rights Declaration. Except within the opaque contents of a foreign extension element, elements and attributes in the HCS namespace are permitted only where expressly defined by this profile.

This schema validates selected structural requirements. Conformance also requires the processor-level and semantic checks defined by this specification.

Within this schema, repeated choice patterns allow different <permits>, <prohibits>, and <legal> types to appear in any order. Processors MUST enforce the applicable RSL 1.0 per-type cardinality rules and the HCS requirements in Section 6.4.

# HCS 1.0 Relax NG Compact Syntax Module (profile)
#
# This schema is intended to be used with the RSL 1.0 Relax NG schema
# to validate documents conforming to the HCS profile.
#
# The standalone HCS discovery document served at
# `/.well-known/hcs.xml` is outside the scope of this schema.

default namespace = "https://rslstandard.org/rsl"
namespace rsl = "https://rslstandard.org/rsl"
namespace hcs = "https://humanconsent.org/hcs"

# The following named patterns are defined by the base RSL schema
# and MUST be available when this profile schema is used:
#
#   content, schema, terms, payment, reporting,
#   legalWarranty, legalDisclaimer, legalProof,
#   permitsUser, permitsGeo,
#   prohibitsUser, prohibitsGeo
#
# This profile overrides the base foreignElement and start patterns
# and defines HCS-specific attribute, attestation, contact, usage,
# license, and Rights Declaration patterns.

namespace local = ""

# The root <rsl> element permits extension attributes only from
# namespaces other than the RSL and HCS namespaces. HCS-defined
# elements do not permit foreign attributes.

hcsRootForeignAttribute =
  attribute * - (rsl:* | hcs:* | local:*) { text }

# A foreign extension element may contain ordinary unqualified
# attributes and attributes from foreign namespaces. Its contents
# are treated as an opaque extension subtree and may use any namespace.

hcsForeignElementAttribute =
  attribute * - (rsl:* | hcs:*) { text }

hcsForeignElementContent =
  element * {
    (attribute * { text } | text | hcsForeignElementContent)*
  }

foreignElement =
  element * - (rsl:* | hcs:*) {
    (hcsForeignElementAttribute | text | hcsForeignElementContent)*
  }

# XSD pattern facets match the complete value.
# URI patterns enforce only the basic scheme constraints used by
# this profile. Full URI validity and comparison requirements are
# governed by the normative prose.

absoluteHttpsURI = xsd:anyURI { pattern = "https://.+" }
absoluteMailtoURI = xsd:anyURI { pattern = "mailto:.+" }
contactURI = absoluteHttpsURI | absoluteMailtoURI

# HCS subject-scope values are defined separately for each Rights Subject
# category. The subject and subject-scope attributes are constrained together
# so that only scope values defined for the selected subject are permitted.

hcsWorkScope =
    "literary"
  | "composition"
  | "recording"
  | "audio-visual"
  | "artwork"

hcsIdentityScope =
    "name"
  | "image"
  | "likeness"
  | "voice"
  | "movement"
  | "signature"

hcsCharacterScope =
    "name"
  | "visual"
  | "voice"
  | "persona"

hcsSubjectAttributes =
    (attribute subject { "work" },
     attribute subject-scope { list { hcsWorkScope+ } }?)
  | (attribute subject { "identity" },
     attribute subject-scope { list { hcsIdentityScope+ } }?)
  | (attribute subject { "character" },
     attribute subject-scope { list { hcsCharacterScope+ } }?)
  | attribute subject { "mark" }

# HCS territory values use ISO 3166-1 alpha-2 country codes.
# This schema validates the two-letter lexical form; whether a value is an
# assigned ISO 3166-1 alpha-2 code is a processor-level requirement.

hcsTerritoryToken =
  xsd:token { pattern = "[A-Z]{2}" }

hcsTerritoryList =
  list { hcsTerritoryToken+ }

# HCRN lexical form: HCRN-XXXX-XXXX-C, where XXXX-XXXX is an
# eight-character Crockford Base32 payload and C is a check symbol.
# The schema does not validate the computed check symbol.
#
# Crockford Base32 excludes I, L, O, and U from payload symbols.
# The check symbol uses the payload alphabet plus the five
# Crockford check-only symbols: *, ~, $, =, and U.

hcrnValue =
  xsd:token {
    pattern = "HCRN-[0-9A-HJKMNP-TV-Z]{4}-[0-9A-HJKMNP-TV-Z]{4}-([0-9A-HJKMNP-TV-Z]|[*~$=U])"
  }

hcrnValueList =
  list { hcrnValue+ }

# HCSI lexical form: HCSI-XXXX-XXXX-C. The payload and check-symbol
# rules are the same as for HCRN values.

hcsiValue =
  xsd:token {
    pattern = "HCSI-[0-9A-HJKMNP-TV-Z]{4}-[0-9A-HJKMNP-TV-Z]{4}-([0-9A-HJKMNP-TV-Z]|[*~$=U])"
  }

specificSubjectAttributes =
  attribute subject-id { hcsiValue }

defaultSubjectAttributes =
  attribute subject-class { absoluteHttpsURI }

# Timestamp values are defined in Section 2.1.
# Full Timestamp conformance remains a processor-level requirement.

timestampValue =
  xsd:dateTime {
    pattern = ".*(Z|[+-][0-9]{2}:[0-9]{2})"
  }

hcsRightStatus =
    "active"
  | "withdrawn"
  | "superseded"

hcsStatusAttributes =
    (attribute status { "superseded" },
     attribute superseded-by { hcrnValueList })
  | (attribute status { "active" | "withdrawn" }?,
     attribute superseded-by { hcrnValueList }?)

hcsAIGenerateToken = "hcs:ai-generate"
hcsAITrainToken = "hcs:ai-train"

# This HCS 1.0 base-profile schema validates only the usage tokens
# defined by this specification.

hcsUsageToken =
    hcsAIGenerateToken
  | hcsAITrainToken

hcsUsageList =
  list { hcsUsageToken+ }

hcsSchema =
  element schema {
    attribute type { "application/ld+json" },
    xsd:string { minLength = "1" }
  }

# JWS syntax, header, payload, signature, algorithm, and certificate
# validation are processor-level requirements.

jwsValue =
  xsd:token { minLength = "1" }

certificationRoleValue =
  xsd:token { pattern = "[a-z]+(-[a-z]+)*" }

hcsCertification =
  element hcs:certification {
    attribute name {
      xsd:token { minLength = "1" }
    },
    attribute contact {
      contactURI
    },
    attribute role {
      certificationRoleValue
    }?,
    attribute time {
      timestampValue
    },
    attribute jws {
      jwsValue
    },
    empty
  }

# Component-reference schemas are informational and may use any
# RSL <schema> form permitted by the base RSL schema.

hcsIncludes =
  element hcs:includes {
    attribute registration-id { hcrnValue },
    schema?
  }

hcsIncluded =
  element hcs:included {
    attribute registration-id { hcrnValue },
    schema?
  }

hcsPermitsUsage =
  element permits {
    attribute type { "usage" },
    hcsUsageList
  }

hcsProhibitsUsage =
  element prohibits {
    attribute type { "usage" },
    hcsUsageList
  }

hcsPermitsElement =
    hcsPermitsUsage
  | permitsUser
  | permitsGeo

hcsProhibitsElement =
    hcsProhibitsUsage
  | prohibitsUser
  | prohibitsGeo

hcsLegalAttestation =
  element legal {
    attribute type { "attestation" },
    xsd:token { pattern = "true" }
  }

hcsLegalContact =
  element legal {
    attribute type { "contact" },
    contactURI
  }

# Repeated choice patterns allow different <permits>, <prohibits>,
# and <legal> types to appear in any order. Processors MUST enforce
# the applicable per-type cardinality rules.

hcsLegalElement =
    hcsLegalAttestation
  | hcsLegalContact
  | legalWarranty
  | legalDisclaimer
  | legalProof

hcsLicense =
  element license {
    (
      (hcsPermitsElement | hcsProhibitsElement)* &
      payment? &
      reporting* &
      hcsLegalElement+ &
      foreignElement*
    )
  }

# This schema validates selected structural requirements.
# Conformance also requires the processor-level and semantic checks
# defined by this specification.

hcsRight =
  element hcs:right {
    attribute registry {
      absoluteHttpsURI
    },
    attribute registration-id {
      hcrnValue
    },
    attribute issued {
      timestampValue
    },

    hcsSubjectAttributes,

    attribute territory {
      hcsTerritoryList
    }?,

    (
      specificSubjectAttributes
      |
      defaultSubjectAttributes
    ),

    hcsStatusAttributes,

    attribute supersedes {
      hcrnValueList
    }?,

    attribute valid-from {
      timestampValue
    }?,
    attribute valid-until {
      timestampValue
    }?,
    attribute max-age {
      xsd:positiveInteger
    }?,
    attribute server {
      absoluteHttpsURI
    }?,

    (
      hcsCertification? &
      hcsSchema &
      terms? &
      (hcsIncludes+ | hcsIncluded)? &
      hcsLicense+ &
      foreignElement*
    )
  }

# HCS declaration document

hcsDocument =
  element rsl {
    attribute max-age {
      xsd:positiveInteger
    }?,
    hcsRootForeignAttribute*,
    (
      content* &
      hcsRight+ &
      foreignElement*
    )
  }

start =
    hcsDocument