Skip to main content
This page specifies how a TLP license server serves as the RSL license server for a talent: what the RSL server attribute points at, how it issues and introspects RSL License tokens, how an RSL document refers to a talent’s facets, and how RSL’s usage values map to TLP’s use fields.

RSL in brief (informative)

Really Simple Licensing (RSL) 1.0, maintained by the RSL Technical Steering Committee, is an XML vocabulary for machine-readable licensing terms. An RSL document (<rsl>) lists <content> elements, each with a url and an optional server attribute that names the RSL license server for that content. Each <content> holds <license> elements, whose <permits> and <prohibits> elements list values by type: usage, user and geo. When a value appears in both, it is prohibited. The Open License Protocol (OLP) is RSL’s protocol for licenses, built on OAuth 2.0: a client obtains a token whose token_type is License (RSL 1.0 §5.4.3) from the license server’s token endpoint, and a content host checks a token it receives by introspection at the license server (§5.5).

A TLP license server as an RSL license server

TLP-RSL-1. A TLP license server that serves as the RSL license server for a talent MUST serve OLP at the token_endpoint and introspection_endpoint of its discovery document, and the RSL documents that cover the talent MUST name it in their server attribute. For the Talent API, server is https://app.reflections.ai/oauth, the token endpoint is https://app.reflections.ai/oauth/token, and the introspection endpoint is https://app.reflections.ai/oauth/introspect. TLP-RSL-2. A <content> element whose url is a facet’s object IRI refers to that facet: the talent’s identity in that form, not a file. RSL documents for media of the talent, such as photos on the talent’s own site, MAY name the same server. TLP-RSL-3. A license server MUST issue a License token for content that covers a talent only when the requesting account holds a license covering the requested usage, or the talent’s posture declares that usage allowed. It MUST NOT issue one for a usage the talent’s posture declares prohibited. TLP-RSL-4. A license server MUST answer introspection of a License token with the fields RSL 1.0 §5.5.3 defines: active, token_type, license, resource, permitted and, when access is not permitted, reason. A token under a license that is revoked or suspended MUST be inactive from the revocation’s effective_at or the suspension. TLP-RSL-5. A License token is a license to use content as its RSL license describes, such as sending a talent’s reference media to a model as input. It is not a decision about a generation. A platform MUST still send a TLP check before it generates a talent, and a generation tool MUST NOT accept a License token as an authorization (TLP-TOK-8). TLP-RSL-6. An RSL document published for a talent by or for its license server MUST agree with the talent’s licenses and posture. A usage in <prohibits> corresponds to a prohibited declaration or a prohibited term, never to license_required. TLP-RSL-7. A platform that finds a server attribute covering a talent MUST treat that server as the talent’s license server, first in the order of TLP-DSC-5, and MUST confirm through its discovery document, at the server URL’s origin, that it is a TLP license server.

Example (informative)

An RSL document for Maya Okafor’s studio likeness facet. It permits commercial use of the facet’s reference media as model input in the United States and Canada, and prohibits training:

Mapping RSL values to TLP

Where an RSL value has a TLP counterpart, the two mean the same thing for a talent. Values with no counterpart are not translated. TLP’s modality, kind, the other purposes and channels have no RSL counterpart.

Divergences

Discovery

The discovery document and the order for finding a license server.

Human Consent Standard

The RSL extension for people and other rights subjects.