Skip to main content
This page specifies how the Talent License Protocol is versioned, what a minor and a major version may change, how implementations handle values from versions they do not know, and how changes are proposed and published.

​
Version numbers

TLP versions are major.minor, such as 1.0. The version appears in tlp.ver in every token and receipt, and in protocol_versions in the discovery document. A license server’s own API versions, such as the Talent API’s 2026-10-15, are separate from the protocol version. TLP-VER-1. A minor version MUST be compatible with every earlier minor version of the same major version. It MAY only:
  • add values to a registry: obligation types, reason codes, remedy types, escalation reasons, and values of the use vocabulary;
  • add optional fields that a party may ignore and still behave conformantly;
  • add requirements that apply only to the values and fields it adds;
  • correct an error, where the correction does not change conformant behavior.
TLP-VER-2. A change that removes or renames anything, changes a meaning, adds a decision, or requires a party on an earlier minor version to behave differently MUST be made in a new major version. A change in what a platform must do for an existing obligation is a new obligation type (TLP-OBL-15).

​
Handling unknown values

TLP-VER-3. A party that receives a value from a later minor version MUST handle it as follows: TLP-VER-4. A license server MUST keep verifying, and serving the live status of, every receipt it signed under any version, for as long as it retains the receipt. TLP-VER-5. A license server that adds a major version SHOULD serve the previous major version alongside it for at least 24 months, and MUST list every version it serves in protocol_versions.

​
Proposing a change

Reflections edits the Standard and keeps its registries. Anyone may propose a change: a registry value, a correction, or a new requirement.
1

Propose

Send the proposal through Reflections developer support. A proposal for an obligation type states what TLP-OBL-14 requires. Other proposals state the problem, the change to the text, and the effect on each role.
2

Review

The proposal is published for comment for at least 30 days. Implementers of every role may comment.
3

Publish

An accepted change is published on these pages with a new version number and date, and listed in the change log below and in the changelog.
Corrections that change no conformant behavior, such as fixing a typo or a broken link, are made without a new version and noted in the change log.

​
Change log

​
1.0, 2026-10-15

First publication. TLP 1.0 defines:
  • the four roles: license server, platform, generation tool and verifier;
  • the three decisions at the check, generation and session stages, escalation with a seven-day maximum, and the honesty rule;
  • the use vocabulary: five modalities, four use kinds, seven purposes, thirteen channels, and ISO 3166-1 territories with WW;
  • the obligations registry, with ten types;
  • the tlp-auth+jwt, tlp-session+jwt and tlp-receipt+jwt formats, ES256 signing, and the tlp-json-1 canonical form;
  • receipt live status, receipt pages, and key publication and rotation;
  • revocation with four scopes, three post-revocation policies, and acknowledgements;
  • the discovery document at /.well-known/talent-license and the signed talent index;
  • mappings to RSL 1.0, the Human Consent Standard, C2PA and ODRL 2.2.

Conformance

The requirements each version sets for each role.

API versioning

How the Talent API’s dated versions work.