RSL Media Human Consent Standard 1.0 Draft Specification

By making AI-related creative rights machine-readable and interoperable at web scale, RSL-MEDIA 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 RSL Media Standard Governance Board as a Draft for review and comment. It reflects contributions and reviews from the RSL Media Artist Governance Board, the RSL Media Industry Governance Board, and the RSL Media 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.

The following forward-looking provisions are included in draft normative form to show the intended final RSL-MEDIA 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 RSL-MEDIA 1.0 specification:

• The designated ISRD Registration Authority, including ISRD assignment, governance, official declaration URLs, lookup mechanisms, declaration provenance chain records, and trust-policy mechanisms for recognizing authoritative Hosts and certifying entities.
• Initial Schema.org-based <schema> profiles for Rights Subject categories, including works, identities, characters, marks, and Default Declarations. These profiles will be formalized before publication of the final RSL-MEDIA 1.0 specification, with input from relevant stakeholders.
• The OLP-MEDIA protocol and server attribute.
• Cross-registry Rights Subject equivalence signals, including standardized identifiers, trusted equivalence authorities, and profile-specific matching rules.
• Embedded certified declarations in digital assets, including format-specific embedding mechanisms, extraction rules, processing rules, and revalidation requirements.

Creative rights associated with expressive Works, Identities, and protected Marks are administered through a complex ecosystem of organizations, including guilds, collective management organizations, studios, agencies, estates, publishers, and brand owners. While these 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 RSL Media Human Consent Standard (RSL-MEDIA) 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, likeness, voice, image, 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: trademarks, service marks, logos, trade dress, and signature product designs, including marks used in fashion, jewelry, luxury goods, consumer products, and related industries.

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

• Registry-Scoped Identification: Unambiguous identification of Rights Subjects using stable, Registry-assigned identifiers or scope definitions, 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.

• Third-Party Certification: Cryptographically verifiable certification by trusted entities, such as law firms, guilds, or studios, indicating that a Rights Subject 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 RSL-MEDIA Open License Protocol (OLP-MEDIA). OLP-MEDIA is based on the Open License Protocol defined by RSL 1.0 and will be specified in the final RSL-MEDIA 1.0 specification.

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

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

The absence of an RSL-MEDIA Rights Subject declaration 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.

RSL-MEDIA 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 nonexistence of an RSL-MEDIA declaration.

RSL-MEDIA Rights Subject license declarations are not permanent grants or transfers of rights. They are revocable declarations of machine-readable 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 the licensing terms expressed by a Rights Subject declaration. AI Systems MUST confirm that any such declaration remains current and in force, and MUST NOT rely on permissions that are no longer in effect.

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

RSL-MEDIA is a public, machine-readable layer for the established rights-administration ecosystem of the creative industries. It standardizes how trusted Hosts and certifying entities described in Section 5 publish AI usage restrictions, licensing terms, and Clearance paths for Rights Subjects.

RSL-MEDIA can expose inconsistent or overlapping rights declarations, but it does not adjudicate ownership, authority, or legal permission. Matching identifiers, similar <schema> metadata, or related Registry records may help identify related declarations, but rights disputes are resolved through the applicable Registry rules, representative workflows, contracts, legal review, and dispute-resolution procedures.

When an AI System identifies a conflict, it MUST apply the conflict rules in Section 3.1.8. Until the conflict is resolved, the affected Rights Scope is unresolved and the AI System MUST NOT rely on any conflicting declaration for that scope.

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

Example: Prohibit Performer Identity AI Use

This example shows an RSL-MEDIA document that prohibits AI Systems from training on or generating digital representations of a performer, including the performer’s name, likeness, voice, image, video, 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:media="https://rslmedia.org/media">

  <media:right
    isrd="RSL-0000-0000-0"
    issued="2026-01-01T00:00:00Z"

    registry="https://agency.example"
    registry-id="123456"
    subject="identity">

    <schema type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@type": "Person",
        "name": "Example Actor",
        "jobTitle": "Actor",
        "url": "https://imdb.example/name/example-actor.html"
      }
    </schema>

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

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

  </media:right>
</rsl>

Example: Creative Work AI License Declaration

This example shows an RSL-MEDIA 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:media="https://rslmedia.org/media">

  <media:right
    isrd="RSL-0000-0001-1"
    issued="2026-01-01T00:00:00Z"

    registry="https://registry.example"
    registry-id="WORK-123456"
    subject="work"
    scope="composition">

    <schema type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@type": "MusicComposition",
        "name": "Example Song",
        "identifier": {
          "@type": "PropertyValue",
          "propertyID": "ExampleRegistry",
          "value": "WORK-123456"
        },
        "creator": {
          "@type": "Person",
          "name": "Jane Doe"
        }
      }
    </schema>

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

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

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

  </media: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 RSL-MEDIA extension module is:

https://rslmedia.org/media

All RSL-MEDIA documents MUST declare the RSL-MEDIA namespace on the root <rsl> element and SHOULD use the media prefix. RSL-MEDIA elements in that namespace MUST be interpreted using XML namespace processing as defined by [XML Namespaces]. XML namespace processing applies to RSL-MEDIA elements and attributes, not to literal token strings defined by this specification.

<rsl xmlns="https://rslstandard.org/rsl"
     xmlns:media="https://rslmedia.org/media">
  ...
</rsl>

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

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

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

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

RSL-MEDIA 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 RSL-MEDIA document MUST contain one or more <media:right> elements as direct children of the RSL <rsl> root element. Each <media:right> element identifies a Rights Subject or Default Declaration scope 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 <media:right> declarations as defined in Section 3.1.7.

The <media:right> element is analogous to an RSL <content> element, but identifies a Rights Subject rather than a canonical digital asset URL. RSL core elements used within <media:right>, including <license> and <payment> elements, retain their RSL 1.0 meanings except where this specification defines Rights Subject-specific rules.

If a <media:right> declaration contains more than one <license> element, the applicable license terms are evaluated together under the RSL 1.0 license evaluation and conflict-resolution rules. For RSL-MEDIA usage tokens, an effective prohibition takes precedence over an effective permission for the same Rights Subject, Rights Scope, and use.

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

An AI System MUST NOT rely on any RSL-MEDIA declaration that fails an applicable requirement of this specification.

The <media:right> element is the RSL-MEDIA licensing element for a Rights Subject. It identifies a Rights Subject or Default Declaration scope, describes it using structured metadata, and associates it with one or more RSL <license> elements.

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

• exactly one RSL <schema> element
• one or more RSL <license> elements
• no more than one <media:certification> element

In the RSL-MEDIA profile, the <schema> element MUST use the inline RSL 1.0 form with type="application/ld+json" and MUST contain JSON-LD conforming to [JSON-LD 1.1]. The JSON-LD MUST describe the Rights Subject or, for Default Declarations, the covered Registry subjects using Schema.org terms.

The <schema> element supports indexing, display, audit, and applicable Rights Subject profile validation. The operative Rights Subject and Rights Scope are determined by the registry, registry-id, subject, and scope attributes. The <schema> element does not, by itself, establish authority, Default Declaration membership, cross-registry equivalence, or permission.

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

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

The order of <license>, <schema>, <media:certification>, and extension child elements is not significant.

Each <media:right> element MUST identify the applicable Rights Subject or Default Declaration scope using the subject, registry, and registry-id attributes. The scope attribute MAY limit the declaration to specific Rights Scope values for the Rights Subject category.

AI Systems evaluate <media:right> declarations under the lifecycle, revalidation, conflict, and trusted-source rules defined in Sections 3.1.6, 3.1.7, 3.1.8, and 5.

The isrd attribute identifies a Rights Subject declaration using an International Standard Rights Declaration (ISRD) identifier assigned by the designated ISRD Registration Authority.

An ISRD is a stable identifier for citation, lookup, revalidation, certification, provenance, audit, and dispute-resolution workflows. The same ISRD SHOULD be retained for updates to the same Rights Subject declaration.

The ISRD Registration Authority maintains lookup records that associate each ISRD with its official declaration URL. This allows an ISRD to serve as a stable citation and discovery reference even if the declaration’s publication location changes over time.

The isrd attribute MUST contain a syntactically valid ISRD identifier as defined in Section 3.1.1.1.

Within a single RSL-MEDIA document, an ISRD MUST NOT appear on more than one <media:right> element. If it does, each occurrence of that ISRD in that document MUST be treated as invalid.

An ISRD identifier has the following format:

RSL-XXXX-XXXX-C

• RSL- is the fixed literal prefix.
• XXXX-XXXX is an 8-character canonical [Crockford Base32] payload, providing more than 1 trillion possible identifiers.
• C is the Crockford check symbol computed from the numeric value represented by the 8-character payload under the Crockford Base32 check-symbol rules. It MUST be one of the payload symbols or one of the check-only symbols *, ~, $, =, or U.

In RSL-MEDIA documents, ISRD identifiers MUST be expressed in canonical uppercase form with hyphens. No case folding or ambiguous-character decoding is performed when validating an ISRD in an RSL-MEDIA document. An ISRD identifier is valid only if the check symbol matches the value computed over the canonical 8-character payload under the Crockford Base32 check-symbol rules.

Two ISRD identifiers are equal if their canonical forms are identical.

ISRD payloads with numeric values from 0000-0000 through 0000-00ZZ, inclusive, are reserved for examples, documentation, testing, and non-production use.

Example: Machine-Readable ISRD Identifier

<media:right
  isrd="RSL-0000-0002-2"
  issued="2026-01-01T00:00:00Z"

  registry="https://registry.example"
  registry-id="WORK-123456"  
  subject="work"
  scope="composition">
  ...
</media:right>

The designated ISRD Registration Authority’s lookup record identifies the official declaration URL for an ISRD. An AI System MAY use that record to locate or confirm the declaration associated with an ISRD.

An AI System MUST NOT treat a declaration bearing an ISRD as the current official declaration for that ISRD unless it is retrieved from the official declaration URL identified by the ISRD Registration Authority.

If an AI System discovers a declaration bearing the same ISRD at another location, that copy MAY be used for discovery, caching, audit, or certification verification, but MUST be reconciled against the official declaration URL before the AI System relies on it as current.

The designated ISRD Registration Authority MAY provide audit records for AI Systems that rely on RSL-MEDIA declarations. An AI System MAY use an ISRD audit service to support compliance, verification, citation, or dispute-resolution workflows.

Hosts MUST retain historical records sufficient to identify the terms published for an ISRD at a given time and to support ISRD audit records and reliance disputes.

The Registration Authority defines the ISRD audit format, receipt format, verification protocol, and any metadata required for an ISRD audit check.

When displayed outside an RSL-MEDIA document, ISRD identifiers SHOULD be rendered in uppercase with hyphens as shown above. The RSL- prefix distinguishes ISRD identifiers from ISWCs, ISRCs, and other industry codes.

Example: Human-Readable ISRD Identifier

(C) 2026 Example Inc., ISRD RSL-0000-0002-2

The issued attribute MUST contain a Timestamp identifying when the declaration identified by the isrd attribute was first issued by the declaration publisher.

The issued value is stable for that ISRD. If the declaration is updated under the same ISRD, the issued value remains unchanged. A declaration assigned a different ISRD has its own issued value.

The issued value identifies the declaration publisher’s original issuance time for the ISRD. It does not identify the time of ISRD assignment, certification, later updates, or subsequent publication or distribution events.

The registry and registry-id attributes identify the Registry namespace and Registry-assigned identifier for the Rights Subject governed by a <media:right> declaration. Together with the subject attribute and any scope values, they identify the declared Rights Subject or Default Declaration scope.

The registry attribute identifies the Registry namespace for the Rights Subject and MUST be interpreted as follows:

• Registries MUST publish registry values in a stable canonical form as absolute HTTPS URLs.
• For comparison, AI Systems MUST apply Syntax-Based Normalization as defined in RFC 3986 Section 6.2.2.
• Registries using internationalized domain names MUST publish registry values in IDNA A-label form as defined by [RFC 5891].
• After the required normalization, registry values are compared exactly. No other URL normalization is required unless the AI System has an independently trusted basis for applying Registry-defined normalization or comparison rules.

The registry-id attribute identifies the Rights Subject within the Registry namespace and MUST be interpreted as follows:

• The value is Registry-defined and after XML attribute normalization, the value MUST NOT be empty and MUST NOT contain XML whitespace.
• Registries MUST publish registry-id values in a stable canonical form.
• Unless the AI System has an independently trusted basis for applying Registry-defined normalization or comparison rules, registry-id values MUST be compared as exact, case-sensitive strings after XML attribute-value normalization.
• The value * is reserved for Default Declarations, and other registry-id values MUST NOT contain the * character.

The registry-subjects attribute identifies a Host-defined subject discovery or verification resource for a Default Declaration and MUST be interpreted as follows:

• The attribute MAY appear only when registry-id="*", and MUST be an absolute HTTPS URL.
• The semantics, format, access requirements, update semantics, and verification procedure for a registry-subjects resource are defined by the Host.

The subject and scope attributes classify the Rights Subject identified by the registry and registry-id attributes and, where applicable, limit the declaration to particular rights components or protected aspects of that subject.

The scope attribute reflects how media rights are commonly administered and licensed. Different rights components or protected aspects of the same Rights Subject may be controlled, licensed, or restricted separately. For example, a musical work may have separate composition and recording rights, and an identity may have separate likeness, voice, image, and video rights.

RSL-MEDIA 1.0 defines four standardized subject values. The subject value classifies the Rights Subject identified by the registry and registry-id attributes and determines which category-specific rules apply to the declaration. It also determines the 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.

RSL-MEDIA 1.0 defines standardized scope values for the work, identity, and character Rights Subject categories. A scope value identifies a rights component, protected aspect, or category-specific subject matter within the Rights Subject; it does not identify a separate Rights Subject. RSL-MEDIA 1.0 does not define standardized scope values for mark.

The scope value is a whitespace-separated list of tokens. Order has no significance, and duplicate values MUST be ignored. Each 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.

If the scope attribute is absent, the declaration applies to the Rights Subject without restriction to any particular Rights Scope, including recognized, unrecognized, and future scope values for the applicable Rights Subject category.

Each scope value is interpreted only within the subject category of the enclosing <media:right> element. AI Systems implementing RSL-MEDIA MUST interpret recognized scope values according to the semantics defined for the applicable category and MUST NOT infer permission from an unknown scope value.

For conflict analysis, a declaration with no scope attribute overlaps any declaration for the same Rights Subject. Unrecognized scope values overlap only when the values are identical.

Registries, industry groups, studios, guilds, publishers, and other sector participants MAY define additional scope values. Such values SHOULD be stable and clearly defined, and SHOULD NOT redefine or conflict with values defined by this specification.

A <media: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 license 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

Rights Holders or Representatives MUST include a <schema> element describing the Rights Subject (e.g., schema:CreativeWork, schema:MusicComposition, or schema:Movie).

Standardized scope Values

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

Example: Creative Work License Declaration

<media:right
  isrd="RSL-0000-0004-4"
  issued="2026-01-01T00:00:00Z"

  registry="https://registry.example"
  registry-id="T-123.456.789-0"
  subject="work"
  scope="composition">

  <schema type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "MusicComposition",
      "name": "Example Song",
      "iswcCode": "T-123.456.789-0",
      "creator": {
        "@type": "Person",
        "name": "Jane Doe"
      }
    }
  </schema>

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

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

</media:right>

A <media:right subject="identity"> element represents licensing terms governing AI-based representations of an identifiable persona. It authorizes or prohibits an AI System from training on, depicting, or generating representations of an identifiable person within the bounds of the license 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, RSL-MEDIA 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.

Rights Holders or Representatives MUST include a <schema> element describing the person (e.g., schema:Person).

Standardized scope Values

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

Example: Performer Identity License Declaration

<media:right
  isrd="RSL-0000-0005-5"
  issued="2026-01-01T00:00:00Z"

  registry="https://agency.example"
  registry-id="123456"
  subject="identity">

  <schema type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "Person",
      "name": "Example Actor"
    }
  </schema>

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

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

</media:right>

A <media: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 license declaration. Covered uses MAY include:

• Visual depictions of the character (illustration, animation, photorealistic rendering)
• Voice, dialogue, or performance in the character’s persona
• In-universe scenes, stories, or derivative works featuring the character
• Synthetic portrayals that closely imitate a specific on-screen portrayal or performance associated with the character

Rights Holders or Representatives MUST include a <schema> element describing the character (e.g., schema:Person for character-like personas, or schema:CreativeWork when a character is represented as a cataloged IP asset), and SHOULD include stable references such as sameAs, identifier, and franchise or publisher URLs.

Standardized scope Values

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

Example: Character License Declaration

<media:right
  isrd="RSL-0000-0006-6"
  issued="2026-01-01T00:00:00Z"

  registry="https://studio.example"
  registry-id="CHAR-2025-000123"
  subject="character">

  <schema type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "CreativeWork",
      "name": "Example Character"
    }
  </schema>

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

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

</media:right>

A <media:right subject="mark"> element represents licensing terms governing AI-based use of a protected mark, including trademarks, service marks, logos, asserted trade dress, product designs asserted to function as trade dress, and other distinctive source-identifying symbols. This includes marks used in fashion, jewelry, luxury goods, consumer products, and related industries.

A mark license declaration authorizes or prohibits an AI System from training on, depicting, generating, adapting, or emulating mark-associated identifiers, asserted trade dress, or other distinctive source-identifying features within the bounds of the license declaration. Covered uses MAY include:

• Model-development uses involving mark-associated materials
• Depictions of branded products, logos, marks, or trade dress (e.g., handbags, jewelry, apparel, packaging)
• Emulation of asserted trade dress or other mark-associated source-identifying elements for generative or synthetic purposes
• Synthetic product imagery, virtual try-on assets, or marketing content featuring protected marks
• Brand-referential outputs that could reasonably imply source, sponsorship, endorsement, affiliation, or commercial association

Rights Holders or Representatives MUST include a <schema> element describing the mark (e.g., schema:Brand or schema:Product) and SHOULD include stable references such as logo, sameAs, trademark registration identifiers, and official brand or product URLs.

Use of scope with Marks

RSL-MEDIA 1.0 does not define standardized scope values for <media:right subject="mark">. If used with subject="mark", scope values are implementation-defined Rights Scope tokens unless recognized by an applicable profile, Registry, or ecosystem rule. AI Systems MUST NOT infer standardized mark-scope semantics from unrecognized values. For interoperability, publishers SHOULD omit the scope attribute for <media:right subject="mark"> unless an applicable profile or Registry defines the used values and their conflict-detection semantics.

Example: Mark Rights License Declaration

<media:right
  isrd="RSL-0000-0007-7"
  issued="2026-01-01T00:00:00Z"

  registry="https://brand.example/registry"
  registry-id="EXAMPLE-MAISON"
  subject="mark">

  <schema type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "Brand",
      "name": "Example Maison"
    }
  </schema>

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

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

</media:right>

The registry-id attribute normally identifies a single Rights Subject. When registry-id="*", the <media:right> element expresses a Default Declaration for Rights Subjects represented by the identified Registry.

Default Declarations allow Registries and other authoritative bodies that administer a defined set of Rights Subjects to publish baseline AI rights policy without requiring an individual declaration for every covered subject.

The scope of a Default Declaration is defined by the registry, registry-id, subject, and any limiting scope values identified by the scope attribute. In a Default Declaration, the <schema> element provides machine-readable metadata describing the covered Registry subjects rather than a single identified Rights Subject.

An AI System MUST apply a Default Declaration only where it has an independent, trusted basis to determine that the Rights Subject is represented by the Registry for purposes of the Default Declaration, such as the resource identified by registry-subjects, authoritative Registry records, or other trusted Registry subject data. If an AI System lacks that basis, the Default Declaration does not apply. The <schema> element describes the covered Registry subjects but is not sufficient, by itself, to establish Registry subject membership.

A declaration that identifies a specific Registry-assigned Rights Subject is more specific than an otherwise applicable Default Declaration. Conflicts involving Default Declarations are governed by Section 3.1.8.1.

The use of registry-id="*" does not expand the trust scope of the publishing Host or certifying entity. Authority, trust scope, and dispute handling are governed by Section 5.

Example: Guild or industry organization default identity restriction

This example shows an RSL-MEDIA 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, likeness, voice, image, or video. The registry-subjects URL points to a Registry resource that identifies or verifies the people represented by the guild.

<rsl xmlns="https://rslstandard.org/rsl"
     xmlns:media="https://rslmedia.org/media">

  <media:right
    isrd="RSL-0000-0008-8"
    issued="2026-01-01T00:00:00Z"

    registry="https://guild.example"
    registry-id="*"
    registry-subjects="https://guild.example/rsl-media/members"
    subject="identity">

    <schema type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@type": "Organization",
        "name": "Example Guild",
        "url": "https://guild.example",
        "description": "Registry-wide default declaration for actors represented by Example Guild."
      }
    </schema>

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

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

  </media:right>
</rsl>

A Rights Subject 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 <media: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.7.

The max-age attribute defines revalidation requirements for the declaration and the Association Mechanism by which it was located or trusted; 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 is current, subject to its validity period, trusted-source evaluation, and conflict handling.

• If status="withdrawn", the declaration has been withdrawn. An AI System MUST NOT rely on a withdrawn declaration for new activities.

• If status="superseded", the declaration has been superseded. An AI System MUST NOT rely on a superseded declaration for new activities.

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 is in force no earlier than its issued time. If valid-until is absent, the declaration has no declared end time. If both attributes are present, valid-until MUST be later than valid-from; 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 valid-from 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-ISRD update, valid-from identifies the earliest time at which the current published terms are in force.

The valid-from value MUST NOT precede the declaration’s issued value. If a same-ISRD update changes the licensing consequence for any covered use, the updated declaration MUST include a valid-from value identifying the earliest time at which the changed terms are in force. That valid-from value MUST NOT precede the time at which those changed terms were first made available at the declaration’s official publication location.

If an AI System first observes changed same-ISRD terms after their stated valid-from time, has satisfied the revalidation requirements in Section 3.1.7, and lacks a trusted basis to determine that the changed terms were made available at the official publication location no later than the stated valid-from time, it MUST treat the changed terms, for purposes of RSL-MEDIA evaluation, as effective no earlier than its first observation time. This rule applies whether the changed terms grant, expand, withdraw, narrow, or prohibit permission.

The supersedes and superseded-by attributes define a declaration’s provenance chain. The provenance chain links related declarations to support discovery, citation, and audit workflows.

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

An AI System MAY use the provenance chain to locate related declarations, cite related ISRDs, maintain audit records, or present declaration history. Each declaration is evaluated independently under the lifecycle, validity, trust, 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 <media:right> declaration before revalidating the declaration and the Association Mechanism by which it was located, associated with a Rights Subject, or trusted. 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 <media: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 <media:right> declaration. If only the <media:right> element specifies max-age, that value applies to that declaration. If both specify max-age, the smaller value applies. Publishers that require faster propagation of updates, withdrawals, or licensing changes SHOULD specify a shorter max-age value.

After the effective revalidation period has elapsed, an AI System MUST NOT rely on the declaration for any new activity governed by an RSL-MEDIA usage token, Clearance path, or payment term unless it has revalidated the declaration and each relied-on Association Mechanism that is capable of changing. Failure to revalidate does not constitute permission under Section 1.2.

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 or any relied-on Association Mechanism has changed, the AI System MUST retrieve and re-evaluate the applicable declaration before relying on it. If the AI System no longer treats the Host, certification, subject-discovery or verification resource, or other trust basis as trusted under Section 5, it MUST NOT continue to rely on the declaration, regardless of the applicable max-age period.

Before determining whether a conflict exists, an AI System MUST exclude any <media:right> declaration that is not applicable, is not trusted under Section 5, is not current because of status, valid-from, or valid-until, or is not the current official declaration for its ISRD under Section 3.1.1.2.

A conflict exists when two or more remaining declarations assert authority to publish licensing terms for the same Rights Subject and overlapping declared scope, subject to the Default Declaration rules in Section 3.1.8.1. A conflict is an authority conflict, not a disagreement about substantive <license> terms. Because the conflicting declarations assert competing authority over the affected scope, an AI System MUST NOT choose among them based on their licensing terms. For purposes of this section, an unresolved scope is a scope for which an AI System MUST NOT treat any conflicting declaration as controlling.

The declared scope of a <media:right> declaration is determined by the subject, registry, registry-id, and scope attributes. If scope is absent, the declaration is treated as applying without restriction to any particular scope value for the applicable Rights Subject category. If registry-id="*", applicability is determined under the Default Declaration rules in Section 3.1.8.1.

Declarations using different registry or registry-id values conflict only where the AI System has a trusted basis to determine that they refer to the same Rights Subject and assert authority over overlapping declared scope. Until standardized cross-registry equivalence signals or applicable Rights Subject profile rules are defined, AI Systems are not required to detect equivalence across different registry or registry-id values. An AI System MUST NOT determine cross-registry equivalence based solely on matching names, titles, descriptive metadata, or approximate similarity in <schema> content.

When declarations overlap only for particular scope values, the conflict exists only for those values.

If an AI System identifies a conflict, it MUST, before relying on any portion of the affected declarations, retrieve or revalidate the current version of each conflicting declaration and re-evaluate the applicable trust basis.

Default Declarations do not assert exclusive authority over a specific Registry-assigned Rights Subject.

If two or more Default Declarations apply to the same Rights Subject, overlapping declared scope, and the same RSL-MEDIA usage token, the affected scope and usage token are unresolved.

If both a Default Declaration and a declaration for a specific Registry-assigned Rights Subject apply to the same Rights Subject, the specific declaration governs only the scope and RSL-MEDIA usage-token combinations it addresses. The Default Declaration continues to govern any remaining combinations within its scope.

A Default Declaration does not govern any scope or RSL-MEDIA usage token for which an applicable specific declaration is non-operative because of a conflict. That scope or usage token remains unresolved.

Except as provided in Section 3.1.8.1, overlapping declared scope for the same Rights Subject MUST be treated as in conflict. For example, if one declaration asserts scope="composition recording" and another asserts scope="recording artwork" for the same Rights Subject, the recording scope value is in conflict, while composition and artwork are not in conflict solely by reason of that overlap.

A conflict concerns the asserted authority to publish licensing terms for the overlapping scope value or values. It is not resolved by comparing the substantive <license> terms of the conflicting declarations.

When declarations conflict, the overlapping scope value or values are unresolved. Each conflicting declaration remains part of the declaration record, but an AI System MUST NOT rely on any conflicting declaration to determine permission, prohibition, Clearance, payment, royalty distribution, or any other licensing consequence for the unresolved scope value or values.

Non-conflicting portions of the declared scope MAY continue to be evaluated under this specification.

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

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

AI Systems MAY use this endpoint to obtain authorization, licensing terms, Clearance, or payment instructions for uses governed by the applicable <media:right> declaration and its <license> terms.

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

The optional <media:certification> element provides third-party certification for a <media: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.

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

RSL-MEDIA certifications use JSON Web Signatures (JWS) with an attached XML payload to verify declaration integrity and provide X.509 certificate material for signer identification and trust-policy evaluation under Section 5. The signed JWS payload, not the enclosing published XML copy, is the authoritative form of a certified declaration under the Trusted Certification model.

The <media:certification> element MUST be empty in RSL-MEDIA 1.0 and MUST contain the following attributes.

The jws attribute MUST contain a JWS Compact Serialization value with an attached payload that conforms to Section 3.2.4. A <media:certification> element that does not satisfy these requirements is invalid.

The JWS payload for a <media:certification> element is the UTF-8 byte serialization of a single well-formed <media:right> element selected by the signer. The signer determines the exact serialized form of that element, including attribute order, whitespace, namespace declarations, and character content.

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

After signing, the signer inserts the resulting JWS Compact Serialization value as the jws attribute value of the <media:certification> element in the published RSL-MEDIA document. The published <media:right> element carries the certification; for a valid certification, the signed JWS payload is the authoritative certified declaration.

This profile signs the serialized XML payload carried in the JWS and does not use XML canonicalization.

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

1. read the jws attribute value from the <media:certification> element in the published RSL-MEDIA document
2. validate the JWS Compact Serialization under Section 3.2.4
3. parse the JWS payload bytes as a well-formed standalone XML <media:right> element using XML namespace processing
4. verify that the parsed signed <media:right> element contains exactly one <media:certification> element and that its jws attribute value is the empty string
5. verify that the isrd attribute of the parsed signed <media:right> element equals the isrd attribute of the enclosing published <media:right> element
6. verify that each published <media:certification> attribute value other than jws matches the corresponding attribute value in the signed payload
7. verify that the parsed signed <media:right> element conforms to the RSL-MEDIA requirements for a <media:right> declaration, except that the signed payload’s <media:certification> element MUST contain jws=""
8. for evaluation under the Trusted Certification model, ignore the enclosing published <media:right> element except as the carrier of the jws attribute, and use only the parsed signed <media:right> payload as the certified declaration

Under the Trusted Certification model, only the parsed signed <media:right> payload is certified and evaluated. The enclosing published <media:right> element is only the carrier for the jws attribute.

If any step fails, the <media:certification> element is invalid and the declaration MUST NOT be treated as trusted under the Trusted Certification model in Section 5.2.

Successful verification establishes payload integrity, not signer authority, certificate trust, legal effect, or ISRD currentness. A verifier treats the certification as an attestation by a trusted certifying entity only after applying the certificate-usage and trust-policy requirements in Sections 3.2.3 and 5.2.

Before relying on a certified declaration as current, an AI System MUST apply the official-declaration rule in Section 3.1.1.2 to the signed JWS payload. The signed payload is current only if it is retrieved from the official declaration URL for the ISRD, or if an applicable ISRD Registration Authority record expressly authorizes reliance on that signed payload or class of certified copies. A differing official declaration means the signed payload is not current.

Example: Third-Party Certification Element

<media: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 <media:certification> signatures MUST validate the x5c certificate path using [RFC 5280] path validation, subject to the verifier’s trust policy, including any revocation requirements under that policy. A verifier MUST validate the certificate path at the time of verification unless its trust policy specifies an independently verifiable historical validation time, and MUST reject a certification if the signer’s certificate or certificate path is 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 verifier’s trust policy MUST also define the scope for which the certifying entity is trusted, including the applicable Registry, Rights Subject category, Rights Scope, and, for Default Declarations, the Rights Subjects the certifying entity is trusted to represent or certify.

The time attribute identifies the certification time asserted by the signer.

RSL-MEDIA 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.2.1. The payload MUST be base64url-encoded without padding as the second segment of the JWS Compact Serialization.

RSL-MEDIA 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 RSL-MEDIA 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/rsl+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 where cty is not application/rsl+xml.

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

RSL-MEDIA defines two RSL usage tokens for use in <permits type="usage"> and <prohibits type="usage"> elements within a <license> child of <media:right>:

• media:ai-generate
• media:ai-train

These tokens are literal, case-sensitive token strings. The media: prefix is part of the token value and is not resolved through XML namespace processing. Unqualified RSL 1.0 usage tokens are not aliases for RSL-MEDIA usage tokens.

In the RSL-MEDIA 1.0 base profile, <permits type="usage"> and <prohibits type="usage"> elements within a <media:right> declaration MUST contain only media:ai-generate and media:ai-train. Additional usage tokens are non-conforming unless defined by an applicable RSL-MEDIA extension profile. An RSL-MEDIA-aware processor MUST NOT treat an unrecognized usage token within a <media:right> declaration as granting permission for any RSL-MEDIA usage category.

The media:ai-generate and media:ai-train tokens are independent. A single AI activity may implicate both, 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 media:ai-generate usage token governs AI-based generation, reproduction, adaptation, or emulation of the Rights Subject identified by a <media:right> declaration. Within a <license>, it indicates whether those uses are permitted or prohibited, subject to the applicable licensing terms.

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

When evaluated in the context of a <media:right> declaration, media: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, any scope values specified on the <media:right> element, the applicable <license> terms, and any linked Clearance mechanism.

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

The media: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 <media:right> declaration. Within a <license>, it indicates whether those uses are permitted or prohibited, subject to the applicable licensing terms.

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

When evaluated in the context of a <media:right> element, media: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, any scope values specified on the <media:right> element, the applicable <license> terms, and any linked Clearance mechanism.

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

RSL 1.0 defines standard, web-native discovery mechanisms for license declarations associated with specific digital assets. RSL-MEDIA supports those mechanisms, but Rights Subject declarations are not tied to a single asset URL, and trusted Hosts may publish declarations for thousands or millions of Rights Subjects.

To support discovery and synchronization at that scale, RSL-MEDIA defines an additional Bulk Publication model based on the Sitemaps Protocol. This model allows AI Systems to locate declarations, enumerate them for synchronization, and detect changes without refetching unchanged declarations.

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

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

• each <url><loc> entry in an RSL-MEDIA Sitemap MUST use https and point to an RSL-MEDIA document served as application/rsl+xml
• each <sitemap><loc> entry in an RSL-MEDIA Sitemap index MUST use https and point to an XML Sitemap that directly enumerates RSL-MEDIA 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

Removal of an RSL-MEDIA 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 <media:right> declaration. Withdrawal or supersession MUST be expressed through the lifecycle attributes defined in Section 3.1.6.

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

Hosts 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: RSL-MEDIA Sitemap (rsl-media.xml)

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

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

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

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

</urlset>

Hosts MAY make RSL-MEDIA Sitemap resources discoverable through one or more of the mechanisms defined in this section. AI Systems SHOULD support all mechanisms defined in this section.

RSL-MEDIA Sitemap resources MUST comply with the Sitemaps Protocol, including the rule that a Sitemap may include only URLs within the URL scope permitted by the Sitemap’s own location. Hosts SHOULD use a root-level Sitemap or Sitemap index when the resource is intended to enumerate RSL-MEDIA documents across the Host.

Whether an RSL-MEDIA declaration originates from a trusted source is determined by the publication location of the RSL-MEDIA document, not by the Sitemap, robots.txt, or other mechanism by which the document was discovered.

Hosts SHOULD make an RSL-MEDIA Sitemap resource available at one of the following root-level default locations:

https://<host>/rsl-media.xml
https://<host>/rsl-media.xml.gz

Hosts MAY advertise an RSL-MEDIA Sitemap resource using the Sitemap: directive defined by the Sitemaps Protocol in the robots.txt file at the root of the Host’s domain. To be identifiable as an RSL-MEDIA Sitemap resource by URL inspection, the Sitemap URL SHOULD end with /rsl-media.xml or /rsl-media.xml.gz.

Sitemap: https://registry.example/rsl-media.xml

AI Systems SHOULD treat matching Sitemap: directives as RSL-MEDIA Sitemap resources. AI Systems MAY retrieve and inspect other Sitemap resources.

AI Systems discovering RSL-MEDIA Sitemaps SHOULD check the following mechanisms:

1. the root-level default locations /rsl-media.xml and /rsl-media.xml.gz
2. robots.txt Sitemap: directives that identify RSL-MEDIA Sitemap resources

If more than one RSL-MEDIA Sitemap resource is discovered, the AI System MAY retrieve and evaluate all discovered resources. Duplicate RSL-MEDIA file URLs SHOULD be treated as references to the same resource.

Because RSL-MEDIA bulk 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 RSL-MEDIA Sitemaps and documents.

HTTP caching metadata MAY be used to reduce unnecessary retrievals, but HTTP caching directives MUST NOT extend the effective RSL-MEDIA revalidation period defined by Section 3.1.7. If the effective max-age period has elapsed, an AI System MUST revalidate the RSL-MEDIA document and the Association Mechanism on which it relied before relying on the declaration.

RSL-MEDIA declarations apply to Rights Subjects that may appear across many sites, files, and forms of media. Because declarations are expressed independently of any particular asset location, AI Systems MUST determine whether a declaration originates from a trusted source before relying on it.

A trusted source establishes the reliability of the RSL-MEDIA licensing information and any referenced Clearance pathway. It does not, by itself, grant legal permission to use a Rights Subject or imply that all rights required for a particular use have been cleared.

An RSL-MEDIA declaration originates from a trusted source when either of the following conditions is met:

• Trusted Host: The RSL-MEDIA document is published and served by a Host that the AI System trusts to publish licensing declarations for the referenced Rights Subject, such as a Registry, collective management organization, studio, or other authorized Host.

• Trusted Certification: The <media:right> declaration includes a valid <media:certification> element issued by a certifying entity that the AI System trusts for the referenced Rights Subject, such as a law firm, agency, guild, or other trusted certifying entity.

AI Systems MAY rely on either model independently and MUST NOT require both. If conflicting declarations are encountered from trusted sources, AI Systems MUST apply Section 3.1.8.

The absence of an RSL-MEDIA declaration MUST NOT be interpreted as permission, authorization, waiver of rights, or any other legal conclusion.

Under the Trusted Host model, an AI System trusts a Host as a reliable source of RSL-MEDIA declarations for the applicable Rights Subject. Host trust is established outside the RSL-MEDIA document, including through contractual, policy-based, regulatory, or other governance mechanisms.

A publication URL, registry value, domain name, TLS certificate, or RSL-MEDIA Sitemap does not, by itself, establish Host trust. An AI System MUST treat a Host as trusted only for the Registry, Rights Subject category, and, where applicable, Rights Scope for which trust has been independently established. For example, an AI System might trust a collective management organization to publish declarations for musical compositions within that organization’s repertoire, but not for performer identities, sound recordings, marks, or works outside that repertoire.

For Default Declarations using registry-id="*", Host trust is limited to the Rights Subjects the AI System has independently determined the Host is trusted to represent or administer. A wildcard declaration, including any registry-subjects resource it references, does not establish subject membership or expand that trust scope.

If the required Host trust has not been established, the declaration MUST NOT be treated as trusted under the Trusted Host model. The declaration MAY still be trusted under the Trusted Certification model if it includes a valid <media:certification> issued by a trusted certifying entity.

Under the Trusted Certification model, an AI System trusts the certifying entity identified in <media:certification>, rather than the Host publishing the document. A valid certification indicates that the declaration reflects the claims reviewed and certified by that entity at the time of certification.

An AI System MUST treat a certification as trusted only within the scope for which it independently trusts the certifying entity, including the applicable Registry, Rights Subject category, Rights Scope, and, for Default Declarations, the Rights Subjects the certifying entity is trusted to represent or certify. A valid signature establishes integrity and signer identity material; it does not establish trust outside that scope and MUST NOT be used to expand the certifying entity’s trusted scope.

For Default Declarations using registry-id="*", a wildcard declaration, including any registry-subjects resource it references, does not establish subject membership or expand that trust scope.

RSL-MEDIA may support embedded certified declarations in digital assets in a future version or companion specification. This specification does not define format-specific embedding mechanisms or processing rules.

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

These elements are required for all RSL-MEDIA license declarations, independent of whether trust is established through the Trusted Host model or the Trusted Certification model. This requirement supplements the base RSL 1.0 <license> definition.

If a <license> within a <media:right> is non-authoritative under this section, an AI System MUST exclude that <license> from evaluation. Other <license> elements in the same <media:right> MAY continue to be evaluated if they satisfy this section and the declaration is otherwise trusted and in force.

Example: Required Legal Elements

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

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

When an AI System relies on a <media:right> declaration, including after initial retrieval or revalidation, it SHOULD retain a retrieval record sufficient to support later revalidation, change detection, audit, and dispute-resolution workflows.

The retrieval record SHOULD identify the ISRD, source URL, retrieval time, trust basis, and either the retrieved declaration or a digest of the signed JWS payload defined in Section 3.2.1.

RSL-MEDIA defines how license declarations are expressed, trusted, and evaluated. It does not define the operational procedures for resolving authority disputes. Those procedures are governed by applicable policies, agreements, Registry rules, certification processes, and dispute-resolution workflows.

When an AI System identifies a conflict under Section 3.1.8, it MUST apply the conflict rules in that section. The AI System MUST NOT rely on any conflicting declaration for the disputed Rights Scope unless and until the authority conflict is resolved.

The AI System SHOULD notify the contact URL provided in each conflicting <legal type="contact"> element. The notice SHOULD identify the conflicting declarations, the affected Rights Subject, the disputed Rights Scope, and the basis on which the conflict was detected.

An AI System is not required by this specification to adjudicate ownership, agency, authorization, or other underlying authority questions beyond applying the trust, lifecycle, revalidation, and conflict rules defined by this specification.

Rights Holders, Representatives, Hosts, Registries, and certifying entities are responsible for resolving authority conflicts through the applicable verification or dispute-resolution process.

When a conflict is resolved, the responsible parties SHOULD publish or update the relevant RSL-MEDIA declarations, certifications, Registry records, or trust records so that the resolution can be evaluated by AI Systems.

For purposes of this specification, a conflict is resolved only when, after revalidation, the AI System no longer identifies conflicting applicable and trusted declarations for the same Rights Subject and Rights Scope.

Affected parties MAY use the <legal type="contact"> URL to raise disputes, submit corrections, or provide evidence of authority.

This specification does not define a dispute-notification format, response format, evidence standard, or resolution protocol. Participants SHOULD support automated or otherwise machine-readable workflows for conflict notification, verification, and resolution where practicable.

This Draft includes a draft RSL-MEDIA 1.0 conformance model to solicit review feedback. The conformance requirements, conformance classes, and operational dependencies will be finalized before publication of the final RSL-MEDIA 1.0 specification.

This specification defines four conformance classes. An implementation MAY conform to one or more classes.

An RSL-MEDIA document conforms to this specification if it satisfies:

• the namespace, encoding, and media-type requirements in Section 2.2;
• the document-structure, element, and attribute requirements in Section 3;
• the ISRD syntax and check-symbol requirements in Section 3.1.1.1;
• the lifecycle requirements in Section 3.1.6;
• the RSL-MEDIA usage-token requirements in Section 3.3; and
• the required <legal> element requirements in Section 5.4.

A <media:certification> element, when present, is a valid certification only if it satisfies the signed-content, JWS signature-profile, and certificate-usage requirements in Section 3.2.

A processor conforms to this specification if it parses RSL-MEDIA documents using XML namespace processing and applies the processor-level checks required by this specification for the functions it performs. These checks include, where applicable:

• URL, timestamp, ISRD, and JSON-LD validation
• lifecycle, usage-token, revalidation, trust, and conflict evaluation
• certification verification

A processor that verifies <media:certification> elements MUST implement the signed-content and verification rules in Sections 3.2.1 and 3.2.2, the certificate-usage requirements in Section 3.2.3, and the RSL-MEDIA JWS Signature Profile in Section 3.2.4.

An AI System conforms to this specification if, before relying on any RSL-MEDIA permission, prohibition, Clearance path, payment term, or other licensing consequence, it relies only on declarations that are applicable, trusted, current, and revalidated under this specification.

A Conforming AI System MUST apply:

• the trust evaluation rules in Section 5;
• the lifecycle and validity rules in Section 3.1.6;
• the revalidation rules in Section 3.1.7;
• the conflict-handling rules in Section 3.1.8; and
• the minor-protection rule in Section 1.1, where applicable.

A Host conforms to this specification if it publishes RSL-MEDIA documents and supports retrieval and revalidation of those documents according to this specification.

A Conforming Host MUST:

• publish RSL-MEDIA documents that satisfy the Conforming Document requirements in Section 6.1;
• ensure that each ISRD appears in no more than one current <media:right> declaration published by that Host;
• express withdrawal, supersession, or same-ISRD updates using the lifecycle rules in Section 3.1.6;
• satisfy the RSL-MEDIA Sitemap requirements in Section 4.1 for any RSL-MEDIA Sitemap resource it publishes; and
• retain historical records sufficient to identify the terms published for an ISRD at a given time as required by Section 3.1.1.3.

• RSL-MEDIA processors MUST disable external entity resolution and MUST NOT fetch external DTDs or external entities when processing RSL-MEDIA documents. Processors SHOULD reject documents containing DTD declarations unless required by a controlled processing environment.

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

• AI Systems retrieving RSL-MEDIA documents, Sitemaps, ISRD lookup records, or License Server resources over HTTPS MUST validate the server certificate and hostname according to current HTTPS/TLS best practices.

• AI Systems SHOULD treat stale, cached, mirrored, or otherwise replayed declarations as potential replay inputs. Before relying on any declaration, AI Systems MUST apply the lifecycle, revalidation, trusted-source, and conflict rules defined by this specification.

• RSL-MEDIA processors MUST verify <media:certification> signatures using the JWS profile in Section 3.2.4 and MUST treat the parsed signed <media:right> element from the JWS payload, not the enclosing published XML copy, as authoritative for evaluation under the Trusted Certification model. Processors MUST NOT use JWS header parameters such as jwk, jku, or x5u as alternative signer-identification mechanisms.

• AI Systems SHOULD treat unreachable or unverifiable declarations as unverified. If a declaration involved in an identified conflict becomes unreachable or unverifiable, the affected Rights Scope remains unresolved unless the conflict is resolved under Section 5.6.

• Registries SHOULD ensure that registry identifiers and published references are stable and resistant to spoofing, impersonation, or unauthorized reassignment.

This specification has no IANA actions.

• [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 5891] J. Klensin, “Internationalized Domain Names in Applications (IDNA): Protocol”, RFC 5891, August 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.

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

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

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

• [Schema.org] Schema.org, "Organization of Schemas".

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

The RSL Media Human Consent Standard specification was developed by the RSL Media 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 RSL Media Human Consent Standard (RSL-MEDIA) documents. It is intended to be used with the RSL 1.0 Relax NG schema to validate selected structural requirements of the RSL-MEDIA profile.

The schema introduces the https://rslmedia.org/media namespace, requires one or more <media:right> elements, and constrains selected uses of base RSL elements within <media:right> declarations. In a combined schema, this profile is expected to override the base RSL start pattern, for example by using a Relax NG include and redefining start for the RSL-MEDIA profile.

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

This schema validates the RSL-MEDIA 1.0 base profile only. It recognizes only the usage tokens defined by this specification. Extension profiles that define additional usage tokens are expected to publish their own schema modules or validation rules.

The RSL-MEDIA base profile permits extension child elements where allowed by this schema, but does not permit extension attributes on elements in the RSL-MEDIA namespace.

A document that satisfies this schema is not necessarily conforming. Full conformance also requires the processor-level and semantic checks defined by this specification.

Within this schema, <legal type="attestation"> is constrained to the value true, and <legal type="contact"> is constrained to a value beginning with https:// or mailto:, consistent with Section 5.4.

# RSL-MEDIA 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 RSL-MEDIA profile.

default namespace = "https://rslstandard.org/rsl"
namespace media = "https://rslmedia.org/media"
namespace xsd   = "http://www.w3.org/2001/XMLSchema-datatypes"

# The following named patterns are defined by the base RSL schema
# and MUST be available when this profile schema is used:
#
#   content,
#   foreignAttribute, foreignElement, schema, payment,
#   legalWarranty,
#   legalDisclaimer, legalProof,
#   permitsUser, permitsGeo,
#   prohibitsUser, prohibitsGeo
#
# This profile defines media-specific attestation, contact, and usage patterns.

# 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

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

# ISRD lexical form: RSL-XXXX-XXXX-C, where XXXX-XXXX is an
# 8-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.

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

isrdValueList = list { isrdValue+ }

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

timestampValue = xsd:dateTime

mediaRightSubject = "work" | "identity" | "character" | "mark"

# Accepts either a non-whitespace Registry ID or the wildcard value "*".
# Default Declaration semantics are defined in Section 3.1.5.

registryIdToken = xsd:string {
  pattern = "[^\s*]+"
}

specificRegistryAttributes =
  attribute registry-id { registryIdToken }

defaultRegistryAttributes =
  attribute registry-id { "*" },
  attribute registry-subjects { absoluteHttpsURI }?

mediaRightStatus = "active" | "withdrawn" | "superseded"

mediaAIGenerateToken = "media:ai-generate"
mediaAITrainToken = "media:ai-train"

# This RSL-MEDIA 1.0 base-profile schema validates only the usage tokens
# defined by this specification. Extension profiles may define additional
# usage tokens and publish their own schema modules or validation rules.

mediaUsageToken = mediaAIGenerateToken | mediaAITrainToken
mediaUsageList  = list { mediaUsageToken+ }

mediaSchema =
  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" }

# Descriptive role token for the certifying entity.

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

mediaCertification =
  element media:certification {
    attribute name    { xsd:string { minLength = "1" } },
    attribute contact { contactURI },
    attribute role    { certificationRoleValue }?,
    attribute time    { timestampValue },
    attribute jws     { jwsValue },
    empty
  }

mediaPermitsUsage    = element permits   { attribute type { "usage" }, mediaUsageList }
mediaProhibitsUsage  = element prohibits { attribute type { "usage" }, mediaUsageList }

# Every <license> within a <media:right> MUST contain <legal type="attestation">
# and <legal type="contact">. This profile permits the RSL license children
# listed below, plus foreign extension elements.

mediaLicenseChild =
    mediaPermitsUsage
  | mediaProhibitsUsage
  | permitsUser
  | prohibitsUser
  | permitsGeo
  | prohibitsGeo
  | payment
  | legalWarranty
  | legalDisclaimer
  | legalProof
  | foreignElement

# Overrides base legalAttestation with value constraint

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

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

mediaLicense =
  element license {
    (
      mediaLegalAttestation &
      mediaLegalContact &
      mediaLicenseChild*
    )
  }

mediaRight =
  element media:right {
    attribute isrd          { isrdValue },
    attribute issued        { timestampValue },
    attribute registry      { absoluteHttpsURI },
    (specificRegistryAttributes | defaultRegistryAttributes),
    attribute subject       { mediaRightSubject },
    attribute scope         { scopeTokenList }?,
    attribute status        { mediaRightStatus }?,
    attribute supersedes    { isrdValueList }?,
    attribute superseded-by { isrdValueList }?,
    attribute valid-from    { timestampValue }?,
    attribute valid-until   { timestampValue }?,
    attribute max-age       { xsd:positiveInteger }?,
    attribute server        { absoluteHttpsURI }?,

    (
      mediaLicense+ &
      mediaCertification? &
      mediaSchema &
      foreignElement*
    )
  }

# In a combined schema, this definition overrides the base RSL
# "start" pattern for the RSL-MEDIA profile, for example via
# Relax NG include with start redefinition, and requires at least
# one media:right element at the root level.

start =
  element rsl {
    attribute max-age { xsd:positiveInteger }?,
    foreignAttribute*,
    (
      (content* & mediaRight+ & foreignElement*)
    )
  }

The following JSON-LD profiles provide initial Schema.org-based structures for <schema> elements used with Rights Subject categories in RSL-MEDIA. These profiles will be refined and formalized with input from relevant registries, trade organizations, rights-holder representatives, and technical implementers before publication of the final RSL-MEDIA 1.0 specification.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Example Actor",
  "sameAs": "https://www.imdb.com/name/nm0000001/",
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "ExampleTalentRegistry",
    "value": "PERSON-123456"
  }
}

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Example Author",
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "ExampleAuthorRegistry",
    "value": "AUTHOR-123456"
  },
  "url": "https://example-author.example"
}

{
  "@context": "https://schema.org",
  "@type": "CreativeWork",
  "name": "Example Character",
  "sameAs": "https://universe.example/characters/example-character",
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "ExampleStudioCharacterID",
    "value": "CHAR-2025-000123"
  }
}

{
  "@context": "https://schema.org",
  "@type": "MusicRecording",
  "name": "Example Song (Original Recording)",
  "isrcCode": "USABC2500001",
  "url": "https://label.example/releases/example-song"
}

{
  "@context": "https://schema.org",
  "@type": "Movie",
  "name": "Example Movie",
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "ExampleMovieRegistry",
    "value": "MOVIE-1234567"
  },
  "url": "https://studio.example/movies/example-movie"
}

{
  "@context": "https://schema.org",
  "@type": "Book",
  "name": "Example Book",
  "isbn": "978-0-00-000000-2",
  "url": "https://publisher.example/books/example-book"
}

{
  "@context": "https://schema.org",
  "@type": "CreativeWork",
  "name": "Example Screenplay (Screenplay)",
  "genre": "Screenplay",
  "url": "https://guild.example/works/example-screenplay"
}

{
  "@context": "https://schema.org",
  "@type": "Painting",
  "name": "Example Painting",
  "creator": {
    "@type": "Person",
    "name": "Famous Artist"
  },
  "url": "https://museum.example/collections/example-painting"
}

{
  "@context": "https://schema.org",
  "@type": "Brand",
  "name": "Example Maison",
  "url": "https://brand.example",
  "logo": "https://brand.example/assets/logo.svg",
  "sameAs": [
    "https://www.instagram.com/examplemaison",
    "https://brand.example/rights/marks/examplemaison"
  ],
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "ExampleTrademarkRegistry",
    "value": "MARK-123456"
  }
}

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example Maison Signature Handbag",
  "brand": {
    "@type": "Brand",
    "name": "Example Maison",
    "url": "https://brand.example"
  },
  "category": "Luxury Goods",
  "image": [
    "https://brand.example/products/signature-handbag/front.jpg",
    "https://brand.example/products/signature-handbag/side.jpg"
  ],
  "sameAs": "https://brand.example/products/signature-handbag",
  "identifier": [
    {
      "@type": "PropertyValue",
      "propertyID": "ExampleProductRegistry",
      "value": "PRODUCT-123456"
    },
    {
      "@type": "PropertyValue",
      "propertyID": "ExampleTrademarkRegistry",
      "value": "MARK-123456"
    }
  ]  
}