Talent License Protocol - Reflections Talent API

The Talent License Protocol (TLP) 1.0 specifies how a license server decides whether a use of a real person’s identity may proceed, how platforms and generation tools act on that decision, how anyone verifies it afterwards, and how consent is withdrawn. Any license server, platform, generation tool or verifier can implement it. The Reflections Talent API is one implementation.

Status

Field	Value
Name	Talent License Protocol (TLP)
Version	1.0
Published	2026-10-15
Status	Stable. Changes are made only as described in Versions and changes.
Editor	Reflections

Notation

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY and OPTIONAL in these pages are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in all capitals. Requirements are numbered per page, such as TLP-DEC-4 on Decision semantics. Each requirement names the role it binds. Conformance lists the requirements of each role. Examples, diagrams and sections marked informative are not requirements.

Scope

TLP 1.0 covers:

deciding a use of a talent before anything is generated (the check), on the output itself (the generation), and during live generation (the session);
the three decisions, allow, deny and escalate, and when each may be returned;
the vocabulary that describes a use, and the registry of obligations a decision can carry;
signed tokens that carry an allow to the tool that runs the model;
signed receipts that anyone can verify offline, and their live status;
revocation, the deadlines that follow it, and acknowledgements;
how a platform finds the license server for a talent, and how anyone finds a license server’s keys.

Roles

Role	What it does	Example
License server	Holds talents’ licenses and postures. Decides checks, generations and sessions. Signs tokens and receipts. Publishes revocations.	The Talent API
Platform	Generates a real person for its end users or for licensees. Sends checks and generations, meets obligations, honors revocations.	Northlight, an image and video generation platform
Generation tool	Runs the model. Verifies an authorization or session token before it generates.	A model provider, or a tool an agent calls
Verifier	Checks a receipt, and reads its live status.	A distribution platform, a publisher, the talent

One product can hold several roles. A platform that runs its own models is also a generation tool, and it meets the requirements of both. Talent, representatives, licensees and end users are parties, not protocol roles: they act through a license server or a platform. See Terminology.

Out of scope

Contracts. TLP carries signed license revisions and their digests. It does not define how a license is negotiated or signed, what legal effect a signature has, or how disputes are settled.
Payments. TLP does not move money or define invoices. A license may state compensation, and the usage_report obligation requires usage to be reported, but billing and payment are outside the protocol.
Model training consent. Beyond the no_training obligation and a license’s training term, TLP does not govern whether a model may be trained on a person’s data.
Identity and accounts. How a license server confirms who a talent is, how a platform authenticates to a license server, and how a licensee lets a platform act for it are implementation choices.
Content policy. TLP enforces the terms a talent signed and the posture they published. It does not define what content is lawful or acceptable in general.

Wire format

TLP-GEN-1. A license server, platform, generation tool and verifier MUST exchange TLP objects as JSON (RFC 8259) encoded in UTF-8. Timestamps in objects MUST be RFC 3339 date-times in UTC. Durations MUST be ISO 8601 durations, such as PT60S or P7D. Times in tokens and receipts are JWT NumericDate values (seconds since the epoch). TLP-GEN-2. A license server MUST accept and return the check, generation, session, session sample, receipt, verification and revocation objects, and the events about them, with the fields, types and enumerated values the Talent API reference defines for the object of the same name in version 2026-10-15, except where these pages define a format themselves (tokens, receipts, the canonical form, the discovery document). A license server MAY add fields. It MAY serve these objects at any paths it lists in its discovery document. TLP-GEN-3. A recipient MUST ignore object fields it does not recognize, with one exception: an obligation whose type it does not recognize is unmet (TLP-OBL-2). TLP-GEN-4. A license server MUST make every POST operation idempotent under an Idempotency-Key request header: the same key and the same body return the original response. A platform MUST retry an operation whose outcome it does not know with the same key, never with a new one.

Document set

Page	Specifies
Conformance	The requirements of each role, and the conformance suite
Terminology	Normative definitions and identifier formats
Decision semantics	The three decisions at each stage, escalation, binding and the honesty rule
Use vocabulary	Modalities, use kinds, purposes, channels and territories
Obligations registry	The registered obligation types and how new ones are added
Tokens	Authorization and session tokens, verification, and the canonical form
Receipts	Receipt formats, signing keys, rotation, live status and receipt pages
Revocation	What revocation cuts, the deadlines that follow, and acknowledgements
Discovery	The discovery document and how a platform finds a talent’s license server
Security	The threat model and the requirements it sets
Privacy	Data minimization on both sides
Versions and changes	How the protocol is versioned and amended, and the change log

Interoperability pages map TLP to RSL 1.0, the Human Consent Standard, C2PA and ODRL 2.2.

Relationship to the Talent API

The Talent API is a license server that implements TLP 1.0. Its reference is the HTTP binding of the TLP objects. Features of the Talent API that TLP does not define, such as usage records, statements, connections and the MCP server, are documented in the reference and are not part of the protocol.

Conformance

The requirements of each role, in one place.

Decision semantics

allow, deny and escalate, normatively.

Tokens

Authorization and session tokens, and how to verify them.

Discovery

Find a license server and its keys.

​Status

​Notation

​Scope

​Roles

​Out of scope

​Wire format

​Document set

​Relationship to the Talent API

​Related