Network Working Group L. J. Reilly
Internet-Draft REM Technologies & Consulting, LLC
Intended status: Informational 6 September 2026
Expires: 10 March 2027
REM License Token (RLT) - Genesis Artifact
draft-reilly-rlt-genesis-02
6 September 2026
Abstract
This document defines the REM License Token, referred to as the RLT,
as the genesis artifact of the Reilly EternaMark Protocol (REM) for
digital permanence and verifiable provenance. This specification
formally defines the token structure, issuance procedures,
multi-algorithm cryptographic hash requirements, blockchain anchoring
requirements, DOI archival requirements, IPFS pinning requirements,
REMID namespace registration, verification methodology, token
lifecycle management, ecosystem integration, and security model.
The RLT represents an implementation of a Dual-Layer Digital
Permanence artifact combining a Bitcoin blockchain timestamp with
DOI-based archival to achieve durable, tamper-evident provenance
guarantees. Revision -01 expanded the token schema to version 2.0,
introduced multi-algorithm hashing via the REM Multi-Algorithm Stack
(REM-MAS), defined formal token lifecycle procedures, and documented
the RLT's integration with the broader REM Protocol ecosystem
including the Protocol Layer Prompt Engineering Specification
(PLPES), the Cognitive Trust Stack (CTS), the AI Machine-Readable
Ethics Directive (AIMED), and related Informational Internet-Drafts
authored by Lawrence John Reilly Jr.
This revision (-02) is additive. It retains the whole of the -01
specification and adds token schema version 2.1, a canonical form
and record digest for token self-integrity, salted field
commitments with selective disclosure, a COSE signature profile,
batch issuance with Merkle aggregation, pending and attested anchor
states, hash migration bridging records, conformance levels C0
through C4, status records and a revocation registry, an anchor
scope rule, the prior art record function under 35 U.S.C. 102(a)(1),
and further ecosystem, privacy, and evidentiary considerations.
This document is published as an Informational Internet-Draft to
serve as open, implementable guidance.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Reilly Expires 10 March 2027 [Page 1]
Internet-Draft REM License Token (RLT) September 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of This Revision . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Additional Terminology Introduced in This Revision . . . 9
3. Background and Rationale . . . . . . . . . . . . . . . . . . . 10
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . 10
3.2. Dual-Layer Digital Permanence . . . . . . . . . . . . . 11
3.3. The REM Protocol Ecosystem . . . . . . . . . . . . . . . 12
3.4. Ecosystem Reference Index . . . . . . . . . . . . . . . 13
4. RLT Genesis Artifact Definition . . . . . . . . . . . . . . . 15
4.1. Commercial Licensing Terms . . . . . . . . . . . . . . . 16
4.2. Genesis Record . . . . . . . . . . . . . . . . . . . . . 16
4.3. Multi-Algorithm Hash Record . . . . . . . . . . . . . . 17
4.4. Anchor Scope Rule . . . . . . . . . . . . . . . . . . . 17
4.5. Prior Art Record Function Under 35 U.S.C. 102(a)(1) . . 18
4.6. Licensing Terms and IETF Document Rights . . . . . . . . 19
5. Token Schema Version 2.0 . . . . . . . . . . . . . . . . . . . 20
5.1. JSON Schema Definition . . . . . . . . . . . . . . . . . 20
5.2. Field Descriptions . . . . . . . . . . . . . . . . . . . 22
Reilly Expires 10 March 2027 [Page 2]
Internet-Draft REM License Token (RLT) September 2026
5.3. Backward Compatibility with Version 1.0 . . . . . . . . 24
5.4. Token Schema Version 2.1 . . . . . . . . . . . . . . . . 24
5.5. Canonical Form and Record Digest . . . . . . . . . . . . 27
5.6. Field Commitments and Selective Disclosure . . . . . . . 28
5.7. Token Signature Profile . . . . . . . . . . . . . . . . 28
6. Issuance and Anchoring Requirements . . . . . . . . . . . . . 29
6.1. Pre-Issuance Preparation . . . . . . . . . . . . . . . . 29
6.2. Multi-Algorithm Hash Computation . . . . . . . . . . . . 30
6.3. OpenTimestamps Anchoring . . . . . . . . . . . . . . . . 30
6.4. DOI Archival via Zenodo . . . . . . . . . . . . . . . . 31
6.5. IPFS Pinning . . . . . . . . . . . . . . . . . . . . . . 32
6.6. Web Archival . . . . . . . . . . . . . . . . . . . . . . 32
6.7. REMID Namespace Registration . . . . . . . . . . . . . . 32
6.8. Token Assembly and Publication . . . . . . . . . . . . . 33
6.9. Batch Issuance and Merkle Aggregation . . . . . . . . . 33
6.10. Pending and Attested Anchor States . . . . . . . . . . 34
6.11. Hash Migration and Bridging Records . . . . . . . . . . 35
7. Verification Requirements . . . . . . . . . . . . . . . . . . 36
7.1. Hash Verification . . . . . . . . . . . . . . . . . . . 36
7.2. Blockchain Proof Verification . . . . . . . . . . . . . 36
7.3. DOI Archival Verification . . . . . . . . . . . . . . . 37
7.4. IPFS Availability Verification . . . . . . . . . . . . . 37
7.5. Token Integrity Verification . . . . . . . . . . . . . . 37
7.6. Verification Result Codes . . . . . . . . . . . . . . . 38
7.7. Conformance Levels . . . . . . . . . . . . . . . . . . . 39
7.8. Additional Verification Result Codes . . . . . . . . . . 39
7.9. Verification of Batch-Anchored Tokens . . . . . . . . . 40
7.10. Verification of Signed Tokens and Commitments . . . . . 41
8. Token Lifecycle Management . . . . . . . . . . . . . . . . . . 41
8.1. Token States . . . . . . . . . . . . . . . . . . . . . . 41
8.2. Token Renewal . . . . . . . . . . . . . . . . . . . . . 42
8.3. Token Succession . . . . . . . . . . . . . . . . . . . . 42
8.4. Token Revocation . . . . . . . . . . . . . . . . . . . . 43
8.5. Token Archival . . . . . . . . . . . . . . . . . . . . . 43
8.6. Token State Transition Rules . . . . . . . . . . . . . . 44
8.7. Status Records and the Revocation Registry . . . . . . . 45
9. Ecosystem Integration . . . . . . . . . . . . . . . . . . . . 46
9.1. Integration with PLPES . . . . . . . . . . . . . . . . . 46
9.2. Integration with CTS . . . . . . . . . . . . . . . . . . 46
9.3. Integration with AIMED and AIMED-EVAL . . . . . . . . . 47
9.4. Integration with UAEMF . . . . . . . . . . . . . . . . . 47
9.5. Integration with WebProof . . . . . . . . . . . . . . . 47
9.6. Integration with RMRP . . . . . . . . . . . . . . . . . 48
9.7. Integration with RBIP and RGIP . . . . . . . . . . . . . 48
9.8. Integration with RRP and RSP . . . . . . . . . . . . . . 49
9.9. Integration with MWS and Cognitive Sovereignty . . . . . 49
9.10. Integration with CBPI and HDRP . . . . . . . . . . . . 49
9.11. AIGOV and Erasure-Compatible Permanence . . . . . . . . 50
Reilly Expires 10 March 2027 [Page 3]
Internet-Draft REM License Token (RLT) September 2026
9.12. Integration with the Web4 Profile . . . . . . . . . . . 50
10. Governance and Interoperability . . . . . . . . . . . . . . . 51
10.1. Schema Versioning Policy . . . . . . . . . . . . . . . 51
10.2. Namespace Governance . . . . . . . . . . . . . . . . . 52
10.3. Third-Party Implementations . . . . . . . . . . . . . . 52
10.4. Interoperability and Test Vectors . . . . . . . . . . . 53
10.5. Attribution and Priority Claims . . . . . . . . . . . . 53
11. Security Considerations . . . . . . . . . . . . . . . . . . . 54
11.1. Hash Algorithm Security . . . . . . . . . . . . . . . . 54
11.2. Blockchain Immutability Assumptions . . . . . . . . . . 55
11.3. DOI Archival Persistence . . . . . . . . . . . . . . . 55
11.4. Author Identity Assurance . . . . . . . . . . . . . . . 56
11.5. Post-Quantum Considerations . . . . . . . . . . . . . . 56
11.6. Token Forgery and Replay Attacks . . . . . . . . . . . 57
11.7. Supply Chain Integrity . . . . . . . . . . . . . . . . 58
11.8. Privacy and Data Minimization . . . . . . . . . . . . . 58
11.9. Canonicalization and Parser Differential Attacks . . . 59
11.10. Anchor Availability and Denial of Service . . . . . . 59
11.11. Evidentiary Limitations . . . . . . . . . . . . . . . 60
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
12.1. Anticipated Future Registrations . . . . . . . . . . . 61
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 61
13.1. Normative References . . . . . . . . . . . . . . . . . 61
13.2. Informative References . . . . . . . . . . . . . . . . 62
Appendix A. Example RLT Token v2.0 . . . . . . . . . . . . . . . 66
Appendix B. Example RLT Token v1.0 (Genesis Record) . . . . . . . 69
Appendix C. REM-MAS Algorithm Suite Reference . . . . . . . . . . 69
Appendix D. Implementation Notes . . . . . . . . . . . . . . . . 70
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 71
Appendix F. Canonical Form Worked Example . . . . . . . . . . . . 76
Appendix G. Example Hash Manifest . . . . . . . . . . . . . . . . 77
Appendix H. Token State Transition Table . . . . . . . . . . . . 77
Appendix I. Verification Algorithm Outline . . . . . . . . . . . 78
Appendix J. Example RLT Token v2.1 . . . . . . . . . . . . . . . 79
Appendix K. Conformance Checklist . . . . . . . . . . . . . . . . 81
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction
The Reilly EternaMark Protocol (REM) defines a Dual-Layer Digital
Permanence model, a term coined by Lawrence John Reilly Jr. in
September 2025. This model binds cryptographic timestamping on a
public blockchain with academic-grade DOI archival, creating a
provenance record that is independently verifiable, globally
accessible, and resilient against both technical failure and
institutional compromise.
Reilly Expires 10 March 2027 [Page 4]
Internet-Draft REM License Token (RLT) September 2026
The REM License Token (RLT) is the genesis artifact of this model:
the first artifact created and anchored using the REM Protocol's
full permanence stack. The original genesis anchor was recorded at
Bitcoin Block Height 914168 on or about September 10, 2025, with DOI
archival at 10.5281/zenodo.17438760.
Since the publication of draft-reilly-rlt-genesis-00 in November
2025, the REM Protocol ecosystem has expanded significantly. The
author has now published fourteen (14) active Informational
Internet-Drafts spanning AI ethics, trust architecture, prompt
engineering, banking integrity, resilience, government integrity,
model routing, web authenticity, and digital permanence. Several of
these drafts directly extend, reference, or build upon the RLT
foundation established in version -00.
This revision, draft-reilly-rlt-genesis-01, substantially expands
the specification in the following areas:
o Token Schema Version 2.0: Introduces mandatory multi-algorithm
hash fields (SHA-256, SHA3-512, BLAKE3), IPFS content addressing,
REMID namespace registration, Wayback Machine archival references,
and structured ecosystem linkage fields.
o REM Multi-Algorithm Stack (REM-MAS): Documents the formal multi-
algorithm hashing requirements introduced across the REM Protocol
ecosystem, providing defense-in-depth against single algorithm
compromise.
o Token Lifecycle Management: Defines formal token states, renewal
procedures, succession mechanics, revocation procedures, and
archival policies.
o Ecosystem Integration: Documents the RLT's integration role
within the broader REM Protocol suite, including PLPES, CTS,
AIMED, UAEMF, WebProof, and RMRP.
o Expanded Security Considerations: Addresses post-quantum
vulnerability, token forgery, replay attacks, supply chain
integrity, and long-term archival assumptions.
o Governance and Interoperability: Establishes schema versioning
policy, namespace governance, and guidance for third-party
implementations.
This document is intended for implementers, protocol architects,
auditors, and researchers working on digital provenance, intellectual
property verification, AI governance, and trusted publishing
infrastructure.
Reilly Expires 10 March 2027 [Page 5]
Internet-Draft REM License Token (RLT) September 2026
1.1. Scope of This Revision
This revision, draft-reilly-rlt-genesis-02, is strictly additive
with respect to draft-reilly-rlt-genesis-01. Every normative
requirement, schema field, procedure, result code, and appendix of
the -01 specification is carried forward unchanged. New material
appears as additional subsections within existing sections, as
additional appendices, and as additional reference entries. A
conforming version 2.0 token issued under -01 remains a conforming
version 2.0 token under this revision.
The paragraphs above describing "this revision" in the present
tense were written for -01 and are retained verbatim; they describe
the -01 changes. The changes introduced by -02 are the following:
o Token Schema Version 2.1 (Section 5.4): a backward-compatible
minor version adding OPTIONAL fields for the REM-MAS suite in
use, anchor scope, canonicalization profile, record digest,
field commitments, batch anchoring, status, and bridging.
o Canonical form and record digest (Section 5.5), giving the token
self-integrity independent of the artifact it describes.
o Salted per-field commitments and selective disclosure
(Section 5.6), so that a token may be published with sensitive
metadata withheld but still provable.
o A signature profile (Section 5.7) binding the record digest
under a detached signature.
o Batch issuance with Merkle aggregation (Section 6.9), pending
and attested anchor states (Section 6.10), and hash migration
bridging records (Section 6.11).
o Conformance levels C0 through C4 (Section 7.7), additional
result codes (Section 7.8), and verification procedures for
batch-anchored and signed tokens (Sections 7.9 and 7.10).
o State transition rules (Section 8.6) and a revocation registry
with status records (Section 8.7).
o Six further ecosystem integration subsections (Sections 9.7
through 9.12).
o Interoperability test vector requirements (Section 10.4) and an
attribution and priority claim policy (Section 10.5).
Reilly Expires 10 March 2027 [Page 6]
Internet-Draft REM License Token (RLT) September 2026
o Four further security subsections (Sections 11.8 through 11.11)
covering privacy and data minimization, canonicalization and
parser differential attacks, anchor availability, and
evidentiary limitations.
o An anchor scope rule (Section 4.4), the prior art record
function under 35 U.S.C. 102(a)(1) (Section 4.5), and the
relationship between the licensing terms of Section 4.1 and the
rights granted in IETF documents (Section 4.6).
o Appendices F through K.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are defined for use in this document:
RLT: REM License Token. The genesis artifact and primary token type
of the Reilly EternaMark Protocol. An RLT binds an artifact's
cryptographic identity to blockchain-anchored and DOI-archived
provenance records.
REM: Reilly EternaMark Protocol. A Dual-Layer Digital Permanence
protocol combining Bitcoin blockchain timestamping with Zenodo
DOI archival to create tamper-evident provenance records. First
published as draft-reilly-rem-protocol-00.
Dual-Layer Digital Permanence: A permanence methodology coined by
Lawrence John Reilly Jr. in September 2025 that combines at
minimum (a) a public blockchain timestamp and (b) a DOI-archived
record to achieve durable, independently verifiable provenance.
The correct term is "Dual-Layer Digital Permanence."
Implementations MAY extend this with additional layers including
IPFS, Web archival, and REMID namespace registration.
REM-MAS: REM Multi-Algorithm Stack. A multi-algorithm cryptographic
hashing framework that computes SHA-256, SHA3-512, and BLAKE3
hashes of a target artifact simultaneously, providing defense-in-
depth against single algorithm compromise. Defined in the REM
Protocol ecosystem and applied across all REM-anchored artifacts.
Reilly Expires 10 March 2027 [Page 7]
Internet-Draft REM License Token (RLT) September 2026
DOI: Digital Object Identifier. A persistent identifier standard
managed by the International DOI Foundation. In the REM Protocol,
DOIs are issued by Zenodo (https://zenodo.org), operated by CERN.
OTS: OpenTimestamps. An open standard and protocol for blockchain-
anchored cryptographic timestamps. OpenTimestamps proofs anchor a
SHA-256 hash into a Bitcoin block header via a Merkle inclusion
path, allowing independent verification without trust in any
central party. See https://opentimestamps.org.
IPFS: InterPlanetary File System. A content-addressed distributed
storage protocol that identifies files by their cryptographic
content hash (CID), enabling decentralized retrieval independent
of any single server.
CID: Content Identifier. The IPFS content-addressed hash string
that uniquely identifies a file or directory pinned to the IPFS
network.
REMID: REM Identifier Namespace. A namespace registration system
for REM Protocol artifacts, providing human-readable, persistent
identifiers for RLT tokens and related artifacts.
DAR: Digital Archival Record. The full set of permanence artifacts
associated with a given RLT issuance, including the source
document, OTS proof file, multi-algorithm hash manifest, DOI
record, IPFS pin, and REMID registration.
PLPES: Protocol Layer Prompt Engineering Specification. An IETF
Informational Internet-Draft (draft-reilly-plpes-00) authored by
Lawrence John Reilly Jr. that formally defines Protocol Layer
Prompt Engineering as a discipline and specifies structured prompt
engineering methodologies for AI systems. The term "Protocol
Layer Prompt Engineering" is attributed to Lawrence John Reilly
Jr.
CTS: Cognitive Trust Stack. An IETF Informational Internet-Draft
(draft-reilly-cts-00) defining a layered trust architecture for
AI reasoning systems, anchored to Bitcoin and Zenodo using the
REM Protocol permanence methodology.
AIMED: AI Machine-Readable Ethics Directive. An IETF Informational
Internet-Draft (draft-reilly-aimed-00) defining a machine-
readable ethics specification format for AI systems.
AIMED-EVAL: AI Machine-Readable Ethics Directive Evaluation
Framework. An IETF Informational Internet-Draft extending AIMED
with evaluation and compliance scoring methodologies.
Reilly Expires 10 March 2027 [Page 8]
Internet-Draft REM License Token (RLT) September 2026
UAEMF: Universal AI Ethics and Moral Framework. An IETF
Informational Internet-Draft (draft-reilly-uaemf-00) defining a
comprehensive ethics framework for AI systems, published with
Zenodo DOI and Bitcoin blockchain timestamp.
WebProof: Web Authenticity and Content Provenance Protocol. An
IETF Informational Internet-Draft (draft-reilly-webproof-00)
defining mechanisms for establishing the authenticity and
provenance of web-based content.
RMRP: Reilly Model Routing Protocol. An IETF Informational
Internet-Draft (draft-reilly-rmrp-00) defining a protocol for
intelligent routing of queries across heterogeneous AI model
ensembles.
Wayback Machine: The Internet Archive's web archival service
(https://web.archive.org), used as an additional permanence layer
in the REM Protocol stack.
Triple-Hash Verification: The process of computing and cross-
verifying SHA-256, SHA3-512, and BLAKE3 hashes of an artifact to
confirm integrity via the REM-MAS framework.
2.1. Additional Terminology Introduced in This Revision
The following additional terms are defined by this revision and
apply to version 2.1 tokens. They do not alter the meaning of any
term defined above.
Canonical Form: The deterministic byte serialization of an RLT
token produced by applying a named canonicalization profile
(Section 5.5) to the token object with the recordDigest and
signature values excluded. Two semantically identical tokens
MUST produce identical canonical forms.
Record Digest: A SHA-256 digest computed over the canonical form of
a token. The record digest gives the token itself an integrity
value distinct from the artifact hashes it carries, so that
modification of token metadata is detectable without reference
to the anchored artifact.
Field Commitment: A salted hash of a single token field value,
published in place of that value. A field commitment permits an
issuer to withhold a value while remaining able to prove it
later by disclosing the value and its salt.
Reilly Expires 10 March 2027 [Page 9]
Internet-Draft REM License Token (RLT) September 2026
Selective Disclosure: The act of revealing a withheld field value
and its salt to a specific verifier, who confirms the disclosure
by recomputing the corresponding field commitment.
Anchor Scope: The declaration of exactly which byte sequence a
given hash set and blockchain proof cover. See Section 4.4.
Pending Anchor: A blockchain anchor for which a calendar
attestation has been obtained but Bitcoin block confirmation has
not yet been observed. See Section 6.10.
Attested Anchor: A blockchain anchor for which Bitcoin block
confirmation has been independently observed and the block
height recorded. See Section 6.10.
Batch Anchor: A blockchain anchor covering a Merkle tree root under
which multiple artifact hashes are aggregated, together with the
inclusion proof for a given artifact. See Section 6.9.
Bridging Record: A record that binds an artifact's existing hash
set to a hash set computed under a newly adopted algorithm,
preserving the evidentiary value of the original anchor across a
hash algorithm migration. See Section 6.11.
Status Record: A small, independently retrievable object that
publishes the current lifecycle state of a token identified by
tokenId, so that state changes can be discovered without
re-fetching the full token. See Section 8.7.
Prior Art Record: An RLT whose anchored artifact has been made
publicly accessible without restriction, such that the artifact
constitutes a disclosure available to the public within the
meaning of 35 U.S.C. 102(a)(1) [USC-35-102], with the blockchain
timestamp serving as independent corroboration of the date of
that public availability. See Section 4.5.
3. Background and Rationale
3.1. Problem Statement
Intellectual property, authorship, and digital provenance frequently
require durable, independently verifiable records. The growth of
AI-generated content, automated publishing, and distributed
information systems has made establishing trustworthy origin records
more challenging and more important simultaneously.
Traditional provenance systems exhibit several weaknesses:
Reilly Expires 10 March 2027 [Page 10]
Internet-Draft REM License Token (RLT) September 2026
o Centralized registries are subject to organizational failure,
political interference, or policy changes that may alter or
remove records.
o Contractual and notarial evidence requires trust in specific
parties and is not globally machine-verifiable.
o Proprietary evidence systems create vendor lock-in and may not
survive organizational changes.
o Simple file timestamps and hash registries lack the binding
strength of an immutable public ledger anchoring.
o Academic citation and preprint systems lack cryptographic
integrity guarantees.
o AI-generated content is increasingly difficult to distinguish
from human-authored content without reliable authorship anchoring.
These weaknesses collectively create an environment in which
establishing durable, verifiable provenance for digital artifacts,
particularly those intended to inform AI systems, legal proceedings,
standards processes, or public discourse, is unreliable without
cryptographic anchoring.
3.2. Dual-Layer Digital Permanence
The REM Protocol addresses these weaknesses through a Dual-Layer
Digital Permanence methodology, coined by Lawrence John Reilly Jr.
in September 2025.
The core insight is that no single permanence mechanism is
sufficient:
o Blockchain timestamps alone lack human-readable, searchable
metadata and institutional recognition.
o DOI archival alone lacks cryptographic binding to a specific
point in time independent of the archiving institution.
o Web archival alone is not cryptographically strong.
By combining these mechanisms, the REM Protocol achieves properties
no single mechanism provides individually:
Reilly Expires 10 March 2027 [Page 11]
Internet-Draft REM License Token (RLT) September 2026
o Bitcoin blockchain timestamps provide cryptographic proof that a
specific hash existed before a specific block was mined, with a
security guarantee backed by the total Bitcoin mining hash rate.
This is independently verifiable by any party with access to the
Bitcoin chain, with no trust in the REM Protocol author.
o Zenodo DOI archival provides an institutionally recognized,
academically citable record with structured metadata, long-term
preservation commitments by CERN, and global discoverability via
DOI resolver networks.
o IPFS pinning provides content-addressed, decentralized
availability independent of any single server, identified by a
CID that is itself a cryptographic hash of the content.
o Wayback Machine archival provides an additional independent
snapshot of the artifact at a specific point in time, with its
own institutional persistence.
o REMID namespace registration provides human-readable, persistent
identifiers that link into the REM ecosystem.
The combination of these layers produces a Dual-Layer Digital
Permanence record (with optional extension to five or more
independent layers) that is cryptographically strong, institutionally
recognized, decentralized, and globally accessible.
3.3. The REM Protocol Ecosystem
Since the initial publication of the REM Protocol in September 2025,
the author has developed a suite of fourteen (14) active
Informational Internet-Drafts that collectively form the REM Protocol
ecosystem. These drafts span the following domains:
o Digital Permanence and Provenance: draft-reilly-rem-protocol,
draft-reilly-rlt-genesis (this document)
o AI Ethics and Governance: draft-reilly-uaemf,
draft-reilly-aimed, draft-reilly-aimed-eval
o Trust Architecture: draft-reilly-cts, draft-reilly-webproof
o Prompt Engineering: draft-reilly-plpes
o Model Routing: draft-reilly-rmrp
Reilly Expires 10 March 2027 [Page 12]
Internet-Draft REM License Token (RLT) September 2026
o Financial Systems Integrity: draft-reilly-rbip (Reilly Banking
Integrity Protocol), draft-reilly-rgip (Reilly Government
Integrity Protocol)
o Resilience: draft-reilly-rrp (Reilly Resilience Protocol),
draft-reilly-rsp (Reilly Sentinel Protocol)
The RLT, as the genesis artifact of this ecosystem, plays a
foundational anchoring role. Each subsequent draft in the ecosystem
applies the Dual-Layer Digital Permanence methodology established
by the RLT, and several drafts explicitly reference the RLT as their
provenance foundation.
The RLT schema version 2.0 defined in this document includes
structured fields for referencing affiliated ecosystem artifacts,
enabling machine-readable traversal of the REM Protocol artifact
graph.
3.4. Ecosystem Reference Index
Section 3.3 describes the ecosystem as it stood when
draft-reilly-rlt-genesis-01 was written. The ecosystem has
continued to grow since. This subsection provides a corrected and
current index of the documents cited by this revision, and is the
authoritative list of ecosystem citations for -02.
Two corrections apply to the citation list carried forward from
-01. First, the short names "draft-reilly-rbip", "draft-reilly-
rgip", "draft-reilly-rrp", and "draft-reilly-rsp" used in
Section 3.3 are working abbreviations and are not the names under
which those documents are published. The published document names
are draft-reilly-banking-integrity [RBIP],
draft-reilly-government-integrity [RGIP],
draft-reilly-resilience-protocol [RRP], and
draft-reilly-sentinel-protocol [RSP]. Second, Internet-Draft
reference entries in Section 13.2 cite document series names
without a revision suffix, so that a citation resolves to the
current revision of the cited document rather than to a revision
that may since have been superseded.
Permanence and provenance:
o The REM Protocol itself [REM-PROTOCOL], which defines the
dual-layer method this token instantiates.
o The genesis revision of this document [RLT-GENESIS-00].
Reilly Expires 10 March 2027 [Page 13]
Internet-Draft REM License Token (RLT) September 2026
o The triple-fingerprint permanence chain [TRIPLE-FP], which
develops the entangled multi-algorithm construction on which
REM-MAS practice in the suite is based.
o Bulk subtree consistency proofs [SUBTREE], which supply the
aggregation and inclusion proof machinery used in Section 6.9.
AI ethics, governance, and trust:
o Universal AI Ethics and Moral Framework [UAEMF].
o AI Machine-Readable Ethics Directive [AIMED] and its evaluation
framework [AIMED-EVAL].
o Cognitive Trust Stack [CTS].
o Verifiable AI governance and data privacy records [AIGOV].
o Verifiable compliance records for AI usage preferences
[AIPREF-COMP].
o Cognitive Behavioral Provenance and Integrity [CBPI].
Web, agent, and routing architecture:
o Protocol Layer Prompt Engineering Specification [PLPES].
o Web Authenticity and Content Provenance Protocol [WEBPROOF].
o Reilly Model Routing Protocol [RMRP].
o Machine-Web Symbiosis [MWS] and Cognitive Sovereignty [COGSOV].
o The Web4 conformance profile [WEB4].
Integrity, resilience, and topology:
o Reilly Banking Integrity Protocol [RBIP] and Reilly Government
Integrity Protocol [RGIP].
o Reilly Resilience Protocol [RRP] and Reilly Sentinel Protocol
[RSP].
o Hypercube Data Rotation Protocol [HDRP].
o Project Atlas [ATLAS] and the Multilarity analysis
[MULTILARITY].
Reilly Expires 10 March 2027 [Page 14]
Internet-Draft REM License Token (RLT) September 2026
o Verifiable Safeguards Records [VSR], which applies the same
commitment and reconciliation machinery in a regulated
accountancy setting.
External normative and informative material relied on by this
revision includes OpenTimestamps [OTS], IPFS [IPFS], the SHA-3
standard [FIPS202], the stateless hash-based signature standard
[FIPS205], BLAKE3 [BLAKE3], language tags [BCP47], JSON
canonicalization [RFC8785], CBOR [RFC8949], COSE [RFC9052], UUIDs
[RFC9562], Internet date and time formats [RFC3339], Merkle tree
log constructions [RFC6962], media type registration procedures
[RFC6838], the Zenodo genesis deposit [ZENODO-RLT], and
35 U.S.C. 102(a)(1) [USC-35-102].
4. RLT Genesis Artifact Definition
The REM License Token binds together the following information
classes into a single, cryptographically anchored, permanently
archived token:
o Author identity information including name and optional ORCID
identifier.
o Multi-algorithm cryptographic hashes (SHA-256, SHA3-512, BLAKE3)
of the canonical reference document.
o Blockchain timestamp proof anchored to the Bitcoin network via
OpenTimestamps.
o DOI archival reference pointing to the Zenodo record containing
the artifact, hash manifest, and OTS proof file.
o IPFS content identifier (CID) for decentralized content
addressing.
o Wayback Machine snapshot URL for additional independent archival.
o REMID namespace registration identifier.
o Token issuance metadata including schema version, issuance date,
and token unique identifier.
o Ecosystem linkage fields referencing affiliated REM Protocol
artifacts.
Reilly Expires 10 March 2027 [Page 15]
Internet-Draft REM License Token (RLT) September 2026
4.1. Commercial Licensing Terms
The REM License Token carries inherent commercial licensing terms
as part of its issuance. Any commercial use, deployment,
integration, or derivative implementation of an RLT-anchored
artifact, or of any system, product, or service that incorporates,
references, or is governed by an RLT-anchored artifact, is subject
to the following perpetual royalty obligation:
A royalty of two and one-half percent (2.5%) of gross revenues
directly or indirectly attributable to the commercial use of the
RLT-anchored artifact SHALL be remitted to Lawrence John Reilly
Jr. This obligation is perpetual, worldwide, and survives any
transfer, sublicense, or assignment of rights in the artifact or
any derivative work.
This commercial licensing obligation applies globally and is not
limited by jurisdiction. The obligation attaches at the point of
issuance and is recorded as part of the permanent provenance record
anchored to the Bitcoin blockchain and DOI archive. Because the
underlying provenance record is immutable, the licensing obligation
is likewise permanent and cannot be extinguished by subsequent
modification or revocation of any token referencing the artifact.
Non-commercial use, academic citation, and independent verification
of the artifact are explicitly permitted without royalty obligation
under the Creative Commons CC-BY-4.0 license terms.
Commercial licensees SHOULD contact the author at the email address
recorded in the Author's Address section of this document to
establish a formal licensing agreement.
4.2. Genesis Record
The canonical REM License Token genesis artifact, representing the
initial application of the Dual-Layer Digital Permanence model, is
archived under the following permanent identifiers:
DOI: 10.5281/zenodo.17438760
Zenodo URL: https://zenodo.org/records/17438760
Metadata Date: November 16, 2025
Blockchain Anchor: Bitcoin Block Height 914168
Approximate Anchor Date: September 10, 2025
Reilly Expires 10 March 2027 [Page 16]
Internet-Draft REM License Token (RLT) September 2026
4.3. Multi-Algorithm Hash Record
The genesis artifact is identified by the following cryptographic
hashes computed over the canonical reference document
(RLT_FIRST_TOKEN_FULL_GUIDE_v2.pdf):
SHA-256:
9964A78C6FC33794EF840ED69045C5C2477BC611CBC73EF6EC537FACA4C7BB74
SHA3-512:
To be computed and recorded per REM-MAS procedures. Issuers
implementing version 2.0 tokens MUST compute and record all
three algorithm outputs.
BLAKE3:
To be computed and recorded per REM-MAS procedures. Issuers
implementing version 2.0 tokens MUST compute and record all
three algorithm outputs.
Note: The SHA-256 value above is the original genesis hash recorded
at Bitcoin Block Height 914168 and is the normative reference hash
for the genesis RLT. SHA3-512 and BLAKE3 values for the genesis
artifact should be computed by implementers verifying the genesis
record against the canonical Zenodo archive.
The two placeholder values above were enclosed in square brackets
in draft-reilly-rlt-genesis-01. The brackets are removed in this
revision because bracketed text is parsed as a citation tag by
Internet-Draft tooling. The substance of the placeholders is
unchanged.
4.4. Anchor Scope Rule
An RLT hash set and its associated blockchain proof cover exactly
one byte sequence. The following rule is normative for version 2.0
and version 2.1 tokens alike, and clarifies a requirement that was
implicit in -01:
One artifact, one hash set, one proof. The values in the hashes
object MUST be computed over the single canonical artifact file
identified by artifact.filename, and the OpenTimestamps proof
identified by blockchain.proofFile MUST have been produced over
that same file. A hash computed over an archive, a directory
listing, a landing page, a schema, or a concatenation of files
MUST NOT be recorded as though it were the artifact hash.
Reilly Expires 10 March 2027 [Page 17]
Internet-Draft REM License Token (RLT) September 2026
Where a package of several files is to be anchored, the issuer MUST
either anchor each file independently, producing one token per
file, or anchor a manifest file that lists each member file with
its own hash set, in which case the manifest is the artifact and
artifact.type MUST be "document" with the manifest's own filename
recorded.
A token schema, a verification tool, or a landing page associated
with an artifact is itself a distinct artifact. If its provenance
is to be established, it MUST be anchored independently under its
own token. Reusing an artifact's hash set to assert the provenance
of an associated file is a scope error and, if detected by a
verifier, MUST be reported as ANCHOR_SCOPE_ERROR (Section 7.8).
Issuers of version 2.1 tokens MUST record the anchorScope object
defined in Section 5.4, which makes the covered byte sequence and
its length explicit.
4.5. Prior Art Record Function Under 35 U.S.C. 102(a)(1)
An RLT whose artifact has been publicly deposited operates as a
prior art record in the same sense as a Full REM Record described
in the REM Protocol specification [REM-PROTOCOL]. 35 U.S.C.
102(a)(1) [USC-35-102], as amended by the Leahy-Smith America
Invents Act, provides that a person is not entitled to a patent if
the claimed invention was patented, described in a printed
publication, or in public use, on sale, or otherwise available to
the public before the effective filing date of the claimed
invention.
A completed RLT issuance produces the evidentiary elements relevant
to that provision:
Public accessibility:
Open-access DOI deposit (Section 6.4) makes the artifact
available to any member of the public without restriction,
registration barrier, or fee, and discoverable through globally
resolvable DOI infrastructure.
Date certainty:
The blockchain anchor (Section 6.3) provides cryptographically
verifiable corroboration that the artifact existed in its exact
recorded form no later than the confirmed block, independent of
the issuer's own records and of the repository operator.
Reilly Expires 10 March 2027 [Page 18]
Internet-Draft REM License Token (RLT) September 2026
Content integrity:
The REM-MAS hash set (Section 6.2) binds the asserted date to
the precise byte-level content disclosed, so that a claim of
later alteration or substitution is defeated by hash
verification (Section 7.1).
Two limitations apply. First, a token whose artifact has been
hashed and anchored but not publicly deposited establishes proof of
existence only; it does not constitute a Prior Art Record, because
the content was not available to the public. Second, this
subsection is informational. Whether a given disclosure qualifies
as prior art in a particular examination, post-grant proceeding, or
litigation is determined by the applicable patent office or court
on the facts of that matter, and nothing in this document
constitutes legal advice.
Issuers operating a token in this mode SHOULD set the priorArt
object defined in Section 5.4 and SHOULD capture an independent web
archive snapshot of the DOI landing page (Section 6.6) evidencing
public accessibility at points in time after publication.
4.6. Licensing Terms and IETF Document Rights
Section 4.1 states commercial licensing terms attaching to
RLT-anchored artifacts. Those terms are a property of the artifact
an issuer chooses to anchor. They are not, and cannot be, a
restriction on this Internet-Draft or on any Internet-Draft.
This document is submitted in full conformance with BCP 78 and
BCP 79. The rights granted to the IETF Trust and to the public in
the text of this document, including the right to implement,
reproduce, and prepare derivative works to the extent provided by
the IETF Trust Legal Provisions, are unaffected by Section 4.1. In
particular:
o Implementing the RLT schema, the issuance procedures, or the
verification procedures specified in this document carries no
royalty obligation of any kind. Section 10.3 states this
directly, and Section 4.1 MUST NOT be read to contradict it.
o The Section 4.1 terms apply, if at all, only to a third party's
commercial exploitation of a specific artifact that the artifact
rights holder has anchored and licensed on those terms, and only
to the extent that the applicable law of the relevant
jurisdiction gives effect to them. They are a licensing
declaration recorded in a provenance record, not a statement of
IETF policy and not an intellectual property right created by
this document.
Reilly Expires 10 March 2027 [Page 19]
Internet-Draft REM License Token (RLT) September 2026
o A third-party issuer using this specification for its own
artifacts sets its own license terms and records them in the
license field. Nothing in Section 4.1 attaches to artifacts the
author of this document does not own.
Any IPR relating to this document is disclosed through the IETF
IPR disclosure process, not through this section or Section 4.1.
5. Token Schema Version 2.0
5.1. JSON Schema Definition
The RLT version 2.0 JSON schema is defined as follows. Fields
marked REQUIRED MUST be present in all conforming version 2.0
tokens. Fields marked OPTIONAL MAY be omitted if the corresponding
permanence layer has not been applied.
{
"$schema": "https://rem-protocol.org/schema/rlt/v2.0",
"rltVersion": "2.0",
"tokenId": "<uuid-v4-string>",
"schemaDate": "2026-05-14",
"author": {
"name": "<Full Legal Name>", // REQUIRED
"orcid": "<ORCID URI or null>", // OPTIONAL
"affiliation": "<Organization or null>", // OPTIONAL
"email": "<contact email or null>" // OPTIONAL
},
"artifact": {
"title": "<Human-readable artifact title>", // REQUIRED
"type": "<document|protocol|specification|other>", // REQUIRED
"filename": "<canonical filename>", // REQUIRED
"mimeType": "<MIME type string>", // RECOMMENDED
"language": "en" // OPTIONAL, BCP47 tag
},
"license": "CC_BY_4_0", // REQUIRED
"hashes": { // REQUIRED
"sha256": "<64-char hex string>", // REQUIRED
"sha3_512": "<128-char hex string>", // REQUIRED (v2.0+)
"blake3": "<64-char hex string>" // REQUIRED (v2.0+)
},
"hashManifestUrl": "<URL to hash manifest>", // RECOMMENDED
Reilly Expires 10 March 2027 [Page 20]
Internet-Draft REM License Token (RLT) September 2026
"dates": {
"artifactCreated": "<ISO 8601 date>", // REQUIRED
"tokenIssued": "<ISO 8601 date>", // REQUIRED
"blockchainAnchor": "<ISO 8601 date>", // REQUIRED
"doiRegistered": "<ISO 8601 date>", // REQUIRED
"nextReviewDue": "<ISO 8601 date>" // RECOMMENDED
},
"blockchain": {
"chain": "Bitcoin", // REQUIRED
"blockHeight": <integer>, // REQUIRED
"blockHash": "<64-char hex string>", // RECOMMENDED
"timestamp": "<ISO 8601 datetime>", // REQUIRED
"proofFile": "<OTS filename>", // REQUIRED
"proofUrl": "<URL to OTS proof file>" // REQUIRED
},
"doi": {
"identifier": "<DOI string>", // REQUIRED
"url": "<DOI resolver URL>", // REQUIRED
"registrar": "Zenodo" // REQUIRED
},
"ipfs": {
"cid": "<IPFS CID string>", // OPTIONAL
"gateway": "<IPFS gateway URL>", // OPTIONAL
"pinnedAt": "<ISO 8601 date>" // OPTIONAL
},
"webArchival": {
"waybackUrl": "<Wayback Machine URL>", // OPTIONAL
"archivedAt": "<ISO 8601 date>" // OPTIONAL
},
"remid": {
"identifier": "<REMID string>", // OPTIONAL
"namespace": "rem-protocol", // OPTIONAL
"registeredAt": "<ISO 8601 date>" // OPTIONAL
},
"tokenState": "ACTIVE", // REQUIRED
// Values: ACTIVE | RENEWED |
// SUPERSEDED | REVOKED |
// ARCHIVED
"predecessorToken": "<tokenId or null>", // OPTIONAL
"successorToken": "<tokenId or null>", // OPTIONAL
Reilly Expires 10 March 2027 [Page 21]
Internet-Draft REM License Token (RLT) September 2026
"ecosystem": {
"protocol": "REM", // REQUIRED
"protocolDraft": "draft-reilly-rem-protocol-00", // REQUIRED
"affiliatedDrafts": [ // OPTIONAL
"<draft-name-00>",
"<draft-name-01>"
],
"complianceProfiles": [] // OPTIONAL
},
"verification": {
"verificationUrl": "<URL>", // OPTIONAL
"publicVerifierEndpoint": "<URL>" // OPTIONAL
},
"signature": {
"type": "<signature type or null>", // OPTIONAL
"value": "<signature value or null>", // OPTIONAL
"keyId": "<key identifier or null>" // OPTIONAL
}
}
5.2. Field Descriptions
rltVersion (REQUIRED): The schema version of this token. MUST be
"2.0" for tokens conforming to this specification. Tokens using
the original schema from draft-reilly-rlt-genesis-00 carry
version "1.0".
tokenId (REQUIRED): A globally unique identifier for this token
instance. MUST be a UUID version 4 string in standard hyphenated
format (xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx).
schemaDate (REQUIRED): The publication date of the schema version
used for this token. For version 2.0 tokens, this SHOULD be
"2026-05-14" or a later date if a subsequent schema revision has
been issued.
author.name (REQUIRED): The full legal name of the artifact's
author or primary rights holder.
author.orcid (OPTIONAL): The author's Open Researcher and
Contributor ID (ORCID) URI, if available. Format:
https://orcid.org/XXXX-XXXX-XXXX-XXXX.
artifact.title (REQUIRED): A human-readable title for the anchored
artifact.
Reilly Expires 10 March 2027 [Page 22]
Internet-Draft REM License Token (RLT) September 2026
artifact.type (REQUIRED): The artifact type classification.
Permitted values are: "document", "protocol", "specification",
"software", "dataset", or "other".
license (REQUIRED): The license under which the artifact is
published. Implementations SHOULD use SPDX license identifiers.
The REM Protocol genesis artifact uses "CC-BY-4.0".
hashes.sha256 (REQUIRED): The SHA-256 hash of the canonical
artifact file, expressed as a 64-character uppercase hexadecimal
string.
hashes.sha3_512 (REQUIRED for v2.0): The SHA3-512 hash of the
canonical artifact file, expressed as a 128-character uppercase
hexadecimal string. This field was not present in version 1.0
tokens.
hashes.blake3 (REQUIRED for v2.0): The BLAKE3 hash of the
canonical artifact file, expressed as a 64-character uppercase
hexadecimal string. This field was not present in version 1.0
tokens.
blockchain.blockHeight (REQUIRED): The Bitcoin block height at
which the OpenTimestamps proof was confirmed. This provides a
minimum-age bound for the anchored hash.
blockchain.proofUrl (REQUIRED): A dereferenceable URL at which the
.ots proof file can be retrieved for independent verification.
doi.identifier (REQUIRED): The DOI string for the Zenodo archival
record. Format: 10.XXXX/zenodo.XXXXXXXX.
ipfs.cid (OPTIONAL): The IPFS Content Identifier for the artifact
or archival package. When present, the artifact MUST be
retrievable via at least one IPFS gateway using this CID.
tokenState (REQUIRED): The current lifecycle state of this token.
See Section 8.1 for state definitions.
ecosystem.protocol (REQUIRED): MUST be "REM" for all conforming
RLT tokens.
ecosystem.protocolDraft (REQUIRED): The IETF Internet-Draft name
for the REM Protocol specification governing this token.
Reilly Expires 10 March 2027 [Page 23]
Internet-Draft REM License Token (RLT) September 2026
5.3. Backward Compatibility with Version 1.0
Version 1.0 tokens conforming to draft-reilly-rlt-genesis-00 are
considered valid genesis records. Implementations that encounter a
version 1.0 token SHOULD treat missing sha3_512 and blake3 fields
as uncomputed rather than as verification failures, provided the
sha256 field is present and verifiable against the blockchain proof
and DOI record.
Version 1.0 tokens SHOULD NOT be issued for new artifacts. New
issuances MUST use version 2.0 or a later schema.
Token upgrading (adding SHA3-512 and BLAKE3 hashes to an existing
version 1.0 token) is permitted by creating a new version 2.0 token
with predecessorToken referencing the original version 1.0 token ID,
tokenState set to "ACTIVE", and all new hash fields populated. The
original version 1.0 token's tokenState SHOULD be updated to
"SUPERSEDED" with a successorToken reference.
5.4. Token Schema Version 2.1
Version 2.1 is a minor version increment as defined by
Section 10.1. It adds OPTIONAL fields only. Every version 2.0
token is a valid version 2.1 token with all 2.1 additions omitted,
and a version 2.1 token that omits every addition is
indistinguishable from a version 2.0 token except for the
rltVersion string. A verifier that does not implement version 2.1
MUST ignore fields it does not recognize rather than treat them as
errors.
A version 2.1 token sets rltVersion to "2.1" and schemaDate to
"2026-09-06" or later, and MAY carry the following additional
top-level members.
{
"rltVersion": "2.1",
"schemaDate": "2026-09-06",
"remMas": {
"suite": "A", // OPTIONAL, A | B | C | D
"algorithms": ["SHA-256", "SHA3-512", "BLAKE3"]
},
"anchorScope": { // RECOMMENDED for v2.1
"coveredFile": "<canonical filename>",
"byteLength": <integer>,
"coverage": "single-file" // single-file | manifest
},
Reilly Expires 10 March 2027 [Page 24]
Internet-Draft REM License Token (RLT) September 2026
"canonicalization": { // RECOMMENDED for v2.1
"profile": "RLT-JCS-1",
"recordDigestAlg": "SHA-256"
},
"recordDigest": "<64-char hex string>", // RECOMMENDED for v2.1
"commitments": { // OPTIONAL
"alg": "SHA-256",
"fields": {
"<json-pointer>": "<64-char hex commitment>"
}
},
"batchAnchor": { // OPTIONAL
"merkleRoot": "<64-char hex string>",
"leafIndex": <integer>,
"treeSize": <integer>,
"inclusionProof": ["<64-char hex string>"],
"proofUrl": "<URL to the batch proof>"
},
"anchorState": "ATTESTED", // RECOMMENDED, PENDING |
// ATTESTED
"bridging": [ // OPTIONAL
{
"fromAlg": "<algorithm name>",
"toAlg": "<algorithm name>",
"fromValue": "<hex string>",
"toValue": "<hex string>",
"bridgedAt": "<ISO 8601 date>",
"bridgeAnchor": "<URL or DOI of the bridging anchor>"
}
],
"status": { // OPTIONAL
"statusUrl": "<URL of the status record>",
"registry": "<URL of the revocation registry>"
},
"priorArt": { // OPTIONAL
"mode": "public-deposit", // public-deposit | existence-
// only
"publiclyAccessibleAt": "<ISO 8601 date>",
"depositUrl": "<URL of the open-access deposit>"
},
Reilly Expires 10 March 2027 [Page 25]
Internet-Draft REM License Token (RLT) September 2026
"conformance": "C2" // OPTIONAL, C0 through C4
}
Field semantics:
remMas.suite (OPTIONAL): The REM-MAS algorithm suite under which
the token was issued, as defined in Appendix C. Appendix C of
-01 anticipated this field; version 2.1 provides it.
anchorScope (RECOMMENDED): Makes the anchor scope rule of
Section 4.4 explicit and machine-checkable. coveredFile MUST
equal artifact.filename. byteLength is the length in octets of
the covered file at the time the hashes were computed. coverage
is "single-file" when the hashes cover the artifact directly and
"manifest" when the artifact is a manifest listing further files
with their own hash sets.
canonicalization (RECOMMENDED): Names the canonicalization profile
and digest algorithm used to compute recordDigest. The only
profile defined by this document is "RLT-JCS-1" (Section 5.5).
recordDigest (RECOMMENDED): The digest of the token's canonical
form (Section 5.5).
commitments (OPTIONAL): Salted field commitments (Section 5.6).
Keys are JSON Pointers into the token object identifying the
committed fields.
batchAnchor (OPTIONAL): Present when the blockchain anchor covers
a Merkle root rather than the artifact hash directly
(Section 6.9). When batchAnchor is present, blockchain.proofFile
and blockchain.proofUrl refer to the proof over merkleRoot.
anchorState (RECOMMENDED): "PENDING" or "ATTESTED" as defined in
Section 6.10. A token whose anchorState is PENDING MUST NOT
assert a blockHeight value, and MUST NOT be presented as
evidence of a confirmed anchor date.
bridging (OPTIONAL): Zero or more hash migration bridging records
(Section 6.11), in chronological order.
status (OPTIONAL): Locations at which the token's current
lifecycle state may be retrieved (Section 8.7).
priorArt (OPTIONAL): Records whether the token is operating as a
Prior Art Record (Section 4.5). mode "existence-only" indicates
that the artifact was anchored but not publicly deposited, and
therefore does not constitute a Prior Art Record.
Reilly Expires 10 March 2027 [Page 26]
Internet-Draft REM License Token (RLT) September 2026
conformance (OPTIONAL): The conformance level the issuer claims,
as defined in Section 7.7. A verifier MUST determine the level
independently and MUST NOT rely on this field.
5.5. Canonical Form and Record Digest
A version 2.0 token has no integrity value of its own. Its hashes
cover the artifact, not the token, so an alteration to the token's
own metadata, for example to the author name, the DOI, or the
licence, is not detectable from the token alone. Version 2.1
closes this gap.
The canonicalization profile "RLT-JCS-1" is defined as follows:
1. Take the token as a JSON value.
2. Remove the members recordDigest and signature, wherever they
appear at the top level of the token object. Remove no other
member.
3. Serialize the resulting value using JSON Canonicalization
Scheme [RFC8785].
4. The resulting octet string is the canonical form.
The record digest is the SHA-256 digest of the canonical form,
expressed as a 64-character lowercase hexadecimal string, and is
recorded in recordDigest. Issuers MUST compute the record digest
as the last step of token assembly, after every other field has its
final value.
Verifiers recompute the canonical form and its digest and compare
against recordDigest. A mismatch MUST be reported as
RECORD_DIGEST_MISMATCH (Section 7.8). A record digest mismatch
indicates that the token has been altered since issuance; it does
not by itself impugn the artifact, whose integrity is established
independently by Section 7.1.
All dates and date-times in a version 2.1 token MUST conform to
[RFC3339]. Date-only fields use the full-date production;
date-time fields use the date-time production with an explicit UTC
offset. tokenId values MUST conform to [RFC9562]. These
constraints exist so that canonicalization is deterministic across
implementations.
Reilly Expires 10 March 2027 [Page 27]
Internet-Draft REM License Token (RLT) September 2026
5.6. Field Commitments and Selective Disclosure
An issuer may need to publish a token while withholding a specific
value, for example an unpublished artifact title, a contact
address, or a customer name, without losing the ability to prove
that value later.
For each withheld field the issuer:
1. Generates a fresh salt of at least 128 bits from a
cryptographically secure random source. A salt MUST NOT be
reused across fields or across tokens.
2. Computes the commitment as the digest, under the algorithm
named in commitments.alg, of the concatenation of the salt, a
single 0x00 octet, and the UTF-8 encoding of the JCS
serialization of the field value.
3. Records the commitment in commitments.fields under the JSON
Pointer identifying the field, and replaces the field's value
in the published token with the JSON value null.
4. Retains the salt and the value privately.
Selective disclosure is performed by transmitting the field value
and its salt to a verifier out of band. The verifier recomputes
the commitment and compares it with the published value. A
mismatch MUST be reported as COMMITMENT_MISMATCH (Section 7.8).
Commitments are covered by the record digest, since they are
ordinary token members. A token that carries commitments therefore
cannot have a commitment silently substituted without also
invalidating recordDigest, provided the token is signed
(Section 5.7) or the record digest is itself anchored.
Commitments MUST NOT be used for the members of the hashes object,
for blockchain.blockHeight, for doi.identifier, or for tokenState.
Those values are the substance of the provenance claim and a token
that withholds them is not verifiable.
5.7. Token Signature Profile
The signature object of version 2.0 is unstructured. Version 2.1
defines a profile for it so that signatures are interoperable.
A signed version 2.1 token sets:
signature.type to "COSE_Sign1"
Reilly Expires 10 March 2027 [Page 28]
Internet-Draft REM License Token (RLT) September 2026
signature.value to the base64url encoding, without padding, of
a COSE_Sign1 structure [RFC9052] serialized as CBOR [RFC8949]
signature.keyId to a URI at which the corresponding public key
is published
The COSE_Sign1 payload MUST be the canonical form defined in
Section 5.5, and the protected header MUST include the algorithm
identifier. The signature is therefore over the whole token except
recordDigest and signature itself, which makes recordDigest a
convenience value rather than a security-bearing one: a verifier
that checks the signature has no need to trust recordDigest.
Implementations requiring long-term security SHOULD use a
post-quantum algorithm, for example SPHINCS+ as standardized in
[FIPS205] and listed as REM-MAS Suite C in Appendix C. Ed25519 is
acceptable where the token's evidentiary horizon is short.
A signature does not extend the security of the anchor. A token
signature proves who assembled the token; the blockchain anchor
proves when the artifact existed. Neither substitutes for the
other.
6. Issuance and Anchoring Requirements
The RLT issuance process MUST be completed in the order specified
below. Steps that are declared REQUIRED in this section MUST be
completed before a token is considered conforming. Steps declared
RECOMMENDED SHOULD be completed. Steps declared OPTIONAL MAY be
omitted at the issuer's discretion.
6.1. Pre-Issuance Preparation
Before beginning the issuance process, the issuer MUST:
1. Produce a stable, finalized version of the artifact to be
anchored. The artifact MUST NOT be modified after hash
computation begins. Any modification, including whitespace
changes or metadata updates, will invalidate the computed hashes
and require a new issuance.
2. Assign the artifact a canonical filename that uniquely identifies
the artifact and its version. The filename SHOULD include the
author's name, a brief title, and a version indicator.
3. Confirm that the artifact is in a format suitable for long-term
archival. PDF/A, plain text (.txt), and XML formats are
RECOMMENDED. Proprietary binary formats SHOULD be avoided.
Reilly Expires 10 March 2027 [Page 29]
Internet-Draft REM License Token (RLT) September 2026
4. Prepare the artifact metadata including title, abstract, author
information, and license declaration.
6.2. Multi-Algorithm Hash Computation
The issuer MUST compute cryptographic hashes of the canonical
artifact file using the following algorithms in the specified order:
1. SHA-256 (REQUIRED): Compute the SHA-256 hash of the artifact
file. The output MUST be expressed as a 64-character uppercase
hexadecimal string.
sha256sum <artifact_filename>
2. SHA3-512 (REQUIRED for v2.0): Compute the SHA3-512 hash of the
artifact file. The output MUST be expressed as a 128-character
uppercase hexadecimal string.
openssl dgst -sha3-512 <artifact_filename>
3. BLAKE3 (REQUIRED for v2.0): Compute the BLAKE3 hash of the
artifact file. The output MUST be expressed as a 64-character
uppercase hexadecimal string.
b3sum <artifact_filename>
The issuer MUST record all three hash values in a hash manifest
file prior to proceeding to the OpenTimestamps step. The hash
manifest SHOULD be a plain text file co-archival with the artifact.
All three hash values MUST be independently re-verifiable from the
artifact file alone. Any discrepancy between recorded values and
values computed from the artifact indicates tampering or file
corruption.
6.3. OpenTimestamps Anchoring
The issuer MUST obtain an OpenTimestamps proof anchored to the
Bitcoin blockchain:
1. Submit the canonical artifact to the OpenTimestamps client:
ots stamp <artifact_filename>
This produces a .ots proof file.
Reilly Expires 10 March 2027 [Page 30]
Internet-Draft REM License Token (RLT) September 2026
2. Wait for Bitcoin block confirmation. The OpenTimestamps proof
is complete when the Merkle inclusion path is confirmed to a
Bitcoin block. This typically requires one or more Bitcoin block
confirmations (approximately 10 minutes per block).
3. Upgrade and verify the OTS proof:
ots upgrade <artifact_filename>.ots
ots verify <artifact_filename>.ots
4. Record the Bitcoin block height from the verified OTS proof.
This block height is the normative blockchain anchor for the
token.
The .ots proof file MUST be preserved and archived alongside the
artifact in all subsequent archival steps.
6.4. DOI Archival via Zenodo
The issuer MUST archive the artifact package on Zenodo to obtain
a persistent DOI:
1. Create a new Zenodo upload record.
2. Upload the following files as a package:
a. The canonical artifact file.
b. The .ots proof file.
c. The hash manifest file (SHA-256, SHA3-512, BLAKE3 values).
3. Complete the Zenodo metadata form including:
a. Title matching the artifact title.
b. Author name, affiliation, and ORCID if available.
c. License declaration.
d. Description referencing the REM Protocol and blockchain
anchor block height.
e. Keywords including "REM Protocol", "RLT", "digital
permanence", "blockchain timestamp", and subject-specific
terms.
4. Publish the Zenodo record to obtain the DOI.
5. Record the DOI string (format: 10.5281/zenodo.XXXXXXXX) and
the Zenodo record URL.
The Zenodo record is the normative archival source for the token.
The DOI MUST resolve to the Zenodo record at time of issuance and
is intended to remain resolvable permanently.
Reilly Expires 10 March 2027 [Page 31]
Internet-Draft REM License Token (RLT) September 2026
6.5. IPFS Pinning
Issuers SHOULD pin the artifact package to the IPFS network:
1. Add the artifact package directory to IPFS:
ipfs add -r <artifact_directory>
2. Record the root CID returned by the ipfs add command.
3. Pin the CID to a persistent IPFS pinning service such as
Pinata, web3.storage, or a self-operated IPFS node.
4. Verify retrievability via a public IPFS gateway:
curl https://ipfs.io/ipfs/<CID>
5. Record the CID and gateway URL in the token.
IPFS pinning provides decentralized content-addressed availability
independent of the Zenodo archive and adds a third permanence layer
to the Dual-Layer Digital Permanence record.
6.6. Web Archival
Issuers SHOULD submit the DOI landing page and any associated
public URLs to the Internet Archive Wayback Machine:
1. Submit the Zenodo record URL to:
https://web.archive.org/save/<zenodo_record_url>
2. Submit the IETF Datatracker draft URL if applicable.
3. Record the resulting Wayback Machine snapshot URLs and snapshot
dates.
4. Include the Wayback Machine URL in the token's webArchival
field.
6.7. REMID Namespace Registration
Issuers MAY register a REMID namespace identifier for the artifact:
1. Choose a REMID identifier string following the format:
rem:<author-handle>:<artifact-short-name>:<version>
2. Register the REMID in the REM Protocol namespace registry.
Reilly Expires 10 March 2027 [Page 32]
Internet-Draft REM License Token (RLT) September 2026
3. Record the assigned REMID and registration date in the token's
remid field.
REMID registration provides a human-readable, persistent identifier
for the artifact within the REM Protocol ecosystem.
6.8. Token Assembly and Publication
After completing all required anchoring steps, the issuer MUST
assemble the RLT JSON token:
1. Assign a UUID v4 token identifier.
2. Populate all REQUIRED fields as defined in Section 5.1.
3. Populate all available OPTIONAL fields corresponding to
completed anchoring steps.
4. Set tokenState to "ACTIVE".
5. Set predecessorToken to null for new issuances.
6. Publish the JSON token file alongside the artifact, OTS proof,
and hash manifest in the Zenodo record.
7. Update the Zenodo record with the completed token if necessary.
The assembled RLT token MUST be verifiable by any party following
the procedures defined in Section 7.
Issuers of version 2.1 tokens perform two further steps after step
5 and before publication:
8. Compute any field commitments (Section 5.6) and null the
corresponding published values.
9. Compute the canonical form and record digest (Section 5.5),
and, if the token is to be signed, produce the COSE_Sign1
signature over that canonical form (Section 5.7).
6.9. Batch Issuance and Merkle Aggregation
An issuer anchoring many artifacts pays one Bitcoin confirmation
delay per artifact if each is stamped separately. Batch issuance
removes that cost without weakening the anchor.
The issuer:
Reilly Expires 10 March 2027 [Page 33]
Internet-Draft REM License Token (RLT) September 2026
1. Collects the SHA-256 hashes of the artifacts to be anchored in
the batch, in a fixed order.
2. Constructs a Merkle tree over those hashes using the leaf and
interior node hashing rules of [RFC6962], which prefix leaf
inputs with 0x00 and interior node inputs with 0x01. The
domain separation is not optional: a tree built without it
admits second-preimage attacks in which an interior node is
presented as a leaf.
3. Obtains a single OpenTimestamps proof over the Merkle root.
4. For each artifact, records in its token the merkleRoot, the
leafIndex, the treeSize, and the inclusionProof audit path, in
the batchAnchor object of Section 5.4.
5. Publishes the batch proof at batchAnchor.proofUrl so that the
audit path can be re-derived independently.
Where the log grows incrementally and a verifier holds an earlier
root, consistency between roots is proved by the constructions of
[RFC6962]; bulk subtree proofs [SUBTREE] give a more compact form
for the case of many appended entries.
A batch anchor establishes the same date bound for every artifact
in the batch: the confirmation time of the single anchoring block.
Issuers MUST NOT record differing blockchainAnchor dates for
artifacts sharing one batch anchor.
6.10. Pending and Attested Anchor States
OpenTimestamps returns a calendar attestation within seconds and a
Bitcoin block attestation after confirmation. These are not
equivalent and a token MUST distinguish them.
PENDING: A calendar attestation exists. The calendar operator
asserts that the hash was submitted at a stated time, but no
independent public ledger has yet confirmed it. A PENDING
anchor rests on trust in the calendar operator.
ATTESTED: The proof has been upgraded and verified against a
Bitcoin block, and the block height has been recorded. The date
bound no longer depends on any operator.
Requirements:
o A version 2.1 token SHOULD record anchorState.
Reilly Expires 10 March 2027 [Page 34]
Internet-Draft REM License Token (RLT) September 2026
o A token with anchorState "PENDING" MUST omit
blockchain.blockHeight or set it to null, and MUST NOT be
published as a completed provenance record.
o An issuer MUST upgrade a PENDING anchor to ATTESTED once
confirmation is available, and MUST reissue or renew the token
with the confirmed block height.
o A verifier encountering a PENDING anchor MUST report
ANCHOR_PENDING (Section 7.8) and MUST NOT report VALID.
Six confirmations are RECOMMENDED before an anchor is treated as
ATTESTED, consistent with Section 11.2.
6.11. Hash Migration and Bridging Records
Hash algorithms are retired. An artifact anchored in 2025 under
SHA-256 may need, decades later, to be verifiable to a party that
no longer accepts SHA-256 evidence. Re-anchoring the artifact
under a new algorithm produces a new, later date, which destroys
the evidentiary value of the original anchor. A bridging record
preserves it.
To bridge an artifact from algorithm X to algorithm Y:
1. Retrieve the artifact from its archival source and confirm that
it still hashes to the recorded value under X.
2. Compute the artifact's hash under Y.
3. Construct a bridging document containing: the artifact
filename and byte length; the value under X; the value under Y;
a reference to the original anchor, including its block height;
and the date of bridging.
4. Anchor the bridging document itself under the full issuance
procedure of this section, using algorithm Y.
5. Record the resulting entry in the token's bridging array
(Section 5.4), with bridgeAnchor pointing at the bridging
document's own anchor.
The chain of evidence is then: the original anchor binds X to a
2025 date; the bridging document binds X to Y and is itself
anchored at a later date under Y. A verifier who trusts Y but not
X learns that the artifact hashing to Y today is the same artifact
that hashed to X in 2025, unless X was already broken at the time
of bridging.
Reilly Expires 10 March 2027 [Page 35]
Internet-Draft REM License Token (RLT) September 2026
Bridging MUST be performed while the outgoing algorithm is still
considered sound. A bridging record created after the outgoing
algorithm has been broken proves nothing, since an adversary able
to find collisions under X could have substituted the artifact
before step 2. Issuers SHOULD bridge proactively rather than in
response to a break.
7. Verification Requirements
Any party MAY verify an RLT token. Verification MUST NOT require
trust in the token issuer; all evidence MUST be independently
retrievable from public sources. The verification process consists
of five independent checks, all of which MUST pass for the token to
be considered VALID.
7.1. Hash Verification
The verifier MUST:
1. Retrieve the canonical artifact file from the DOI record or
IPFS CID.
2. Compute SHA-256 over the retrieved file.
3. Compare the computed SHA-256 against the hashes.sha256 field
in the token. The values MUST match exactly (case-insensitive
hexadecimal comparison).
4. For version 2.0 tokens: Compute SHA3-512 and BLAKE3 over the
retrieved file and compare against hashes.sha3_512 and
hashes.blake3 respectively.
5. If any hash comparison fails, the verification MUST be recorded
as HASH_MISMATCH and the token MUST NOT be considered VALID.
A token is considered hash-verified if and only if all present hash
fields match the computed values.
7.2. Blockchain Proof Verification
The verifier MUST:
1. Retrieve the .ots proof file from the URL specified in
blockchain.proofUrl or from the DOI archival record.
2. Run the OpenTimestamps verification tool:
ots verify <artifact_filename>.ots
Reilly Expires 10 March 2027 [Page 36]
Internet-Draft REM License Token (RLT) September 2026
3. Confirm that the verification output references a Bitcoin block
height matching or preceding the blockchain.blockHeight value
in the token.
4. If OTS verification fails, the verification MUST be recorded as
OTS_VERIFICATION_FAILED.
5. If the confirmed block height does not match the token's recorded
block height, the verification MUST be recorded as
BLOCK_HEIGHT_MISMATCH.
7.3. DOI Archival Verification
The verifier MUST:
1. Resolve the DOI identifier from doi.identifier using the
standard DOI resolver (https://doi.org/<doi_identifier>).
2. Confirm that the DOI resolves to a publicly accessible record.
3. Confirm that the record metadata includes the artifact title and
author name matching the token's artifact and author fields.
4. Confirm that the artifact file and OTS proof file are present
in the DOI record.
5. If the DOI does not resolve, the verification MUST be recorded
as DOI_UNRESOLVABLE.
7.4. IPFS Availability Verification
If the token includes an ipfs.cid field, the verifier SHOULD:
1. Attempt to retrieve the artifact via the specified IPFS gateway
or any public IPFS gateway using the recorded CID.
2. Verify that the retrieved content matches the hash values in
the token's hashes fields.
3. Record IPFS availability as IPFS_AVAILABLE or IPFS_UNAVAILABLE.
IPFS unavailability does not constitute a token validity failure
but SHOULD be noted in the verification report.
7.5. Token Integrity Verification
The verifier MUST:
1. Confirm that the token JSON is syntactically valid.
Reilly Expires 10 March 2027 [Page 37]
Internet-Draft REM License Token (RLT) September 2026
2. Confirm that all REQUIRED fields are present and non-null.
3. Confirm that tokenState is a recognized value per Section 8.1.
4. If tokenState is "REVOKED" or "SUPERSEDED", the verifier MUST
note this in the verification result. A REVOKED or SUPERSEDED
token is not necessarily fraudulent but indicates that the
issuer has updated the token's status.
5. If predecessorToken or successorToken fields are present and
non-null, the verifier SHOULD retrieve and verify the referenced
tokens to establish the full token chain.
7.6. Verification Result Codes
Implementations SHOULD report verification using the following
standardized result codes:
VALID: All required verification steps passed.
HASH_MISMATCH: One or more hash values do not match the
artifact file.
OTS_VERIFICATION_FAILED: The OpenTimestamps proof does not
verify against the Bitcoin blockchain.
BLOCK_HEIGHT_MISMATCH: The verified OTS block height does not
match the token's recorded blockHeight.
DOI_UNRESOLVABLE: The DOI does not resolve to an accessible
record.
ARTIFACT_UNAVAILABLE: The artifact file cannot be retrieved
from any listed source.
TOKEN_MALFORMED: The token JSON is syntactically invalid or
missing required fields.
IPFS_UNAVAILABLE: The IPFS CID is not retrievable (non-fatal
if other sources are available).
STATE_REVOKED: The token is valid but has been revoked by the
issuer.
STATE_SUPERSEDED: The token is valid but has been superseded by
a newer token referenced in successorToken.
Reilly Expires 10 March 2027 [Page 38]
Internet-Draft REM License Token (RLT) September 2026
7.7. Conformance Levels
The -01 specification defines a single binary outcome. In practice
a token may be sound but incomplete, and a verifier needs to say so
precisely. This subsection defines five cumulative levels. A
token attains a level only if it attains every lower level.
C0 (Well-formed): The token parses, carries a recognized
rltVersion, and has all REQUIRED fields for that version present
and non-null. No external retrieval is performed.
C1 (Anchored): C0, and the artifact is retrievable, its SHA-256
matches, and the OpenTimestamps proof verifies to a Bitcoin
block at or before the recorded blockHeight with anchorState
ATTESTED or absent.
C2 (Dual-layer): C1, and the DOI resolves to a public record whose
metadata matches the token, and the artifact file and proof file
are present in that record. C2 is the level at which a token
realizes the Dual-Layer Digital Permanence claim.
C3 (Multi-algorithm and multi-layer): C2, and all three REM-MAS
hashes match, and at least one further permanence layer, IPFS or
web archival, is present and retrievable.
C4 (Self-integral): C3, and the token carries a canonicalization
profile and record digest that verify, and a signature that
verifies against a retrievable public key, and, where an
anchorScope object is present, the recorded byte length matches
the retrieved artifact.
Verifiers SHOULD report the highest level attained together with
the reason the next level was not attained. A conformance level is
a statement about evidence available at verification time; a token
may attain C3 today and C2 tomorrow if an IPFS pin lapses, without
any change to the token.
7.8. Additional Verification Result Codes
The following result codes are added by this revision. They
supplement, and do not replace, the codes of Section 7.6.
ANCHOR_PENDING: The token's anchorState is PENDING, so no
confirmed block anchors the artifact (Section 6.10).
Reilly Expires 10 March 2027 [Page 39]
Internet-Draft REM License Token (RLT) September 2026
ANCHOR_SCOPE_ERROR: The anchorScope object is inconsistent with
the artifact or with the proof, for example a recorded byte
length that does not match the retrieved file, or a
coveredFile that differs from artifact.filename
(Section 4.4).
RECORD_DIGEST_MISMATCH: The recomputed record digest does not
match recordDigest (Section 5.5).
SIGNATURE_INVALID: The COSE_Sign1 signature does not verify over
the canonical form (Section 5.7).
SIGNATURE_KEY_UNAVAILABLE: The public key identified by
signature.keyId could not be retrieved. Non-fatal; the
verifier reports the highest level not requiring the
signature.
COMMITMENT_MISMATCH: A disclosed field value and salt do not
reproduce the published commitment (Section 5.6).
BATCH_PROOF_INVALID: The Merkle inclusion proof does not connect
the artifact hash to the anchored root (Section 6.9).
BRIDGE_INVALID: A bridging record's own anchor does not verify,
or the recorded outgoing value does not match the token
(Section 6.11).
STATUS_UNAVAILABLE: A status URL is present but could not be
retrieved. Non-fatal; the verifier reports the state
recorded in the token and notes that it may be stale.
7.9. Verification of Batch-Anchored Tokens
Where batchAnchor is present, step 2 of Section 7.2 is replaced by
the following:
1. Compute the artifact's SHA-256 hash as in Section 7.1.
2. Using leafIndex, treeSize, and inclusionProof, recompute the
Merkle root under the [RFC6962] hashing rules.
3. Compare the recomputed root with batchAnchor.merkleRoot. A
mismatch MUST be reported as BATCH_PROOF_INVALID.
4. Verify the OpenTimestamps proof over merkleRoot as in
Section 7.2, treating the root as the timestamped value.
Reilly Expires 10 March 2027 [Page 40]
Internet-Draft REM License Token (RLT) September 2026
A verifier MUST NOT accept an inclusion proof whose length is
inconsistent with treeSize, and MUST reject a proof in which any
supplied node equals the computed leaf, which is the signature of
an attempted second-preimage substitution.
7.10. Verification of Signed Tokens and Commitments
Where signature.type is "COSE_Sign1", the verifier:
1. Retrieves the public key from signature.keyId. If retrieval
fails, reports SIGNATURE_KEY_UNAVAILABLE and continues.
2. Recomputes the canonical form per Section 5.5.
3. Verifies the COSE_Sign1 structure over that canonical form. A
failure MUST be reported as SIGNATURE_INVALID, and the token
MUST NOT attain C4.
Where a field value and salt have been disclosed, the verifier
recomputes the commitment per Section 5.6 and compares it with the
published value in commitments.fields, reporting
COMMITMENT_MISMATCH on failure.
A verifier MUST NOT treat the absence of a signature as a failure.
An unsigned token is simply one that cannot attain C4.
8. Token Lifecycle Management
8.1. Token States
Every RLT token MUST have a tokenState field with one of the
following values:
ACTIVE: The token is current, valid, and in its primary issuance
state. No lifecycle event has modified the token since issuance.
RENEWED: The token has been renewed by the issuer to extend its
active period or update non-hash metadata. The token remains
valid and its provenance record is unchanged.
SUPERSEDED: The token has been replaced by a newer token referenced
in the successorToken field. The superseded token remains valid
as a historical provenance record but should not be treated as
the authoritative current record for the artifact.
Reilly Expires 10 March 2027 [Page 41]
Internet-Draft REM License Token (RLT) September 2026
REVOKED: The issuer has revoked the token. Revocation does not
erase the blockchain or DOI records (which are permanent) but
signals that the issuer no longer endorses this token as a valid
provenance record. Verifiers SHOULD investigate the reason for
revocation before relying on a REVOKED token.
ARCHIVED: The artifact has been intentionally retired from active
use, but the provenance record is preserved for historical
reference. An ARCHIVED token remains verifiable indefinitely.
8.2. Token Renewal
Token renewal is appropriate when:
o The issuer wishes to add previously missing optional fields
(e.g., adding IPFS and REMID fields to a token that was issued
before those layers were applied).
o The issuer has updated contact information or ORCID.
o The artifact has been reformatted without content change (e.g.,
converting from PDF to PDF/A).
Renewal procedure:
1. Issue a new version 2.0 token with a new UUID.
2. Recompute all hash values if the artifact file has changed.
If only metadata has changed and the artifact file is identical,
the original hash values are carried forward.
3. Set predecessorToken to the UUID of the original token.
4. Set tokenState to "RENEWED" if the original token is being
continued, or "ACTIVE" if this is a distinct new record.
5. Update the original token's tokenState to "SUPERSEDED" and
set successorToken to the UUID of the new token.
8.3. Token Succession
Token succession occurs when an artifact is formally updated and
a new anchoring is performed:
1. Produce the updated artifact.
Reilly Expires 10 March 2027 [Page 42]
Internet-Draft REM License Token (RLT) September 2026
2. Complete the full issuance procedure (Section 6) for the
updated artifact, generating a new blockchain anchor, new DOI,
and new hash values.
3. Issue a new version 2.0 token for the updated artifact with
predecessorToken referencing the previous token's UUID.
4. Set the previous token's tokenState to "SUPERSEDED" and set
its successorToken to the new token's UUID.
Token succession chains SHOULD be traversable via the
predecessorToken and successorToken fields, enabling verifiers to
reconstruct the complete provenance history of an artifact across
multiple versions.
8.4. Token Revocation
Token revocation is appropriate when:
o The artifact was erroneously anchored to incorrect content.
o The anchor metadata (author, title, dates) contains material
errors that cannot be corrected by renewal.
o Legal or compliance requirements necessitate withdrawal.
Revocation procedure:
1. Update the token's tokenState to "REVOKED".
2. Publish an updated copy of the token with the revocation state
to the same publication channels used for the original token.
3. If possible, update the Zenodo record to note the revocation.
Note: Revocation does NOT erase the Bitcoin blockchain timestamp
or DOI record. These are permanent. Revocation only signals the
issuer's withdrawal of endorsement. The original provenance
evidence remains accessible and independently verifiable regardless
of the token's revocation state.
8.5. Token Archival
Tokens MAY be transitioned to ARCHIVED state when:
o The artifact has completed its active lifecycle and is no longer
being actively referenced or updated.
Reilly Expires 10 March 2027 [Page 43]
Internet-Draft REM License Token (RLT) September 2026
o The issuer wishes to signal that the artifact is a historical
record rather than an actively maintained document.
Archived tokens remain fully verifiable and SHOULD be preserved
indefinitely.
8.6. Token State Transition Rules
Sections 8.1 through 8.5 describe the states and the events that
reach them. This subsection states which transitions are permitted,
so that an implementation can reject an inconsistent history. The
full matrix appears in Appendix H.
The rules are:
o ACTIVE is the only initial state. A token MUST NOT be first
published in any other state.
o ACTIVE MAY move to RENEWED, SUPERSEDED, REVOKED, or ARCHIVED.
o RENEWED MAY move to SUPERSEDED, REVOKED, or ARCHIVED.
o ARCHIVED MAY move to REVOKED only. An archived token is not
reactivated; a renewed interest in the artifact is expressed by
issuing a successor.
o SUPERSEDED MAY move to REVOKED only.
o REVOKED is terminal. A token MUST NOT leave REVOKED. If an
issuer revokes in error, the remedy is to issue a new token, not
to un-revoke.
o Whenever a token enters SUPERSEDED, successorToken MUST be set
and MUST reference a token whose predecessorToken references
this token. A one-sided link is a malformed chain and a
verifier SHOULD report TOKEN_MALFORMED.
o A successor MUST NOT be issued with a blockchainAnchor date
earlier than that of its predecessor. A chain whose dates run
backwards is evidence of error or fabrication.
Every transition changes the token's bytes and therefore its record
digest. An issuer of version 2.1 tokens MUST recompute
recordDigest and, where present, the signature on every transition.
Reilly Expires 10 March 2027 [Page 44]
Internet-Draft REM License Token (RLT) September 2026
8.7. Status Records and the Revocation Registry
A verifier who holds a copy of a token has no way to learn that its
state has since changed, because the copy it holds still says
ACTIVE. Republication of the full token does not solve this: the
verifier does not know to look. A status record does.
A status record is a small JSON object published at a stable URL
recorded in the token's status.statusUrl:
{
"tokenId": "<uuid>",
"tokenState": "REVOKED",
"asOf": "2026-09-06T00:00:00Z",
"successorToken": "<uuid or null>",
"reason": "<short free-text reason or null>",
"recordDigest": "<digest of the token this status describes>"
}
Requirements:
o The status URL, if published, MUST remain resolvable for as long
as the token is relied upon, and MUST be stable across state
changes.
o A status record MUST carry the recordDigest of the token version
it describes, so that a verifier can tell whether the status
applies to the copy it holds.
o A verifier SHOULD fetch the status record before reporting a
result, and MUST prefer the status record's state over the state
embedded in its copy of the token when the recordDigest values
agree.
o If the status URL is unreachable, the verifier reports
STATUS_UNAVAILABLE (Section 7.8) and falls back to the embedded
state, noting that it may be stale.
An issuer operating many tokens MAY additionally publish a
revocation registry at status.registry: a single document listing
the tokenId and state of every token the issuer has revoked or
superseded. A registry is a convenience for bulk checking; it does
not replace per-token status records, and a token absent from the
registry MUST NOT be inferred to be ACTIVE, since absence is
indistinguishable from an incomplete registry.
Reilly Expires 10 March 2027 [Page 45]
Internet-Draft REM License Token (RLT) September 2026
Neither mechanism can erase evidence. The blockchain anchor and
the DOI deposit remain, and a revoked token remains verifiable as
the historical record of what was claimed and when.
9. Ecosystem Integration
9.1. Integration with PLPES
The Protocol Layer Prompt Engineering Specification
(draft-reilly-plpes-00), authored by Lawrence John Reilly Jr.,
formally defines Protocol Layer Prompt Engineering as a discipline
and specifies structured methodologies for constructing AI prompts
that achieve deterministic, verifiable, and provenance-anchored
outputs.
The RLT integrates with PLPES as follows:
o PLPES-governed prompt packages MAY include an embedded RLT or
RLT reference to establish the provenance and authorship of the
prompt engineering specification.
o AI systems that consume PLPES-compliant prompt packages SHOULD
verify the embedded RLT before executing prompted procedures.
o RLT tokens anchoring PLPES-related artifacts SHOULD include
"draft-reilly-plpes-00" in the ecosystem.affiliatedDrafts array.
9.2. Integration with CTS
The Cognitive Trust Stack (draft-reilly-cts-00) defines a layered
trust architecture for AI reasoning systems. The CTS is itself
anchored using the Dual-Layer Digital Permanence methodology, with
a Zenodo DOI and Bitcoin blockchain timestamp.
The RLT integrates with CTS as follows:
o The CTS Trust Layer 1 (Provenance) relies on the RLT model as
the canonical mechanism for establishing artifact provenance
within the CTS trust hierarchy.
o Artifacts that participate in a CTS trust chain SHOULD carry an
RLT to establish their provenance at the entry point of the
chain.
o The CTS verification process MAY include RLT verification as a
required step before elevating an artifact's trust score.
Reilly Expires 10 March 2027 [Page 46]
Internet-Draft REM License Token (RLT) September 2026
9.3. Integration with AIMED and AIMED-EVAL
The AI Machine-Readable Ethics Directive (draft-reilly-aimed-00)
and its evaluation framework (draft-reilly-aimed-eval-00) define
machine-readable ethics specifications and compliance evaluation
methodologies for AI systems.
The RLT integrates with AIMED as follows:
o AIMED directive documents SHOULD be anchored with an RLT to
establish their provenance and prevent undetected modification.
o AIMED-EVAL compliance reports SHOULD reference the RLT of the
AIMED directive being evaluated.
o AI systems that consume AIMED directives SHOULD verify the
directive's RLT before applying ethics constraints, ensuring
that the ethics directive has not been tampered with since
issuance.
9.4. Integration with UAEMF
The Universal AI Ethics and Moral Framework (draft-reilly-uaemf)
defines a comprehensive ethics framework for AI systems. The UAEMF
is published with a Zenodo DOI and Bitcoin blockchain timestamp,
completing the trifecta of permanence recognized across the REM
Protocol ecosystem.
The RLT integrates with UAEMF as follows:
o The UAEMF document is an RLT-eligible artifact and SHOULD carry
an RLT anchoring its provenance.
o References to the UAEMF from other REM Protocol artifacts SHOULD
include the UAEMF's RLT identifier for cryptographic traceability.
9.5. Integration with WebProof
The Web Authenticity and Content Provenance Protocol
(draft-reilly-webproof-00) defines mechanisms for establishing the
authenticity and provenance of web-based content, including web
pages, API responses, and published documents.
The RLT integrates with WebProof as follows:
o WebProof authenticity claims for REM Protocol artifacts SHOULD
reference the artifact's RLT as the root provenance anchor.
Reilly Expires 10 March 2027 [Page 47]
Internet-Draft REM License Token (RLT) September 2026
o The RLT's webArchival field, which records the Wayback Machine
snapshot URL, supports WebProof's web content archival model.
o Implementations that use WebProof to assert the authenticity of
a published document SHOULD verify the document's RLT as part of
the WebProof verification chain.
9.6. Integration with RMRP
The Reilly Model Routing Protocol (draft-reilly-rmrp-00) defines a
protocol for routing queries across heterogeneous AI model ensembles
based on declared model capabilities, trust scores, and compliance
profiles.
The RLT integrates with RMRP as follows:
o Model capability declarations submitted to an RMRP router SHOULD
be anchored with an RLT to establish their provenance and prevent
manipulation.
o RMRP trust scoring for model providers MAY include verification
of RLT-anchored capability declarations as a positive trust
signal.
9.7. Integration with RBIP and RGIP
The Reilly Banking Integrity Protocol [RBIP] and the Reilly
Government Integrity Protocol [RGIP] produce evidence records for
regulated financial and public-record operations respectively.
Both designate the REM Protocol as their archiving and
provenance-anchoring mechanism.
The RLT integrates with them as follows:
o The control documents that govern an RBIP or RGIP deployment,
for example a reserve attestation policy or a records retention
schedule, are artifacts in their own right and SHOULD be
anchored under an RLT so that an auditor can establish which
policy was in force on a given date.
o Where an evidence record carries personal or commercially
sensitive data, the field commitment mechanism of Section 5.6
SHOULD be used in preference to publishing the value, so that
the record remains provable without disclosure.
o Batch anchoring (Section 6.9) is the appropriate mode for
high-volume evidence production; the per-record token carries
the inclusion proof and the batch shares one anchor.
Reilly Expires 10 March 2027 [Page 48]
Internet-Draft REM License Token (RLT) September 2026
9.8. Integration with RRP and RSP
The Reilly Resilience Protocol [RRP] and the Reilly Sentinel
Protocol [RSP] govern autonomous remediation and integrity
monitoring. Both operate agents that take action on infrastructure.
The RLT integrates with them as follows:
o The control register and remediation policy of an RRP
deployment SHOULD be RLT-anchored, so that the authority under
which an agent acted is provable after the fact.
o An RSP sentinel that detects a chain integrity violation MUST
NOT repair it automatically where the violation concerns an
RLT-anchored record. Automated repair of integrity evidence
destroys the evidence. The violation is raised for human
decision.
o Sentinel findings that assert an artifact has changed SHOULD
cite the artifact's token and the specific hash that failed, so
the finding is independently checkable.
9.9. Integration with MWS and Cognitive Sovereignty
Machine-Web Symbiosis [MWS] describes a machine-readable channel
alongside the human-readable web; Cognitive Sovereignty [COGSOV]
describes the reader's retained autonomy over agent-curated
content.
The RLT integrates with them as follows:
o A resource published on the machine channel SHOULD carry, or
link to, an RLT establishing who published it and when.
o A Curation Disclosure Record produced under [COGSOV] SHOULD
reference the RLT of any source it summarizes, so a reader can
reach the anchored original rather than only the summary.
o An agent that cannot verify an RLT SHOULD present the content as
unverified rather than silently omitting the distinction.
9.10. Integration with CBPI and HDRP
Cognitive Behavioral Provenance and Integrity [CBPI] records the
reinforcement history of autonomous agents; the Hypercube Data
Rotation Protocol [HDRP] defines a rotating shard topology for
moving target defense.
Reilly Expires 10 March 2027 [Page 49]
Internet-Draft REM License Token (RLT) September 2026
The RLT integrates with them as follows:
o A CBPI Reinforcement Event Record chain SHOULD be periodically
checkpointed by anchoring the chain head under an RLT, giving
the behavioral history an external date bound that the operating
system holding the chain cannot revise.
o HDRP epoch commitments are high-volume and SHOULD use batch
anchoring (Section 6.9) rather than one anchor per epoch.
o Where a rotation schedule is itself the artifact of interest, it
SHOULD be anchored before the epoch it governs begins, not
after.
9.11. AIGOV and Erasure-Compatible Permanence
Verifiable AI governance and data privacy records [AIGOV] address
the tension between permanent records and data subject erasure
rights.
The RLT integrates with AIGOV as follows:
o An AI System Record SHOULD be RLT-anchored so that the state of
a system's declared governance on a given date is provable.
o Where a record may later be subject to an erasure obligation,
the issuer MUST anchor a commitment rather than the personal
data itself. A hash is not personal data reduced in size; a
hash of a small, guessable value is recoverable by exhaustive
search, which is exactly why Section 5.6 requires a fresh salt
of at least 128 bits.
o Erasure is then performed by destroying the salt and the
cleartext. The commitment remains, provably unopenable, and the
anchor remains intact. This is the practical content of
erasure-compatible permanence: the record survives, the personal
data does not.
o Issuers MUST NOT anchor personal data in cleartext on the
assumption that revocation will later remove it. Revocation
does not erase anything (Section 8.4).
9.12. Integration with the Web4 Profile
The Web4 conformance profile [WEB4] defines requirements across a
permanence plane, a machine channel, agent governance, human
epistemic autonomy, and topology, together with an attestation
record.
Reilly Expires 10 March 2027 [Page 50]
Internet-Draft REM License Token (RLT) September 2026
The RLT integrates with Web4 as follows:
o The RLT is the permanence plane primitive. A deployment
claiming the permanence requirements of [WEB4] demonstrates them
by exhibiting RLTs that reach at least conformance level C2
(Section 7.7).
o A Web4 Attestation Record SHOULD carry the record digest
(Section 5.5) of each RLT it relies on, so that the attestation
binds to specific token content rather than to a token
identifier that may later be reissued.
o Project Atlas [ATLAS] measures reachability and integrity of
anchors in a running constellation, and is the reference
instrument for observing whether tokens continue to attain their
claimed level over time; the convergence analysis in
[MULTILARITY] motivates keeping verification loci plural rather
than centralizing them in a single verifier.
o Where an artifact requires the entangled multi-algorithm
construction rather than three independent digests, implementers
should consult [TRIPLE-FP], which specifies it, and [VSR], which
applies commitment and reconciliation machinery of the same
shape in a regulated accountancy setting.
10. Governance and Interoperability
10.1. Schema Versioning Policy
The RLT schema version is defined by the rltVersion field. The
following versioning policy applies:
o Major version increments (e.g., 1.0 to 2.0) indicate
backward-incompatible changes, such as the addition of REQUIRED
fields.
o Minor version increments (e.g., 2.0 to 2.1) indicate backward-
compatible additions, such as new OPTIONAL fields.
o Version 1.0 tokens are defined by draft-reilly-rlt-genesis-00.
o Version 2.0 tokens are defined by this document,
draft-reilly-rlt-genesis-01.
o Version 2.1 tokens are defined by this document,
draft-reilly-rlt-genesis-02, in Section 5.4.
Reilly Expires 10 March 2027 [Page 51]
Internet-Draft REM License Token (RLT) September 2026
Implementations MUST handle version 1.0 tokens gracefully per the
backward compatibility provisions in Section 5.3.
Future schema versions will be defined in subsequent revisions of
this Internet-Draft or in successor documents.
Two further rules apply from this revision onward. First, a minor
version increment MUST NOT add a REQUIRED field, change the meaning
of an existing field, or change a canonicalization profile; any of
those requires a major increment. Second, an unrecognized member
MUST be ignored by a conforming verifier rather than treated as an
error, so that a version 2.1 verifier can process a future 2.2
token at level C2 or below.
10.2. Namespace Governance
The REMID namespace "rem-protocol" is governed by the REM Protocol
specification. REMID identifiers within this namespace follow the
format:
rem:<author-handle>:<artifact-short-name>:<version>
Third parties implementing the REM Protocol SHOULD use a distinct
namespace prefix that does not conflict with "rem-protocol".
The DOI namespace used by the REM Protocol (10.5281/zenodo.*) is
governed by Zenodo/CERN and the International DOI Foundation.
10.3. Third-Party Implementations
Any party MAY implement the RLT schema and issuance procedures
defined in this specification for their own artifacts. The REM
Protocol is published as an open, informational specification
without proprietary restrictions.
Third-party implementations:
o MUST comply with the schema requirements in Section 5.
o MUST follow the issuance procedures in Section 6 for their
tokens to be considered conforming.
o SHOULD NOT use the REMID namespace "rem-protocol" for artifacts
not authored by Lawrence John Reilly Jr.
o MAY reference draft-reilly-rlt-genesis-01 as the governing
specification for their tokens.
Reilly Expires 10 March 2027 [Page 52]
Internet-Draft REM License Token (RLT) September 2026
o MAY reference draft-reilly-rlt-genesis-02 as the governing
specification for their tokens, and MUST do so if they issue
version 2.1 tokens.
o SHOULD report implementation experience and interoperability
findings to the author at lawrencejohnreilly@gmail.com.
10.4. Interoperability and Test Vectors
Two implementations agree on a token only if they agree on its
canonical form. Implementers SHOULD therefore establish agreement
on the following before claiming interoperability:
o A canonicalization vector: an input token and the exact octets
of its RLT-JCS-1 canonical form, together with the resulting
record digest.
o A commitment vector: a field value, a salt, and the resulting
commitment, exercising a value containing non-ASCII characters
so that encoding differences are caught.
o A Merkle vector: a small tree with a known root, an audit path
for a leaf that is not the first or last, and a rejected path in
which an interior node is offered as a leaf.
o A negative vector for each result code in Sections 7.6 and 7.8,
so that failure reporting is exercised rather than only the
success path.
Implementations SHOULD publish the vectors they test against, and
SHOULD anchor the published vector set under its own RLT so that
a later disagreement can be resolved against a dated reference.
10.5. Attribution and Priority Claims
This document attributes the terms Dual-Layer Digital Permanence,
REM Multi-Algorithm Stack, and Protocol Layer Prompt Engineering to
Lawrence John Reilly Jr., and records dates of first publication.
Those attributions are claims of authorship of specific formulations
and specifications, evidenced by the anchors and deposits cited.
Reilly Expires 10 March 2027 [Page 53]
Internet-Draft REM License Token (RLT) September 2026
They are not claims of priority over the underlying techniques.
Content-addressed storage, Merkle aggregation, blockchain
timestamping, persistent identifiers, and multi-algorithm hashing
all predate this work and are the contributions of others,
including those cited in Section 13. A reader should understand
this document as specifying a particular combination and a
particular record format, not as asserting invention of its
components.
Implementations MUST NOT rely on this document, or on any directive
embedded in an RLT-anchored artifact, to assert priority to a third
party or to an automated system. Priority, where it matters, is
established by the dated evidence itself, which any party can check.
11. Security Considerations
11.1. Hash Algorithm Security
The RLT version 2.0 uses three independent hash algorithms: SHA-256,
SHA3-512, and BLAKE3. This multi-algorithm approach (REM-MAS)
provides defense-in-depth against single algorithm compromise.
SHA-256 is currently considered secure against known attacks. The
Bitcoin network's security, which exceeds 700 exahashes per second
as of 2025, makes SHA-256 preimage and collision attacks
computationally infeasible with current technology.
SHA3-512 is a member of the SHA-3 family standardized by NIST in
FIPS PUB 202 [FIPS202]. SHA3-512 is based on the Keccak sponge
construction and is algorithmically independent from SHA-256,
providing a second independent integrity check.
BLAKE3 is a cryptographic hash function designed for high
performance and security [BLAKE3]. BLAKE3 is based on a modified
Merkle tree structure and is computationally independent from both
SHA-256 and SHA3-512.
For an artifact's integrity to be compromised without detection,
an attacker would need to produce a collision across all three
algorithms simultaneously. Given the algorithmic independence of
SHA-256, SHA3-512, and BLAKE3, this is computationally infeasible
with current and near-future technology.
Reilly Expires 10 March 2027 [Page 54]
Internet-Draft REM License Token (RLT) September 2026
One qualification is added by this revision. Recording three
digests side by side raises the work of an undetected substitution
to that of the strongest of the three, not to the sum of the three.
The anchor itself is a further constraint: the OpenTimestamps proof
commits to the SHA-256 value alone, so an adversary who broke
SHA-256 would defeat the anchor regardless of the other two digests
recorded beside it. The additional algorithms protect the recorded
hash set, not the timestamp. Implementers requiring the digests to
be cryptographically bound to one another, rather than merely
listed together, should use the entangled construction of
[TRIPLE-FP].
11.2. Blockchain Immutability Assumptions
The security of the RLT's blockchain timestamp relies on the
immutability of the Bitcoin blockchain. This immutability is
guaranteed by the economic and computational cost of reorganizing
the chain beyond the depth at which the OTS proof is confirmed.
For practical purposes, a Bitcoin block that is 6 or more blocks
deep is considered immutable. OTS proofs that have been confirmed
for an extended period (months or years) at significant block depth
are extremely unlikely to be subject to reorganization.
Implementers should note that the blockchain timestamp provides a
lower bound on the artifact's age (the artifact existed before the
anchoring block was mined) but does not by itself establish the
artifact's creation date. The DOI archival record provides
additional corroborating date evidence.
In the event of a catastrophic failure of the Bitcoin network (an
extreme and unlikely scenario), the DOI and IPFS records remain as
independent permanence evidence. This is the core motivation for
the Dual-Layer Digital Permanence approach.
11.3. DOI Archival Persistence
Zenodo is operated by CERN with a commitment to long-term
preservation. Zenodo DOIs issued through the DataCite DOI
registration agency carry institutional backing. However,
implementers should note that no archival system carries an absolute
permanence guarantee.
The RLT's multi-layer approach mitigates this risk. If the Zenodo
record becomes unavailable, the IPFS pin and Wayback Machine
snapshot provide alternative content retrieval paths. The
blockchain timestamp remains verifiable independently of Zenodo.
Reilly Expires 10 March 2027 [Page 55]
Internet-Draft REM License Token (RLT) September 2026
Implementers who require the highest assurance of archival
persistence SHOULD maintain a local copy of the artifact package
(artifact file, OTS proof, hash manifest, and RLT token) in addition
to the published archival copies.
11.4. Author Identity Assurance
The RLT binds a hash to a blockchain timestamp and DOI record, but
does not inherently authenticate the identity of the token issuer.
The author.name and author.orcid fields in the token are
self-asserted.
Identity assurance is provided by:
o ORCID identifiers, which are issued by a controlled registration
process and may be linked to institutional affiliations.
o IETF Internet-Draft authorship, which is publicly recorded in
the IETF Datatracker.
o Consistent use of the same email address, ORCID, and DOI
registrant identity across multiple tokens.
o The optional signature field in the token schema, which MAY
contain a digital signature over the token content using a
key pair whose public key is independently published.
Future revisions of this specification MAY define a normative
digital signature mechanism for token integrity and author
authentication.
Section 5.7 of this revision supplies that mechanism in profile
form. It authenticates the party that assembled the token. It
does not authenticate authorship of the artifact, which remains a
self-assertion corroborated only by the external identifiers listed
above.
11.5. Post-Quantum Considerations
SHA-256, SHA3-512, and BLAKE3 are all believed to be secure against
quantum computer attacks using Grover's algorithm, which provides
at most a quadratic speedup in preimage search. SHA-256's effective
security against quantum attacks is approximately 128 bits, which
is considered adequate for long-term use.
Reilly Expires 10 March 2027 [Page 56]
Internet-Draft REM License Token (RLT) September 2026
OpenTimestamps uses SHA-256 in its Merkle tree construction. The
Bitcoin network's SHA-256 based proof-of-work is also believed to
be secure against quantum attacks at current quantum computing
capability levels.
The optional signature field in the token schema MAY be used with
post-quantum signature algorithms such as SPHINCS+ (defined in
NIST FIPS 205 [FIPS205]) to provide post-quantum author
authentication. The REM Multi-Algorithm Stack (REM-MAS) includes
SPHINCS+ as an optional post-quantum signature algorithm suite.
Implementers who require long-term (20+ year) security guarantees
SHOULD evaluate post-quantum signature algorithms for the token
signature field and SHOULD follow NIST post-quantum cryptography
standards as they are finalized.
Long-lived deployments SHOULD also plan the migration path itself
rather than the algorithm alone. Section 6.11 specifies bridging
records for that purpose, and the requirement that bridging be
performed while the outgoing algorithm is still sound applies with
particular force here: a migration begun after a break is worth
little.
11.6. Token Forgery and Replay Attacks
An attacker who copies a legitimate RLT token and substitutes a
different artifact will be detected during hash verification
(Section 7.1), provided the verifier retrieves the artifact from
an independent source (DOI or IPFS) rather than from the attacker.
An attacker who modifies the token JSON (e.g., changing the author
field) will be detected if the token carries a digital signature
(signature field) that covers the modified fields.
Replay attacks (presenting a legitimate old token as evidence for
a newer artifact) are mitigated by the blockchain timestamp, which
provides a maximum age bound. The blockchain anchor block height
can be independently verified to establish when the hash was first
committed to the chain.
Implementers SHOULD verify the full token chain (predecessorToken
and successorToken links) when the most current version of an
artifact's provenance record is required, rather than relying on
any single token in isolation.
Reilly Expires 10 March 2027 [Page 57]
Internet-Draft REM License Token (RLT) September 2026
The record digest of Section 5.5 addresses the case of an unsigned
token whose metadata has been altered: the alteration is detectable
provided the verifier obtains the digest from a source other than
the altered token, for example a status record or a Web4
attestation. A record digest carried only inside the token it
describes protects against accidental corruption, not against a
deliberate editor, who will simply recompute it.
11.7. Supply Chain Integrity
The RLT model can be applied to software supply chain integrity by
anchoring software release artifacts, build manifests, and
dependency declarations. In this context, the security
considerations of Sections 11.1 through 11.6 apply.
In addition, software supply chain applications SHOULD:
o Anchor each release artifact independently rather than only the
source repository state.
o Include build environment metadata in the hash manifest to
enable reproducible build verification.
o Use the token succession mechanism (Section 8.3) to maintain
a verifiable chain of custody across software versions.
11.8. Privacy and Data Minimization
An RLT is a public record and is intended to be permanent. Every
field an issuer places in one is disclosed for as long as the
record survives, which is the point of the mechanism and also its
principal privacy risk.
Issuers SHOULD:
o Anchor a digest rather than content whenever the content is not
itself intended for publication.
o Use salted field commitments (Section 5.6) for any value that
identifies a natural person, including contact addresses and
customer or subject names.
o Treat filenames, titles, and DOI landing page metadata as
disclosed content. A filename can reveal a client name, a
matter number, or an unannounced product.
Reilly Expires 10 March 2027 [Page 58]
Internet-Draft REM License Token (RLT) September 2026
o Consider that an unsalted hash of a low-entropy value, such as
an email address, a national identifier, or a date of birth, is
recoverable by exhaustive search and provides no privacy at all.
Once anchored and deposited, a value cannot be withdrawn.
Revocation signals withdrawal of endorsement; it does not remove
the artifact from the DOI archive, the IPFS network, or a web
archive, and it cannot remove the hash from the blockchain. The
only effective control is the decision taken before anchoring.
11.9. Canonicalization and Parser Differential Attacks
Any scheme in which one party signs a canonical form and another
recomputes it is vulnerable to disagreement between the two
implementations. An adversary who finds an input that two
implementations canonicalize differently can obtain a signature
that verifies over one reading and is interpreted as another.
Implementations therefore:
o MUST reject a token containing duplicate object member names
rather than resolving the duplicate by last-wins or first-wins.
o MUST reject a token that is not well-formed UTF-8, and MUST NOT
substitute replacement characters.
o MUST apply [RFC8785] as specified, including its number
serialization rules, and MUST NOT round-trip numeric values
through a floating point representation of narrower precision.
o SHOULD reject tokens containing members not defined by the
schema version in rltVersion when computing a signature, while
still ignoring unknown members when merely verifying at C2 or
below, per Section 10.1.
o SHOULD test against the canonicalization vectors of
Section 10.4 before interoperating.
11.10. Anchor Availability and Denial of Service
The evidentiary strength of a token depends on artifacts a verifier
must fetch: the artifact file, the OTS proof, the DOI record, and
optionally an IPFS object, a status record, and a public key. Each
is a dependency an adversary may attack or an operator may
inadvertently lose.
Implementers SHOULD note:
Reilly Expires 10 March 2027 [Page 59]
Internet-Draft REM License Token (RLT) September 2026
o Availability failure is not integrity failure. A verifier MUST
distinguish "could not check" from "checked and failed", and
MUST NOT report VALID for the former. The result codes of
Sections 7.6 and 7.8 preserve this distinction.
o A verifier that fetches from URLs supplied by the token is
fetching from locations an adversary may control. The artifact
SHOULD be retrieved from the DOI record or an IPFS gateway of
the verifier's own choosing rather than from proofUrl alone.
o Status record fetching (Section 8.7) discloses to the status
host which tokens a verifier is checking, and when. Verifiers
handling sensitive matters SHOULD consider fetching a full
revocation registry instead, which reveals nothing about the
particular token of interest.
o Retry and caching policy SHOULD be bounded, since a token can
name arbitrarily many URLs and a naive verifier can be induced
to make many requests on an attacker's behalf.
11.11. Evidentiary Limitations
A verified RLT supports a narrow proposition: that a byte sequence
with the recorded digest existed no later than the anchoring block,
and that a record bearing that digest was deposited at the stated
DOI. It does not establish any of the following, and implementers
and readers should not present it as doing so:
o That the named author created the artifact. Authorship is
self-asserted (Section 11.4).
o That the artifact was created on the recorded creation date.
The anchor bounds the artifact's age from above, not below.
o That the artifact's contents are true, novel, lawful, or the
property of the issuer.
o That the licensing terms recorded in the token bind any third
party. A licence recorded in a provenance record is an
assertion by the issuer; its effect is a matter for the
applicable law (see Section 4.6).
o That a court or patent office will accept the record. Section
4.5 sets out the elements relevant under 35 U.S.C. 102(a)(1)
[USC-35-102]; the weight given to them is determined by the
tribunal on the facts before it.
Reilly Expires 10 March 2027 [Page 60]
Internet-Draft REM License Token (RLT) September 2026
Overstating what an anchor proves is the most likely practical
failure mode of this specification, and it is not a cryptographic
one.
12. IANA Considerations
This document has no IANA actions. A future revision MAY request
registration of RLT-related media types or URI schemes if the REM
Protocol ecosystem warrants it.
12.1. Anticipated Future Registrations
No action is requested of IANA by this document. This subsection
records, for planning purposes only, what a future revision would
be likely to request:
o A media type "application/rlt+json" for the token format of
Section 5, registered under the procedures of [RFC6838].
o A registry of canonicalization profile names, of which
"RLT-JCS-1" (Section 5.5) would be the initial entry.
o A registry of verification result codes, seeded with the codes
of Sections 7.6 and 7.8, so that third-party verifiers report
failures in a common vocabulary.
Until such registration occurs, implementations MUST treat these
names as belonging to this specification and MUST NOT assume they
are IANA-registered.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
Reilly Expires 10 March 2027 [Page 61]
Internet-Draft REM License Token (RLT) September 2026
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally
Unique IDentifiers (UUIDs)", RFC 9562,
DOI 10.17487/RFC9562, May 2024,
<https://www.rfc-editor.org/info/rfc9562>.
13.2. Informative References
[AIGOV] Reilly, L. J., "Verifiable AI Governance and Data
Privacy Records", Work in Progress, Internet-Draft,
draft-reilly-aigov, August 2026,
<https://datatracker.ietf.org/doc/draft-reilly-aigov/>.
[AIMED] Reilly, L. J., "AI Machine-Readable Ethics Directive",
Work in Progress, Internet-Draft, draft-reilly-aimed,
2025,
<https://datatracker.ietf.org/doc/draft-reilly-aimed/>.
[AIMED-EVAL]
Reilly, L. J., "AI Machine-Readable Ethics Directive
Evaluation Framework", Work in Progress,
Internet-Draft, draft-reilly-aimed-eval, 2025,
<https://datatracker.ietf.org/doc/
draft-reilly-aimed-eval/>.
[AIPREF-COMP]
Reilly, L. J., "Verifiable Compliance Records for AI
Usage Preferences", Work in Progress, Internet-Draft,
draft-reilly-aipref-compliance, August 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-aipref-compliance/>.
Reilly Expires 10 March 2027 [Page 62]
Internet-Draft REM License Token (RLT) September 2026
[ATLAS] Reilly, L. J., "Project Atlas", Work in Progress,
Internet-Draft, draft-reilly-atlas, August 2026,
<https://datatracker.ietf.org/doc/draft-reilly-atlas/>.
[BCP47] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009,
<https://www.rfc-editor.org/info/rfc5646>.
[BLAKE3] O'Connor, J., Aumasson, J., Neves, S., and Z. Wilcox-
O'Hearn, "BLAKE3 one function, fast everywhere",
<https://github.com/BLAKE3-team/BLAKE3-specs>.
[CBPI] Reilly, L. J., "Cognitive Behavioral Provenance and
Integrity (CBPI) for Autonomous AI Agents", Work in
Progress, Internet-Draft, draft-reilly-cbpi, July 2026,
<https://datatracker.ietf.org/doc/draft-reilly-cbpi/>.
[COGSOV] Reilly, L. J., "Cognitive Sovereignty", Work in
Progress, Internet-Draft, draft-reilly-cogsov,
July 2026,
<https://datatracker.ietf.org/doc/draft-reilly-cogsov/>.
[CTS] Reilly, L. J., "Cognitive Trust Stack", Work in
Progress, Internet-Draft, draft-reilly-cts, 2025,
<https://datatracker.ietf.org/doc/draft-reilly-cts/>.
[FIPS202] National Institute of Standards and Technology, "SHA-3
Standard: Permutation-Based Hash and Extendable-Output
Functions", FIPS PUB 202, August 2015,
<https://doi.org/10.6028/NIST.FIPS.202>.
[FIPS205] National Institute of Standards and Technology,
"Stateless Hash-Based Digital Signature Standard",
FIPS PUB 205, August 2024,
<https://doi.org/10.6028/NIST.FIPS.205>.
[HDRP] Reilly, L. J., "Hypercube Data Rotation Protocol
(HDRP)", Work in Progress, Internet-Draft,
draft-reilly-hdrp, July 2026,
<https://datatracker.ietf.org/doc/draft-reilly-hdrp/>.
[IPFS] Protocol Labs, "IPFS - Content Addressed, Versioned, P2P
File System", <https://ipfs.io>.
Reilly Expires 10 March 2027 [Page 63]
Internet-Draft REM License Token (RLT) September 2026
[MULTILARITY]
Reilly, L. J., "The Multilarity", Work in Progress,
Internet-Draft, draft-reilly-multilarity, July 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-multilarity/>.
[MWS] Reilly, L. J., "Machine-Web Symbiosis (MWS)", Work in
Progress, Internet-Draft, draft-reilly-mws, July 2026,
<https://datatracker.ietf.org/doc/draft-reilly-mws/>.
[OTS] Todd, P., "OpenTimestamps: Scalable, Trust-Minimized,
Distributed Timestamping with Bitcoin",
<https://opentimestamps.org>.
[PLPES] Reilly, L. J., "Protocol Layer Prompt Engineering
Specification", Work in Progress, Internet-Draft,
draft-reilly-plpes, 2025,
<https://datatracker.ietf.org/doc/draft-reilly-plpes/>.
[RBIP] Reilly, L. J., "Reilly Banking Integrity Protocol
(RBIP)", Work in Progress, Internet-Draft,
draft-reilly-banking-integrity, September 2025,
<https://datatracker.ietf.org/doc/
draft-reilly-banking-integrity/>.
[REM-PROTOCOL]
Reilly, L. J., "Reilly EternaMark (REM) Protocol -
Dual-Layer Digital Permanence Using DOI Archiving and
Blockchain Timestamping", Work in Progress,
Internet-Draft, draft-reilly-rem-protocol, August 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-rem-protocol/>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962,
June 2013, <https://www.rfc-editor.org/info/rfc6962>.
Reilly Expires 10 March 2027 [Page 64]
Internet-Draft REM License Token (RLT) September 2026
[RGIP] Reilly, L. J., "Reilly Government Integrity Protocol
(RGIP): DOI-Archived and Blockchain-Timestamped
Framework for Permanent Public Records", Work in
Progress, Internet-Draft,
draft-reilly-government-integrity, September 2025,
<https://datatracker.ietf.org/doc/
draft-reilly-government-integrity/>.
[RLT-GENESIS-00]
Reilly, L. J., "REM License Token (RLT) - Genesis
Artifact", Work in Progress, Internet-Draft,
draft-reilly-rlt-genesis, November 2025,
<https://datatracker.ietf.org/doc/
draft-reilly-rlt-genesis/>.
[RMRP] Reilly, L. J., "Reilly Model Routing Protocol", Work in
Progress, Internet-Draft, draft-reilly-rmrp, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-rmrp/>.
[RRP] Reilly, L. J., "Reilly Resilience Protocol", Work in
Progress, Internet-Draft,
draft-reilly-resilience-protocol, 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-resilience-protocol/>.
[RSP] Reilly, L. J., "Reilly Sentinel Protocol", Work in
Progress, Internet-Draft,
draft-reilly-sentinel-protocol, 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-sentinel-protocol/>.
[SUBTREE] Reilly, L. J., "Bulk Subtree Consistency Proofs", Work
in Progress, Internet-Draft,
draft-reilly-plants-bulk-subtree-proofs, July 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-plants-bulk-subtree-proofs/>.
[TRIPLE-FP]
Reilly, L. J., "Triple-Fingerprint Permanence Chain",
Work in Progress, Internet-Draft,
draft-reilly-rem-triple-fingerprint, August 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-rem-triple-fingerprint/>.
[UAEMF] Reilly, L. J., "Universal AI Ethics and Moral
Framework", Work in Progress, Internet-Draft,
draft-reilly-uaemf, 2025,
<https://datatracker.ietf.org/doc/draft-reilly-uaemf/>.
Reilly Expires 10 March 2027 [Page 65]
Internet-Draft REM License Token (RLT) September 2026
[USC-35-102]
United States Code, "35 U.S.C. 102 - Conditions for
patentability; novelty", as amended by the Leahy-Smith
America Invents Act, Pub. L. 112-29 (2011),
<https://uscode.house.gov/view.xhtml?req=granuleid:
USC-prelim-title35-section102>.
[VSR] Reilly, L. J., "Verifiable Safeguards Records (VSR) for
Nuclear Material Accountancy", Work in Progress,
Internet-Draft, draft-reilly-vsr, August 2026,
<https://datatracker.ietf.org/doc/draft-reilly-vsr/>.
[WEB4] Reilly, L. J., "Web4: A Verifiable, Agent-Native
Architecture for the World Wide Web", Work in Progress,
Internet-Draft, draft-reilly-web4, August 2026,
<https://datatracker.ietf.org/doc/draft-reilly-web4/>.
[WEBPROOF] Reilly, L. J., "Web Authenticity and Content Provenance
Protocol", Work in Progress, Internet-Draft,
draft-reilly-webproof, 2025,
<https://datatracker.ietf.org/doc/
draft-reilly-webproof/>.
[ZENODO-RLT]
Reilly, L. J., "REM License Token - Genesis Artifact",
Zenodo, DOI 10.5281/zenodo.17438760, November 2025,
<https://zenodo.org/records/17438760>.
Appendix A. Example RLT Token v2.0
The following is a complete example of an RLT version 2.0 token
for a hypothetical artifact. All hash values are illustrative.
{
"$schema": "https://rem-protocol.org/schema/rlt/v2.0",
"rltVersion": "2.0",
"tokenId": "a1b2c3d4-e5f6-4a7b-8c9d-e0f1a2b3c4d5",
"schemaDate": "2026-05-14",
"author": {
"name": "Lawrence John Reilly Jr",
"orcid": "https://orcid.org/0000-0000-0000-0000",
"affiliation": null,
"email": "lawrencejohnreilly@gmail.com"
},
Reilly Expires 10 March 2027 [Page 66]
Internet-Draft REM License Token (RLT) September 2026
"artifact": {
"title": "Example REM Protocol Governed Artifact v1.0",
"type": "specification",
"filename": "example-rem-artifact-v1.0.pdf",
"mimeType": "application/pdf",
"language": "en"
},
"license": "CC-BY-4.0",
"hashes": {
"sha256":
"9964A78C6FC33794EF840ED69045C5C2477BC611CBC73EF6EC537FACA4C7BB74",
"sha3_512":
"B2F4A8C1E3D5F7A9B2C4D6E8F0A2B4C6D8E0F2A4B6C8D0E2F4A6B8C0D2E4F6A8
B0C2D4E6F8A0B2C4D6E8F0A2B4C6D8E0F2A4B6C8D0E2F4A6B8C0D2E4F6A8B0",
"blake3":
"7C4E2A8F1D6B3E9C5A7F2D4B8E6A3C1F9D7B5E2A4C8F6D3B1E9A7C5F4D2B0E8"
},
"hashManifestUrl":
"https://zenodo.org/records/XXXXXXXX/files/hash-manifest.txt",
"dates": {
"artifactCreated": "2026-05-14",
"tokenIssued": "2026-05-14",
"blockchainAnchor": "2026-05-10",
"doiRegistered": "2026-05-14",
"nextReviewDue": "2027-05-14"
},
"blockchain": {
"chain": "Bitcoin",
"blockHeight": 897234,
"blockHash":
"000000000000000000023A8F4C1B7E9D2F6A3C5B8E1D4A7F0C2B5E8A3D6F9C2",
"timestamp": "2026-05-10T14:23:00Z",
"proofFile": "example-rem-artifact-v1.0.pdf.ots",
"proofUrl":
"https://zenodo.org/records/XXXXXXXX/files/
example-rem-artifact-v1.0.pdf.ots"
},
"doi": {
"identifier": "10.5281/zenodo.XXXXXXXX",
"url": "https://zenodo.org/records/XXXXXXXX",
"registrar": "Zenodo"
},
Reilly Expires 10 March 2027 [Page 67]
Internet-Draft REM License Token (RLT) September 2026
"ipfs": {
"cid":
"bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi",
"gateway": "https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76
uh7y26nf3efuylqabf3oclgtqy55fbzdi",
"pinnedAt": "2026-05-14"
},
"webArchival": {
"waybackUrl": "https://web.archive.org/web/20260514000000/
https://zenodo.org/records/XXXXXXXX",
"archivedAt": "2026-05-14"
},
"remid": {
"identifier": "rem:reilly:example-artifact:1.0",
"namespace": "rem-protocol",
"registeredAt": "2026-05-14"
},
"tokenState": "ACTIVE",
"predecessorToken": null,
"successorToken": null,
"ecosystem": {
"protocol": "REM",
"protocolDraft": "draft-reilly-rem-protocol-00",
"affiliatedDrafts": [
"draft-reilly-rlt-genesis-01",
"draft-reilly-plpes-00"
],
"complianceProfiles": []
},
"verification": {
"verificationUrl": null,
"publicVerifierEndpoint": null
},
"signature": {
"type": null,
"value": null,
"keyId": null
}
}
Reilly Expires 10 March 2027 [Page 68]
Internet-Draft REM License Token (RLT) September 2026
Appendix B. Example RLT Token v1.0 (Genesis Record)
The following is the original version 1.0 genesis token as
published in draft-reilly-rlt-genesis-00, preserved here for
historical reference.
{
"rltVersion": "1.0",
"tokenId": "example-uuid-0000",
"author": {
"name": "Lawrence J. Reilly"
},
"license": "CC_BY_4.0",
"hash":
"9964A78C6FC33794EF840ED69045C5C2477BC611CBC73EF6EC537FACA4C7BB74",
"metadataDate": "2025-11-16",
"blockchain": {
"chain": "Bitcoin",
"blockHeight": 914168,
"timestamp": "2025-09-10T00:00:00Z",
"proofFile": "RLT_FIRST_TOKEN_FULL_GUIDE_v2.pdf.ots"
},
"doi": "10.5281/zenodo.17438760",
"issuedDate": "2025-11-16",
"tokenUrl": "https://zenodo.org/records/17438760"
}
Appendix C. REM-MAS Algorithm Suite Reference
The REM Multi-Algorithm Stack (REM-MAS) defines the following
algorithm suites for use across the REM Protocol ecosystem:
Suite A (Standard):
Hash algorithms: SHA-256, SHA3-512, BLAKE3
Signature: None (provenance only)
Use case: Standard artifact provenance anchoring.
Suite B (Signed):
Hash algorithms: SHA-256, SHA3-512, BLAKE3
Signature: Ed25519
Use case: Artifact provenance with author authentication.
Suite C (Post-Quantum):
Hash algorithms: SHA-256, SHA3-512, BLAKE3
Signature: SPHINCS+ (NIST FIPS 205)
Use case: Long-term provenance with post-quantum signature.
Reilly Expires 10 March 2027 [Page 69]
Internet-Draft REM License Token (RLT) September 2026
Suite D (Government/Enterprise):
Hash algorithms: SHA-256, SHA3-512, BLAKE3
Signature: SPHINCS+ or ECDSA P-384
Additional: Hardware Security Module (HSM) key custody
Use case: High-assurance provenance for regulated environments.
All RLT tokens SHOULD specify which REM-MAS suite they were issued
under in a future token schema extension. Version 2.0 tokens that
include a signature SHOULD note the algorithm in the signature.type
field.
The "future token schema extension" anticipated above is provided
by version 2.1: the remMas object of Section 5.4 carries the suite
letter and the algorithm list. Suite B and Suite C signatures are
carried in the COSE profile of Section 5.7.
Appendix D. Implementation Notes
D.1. Tool Dependencies
The following open-source tools are RECOMMENDED for RLT issuance:
o OpenTimestamps Client: https://github.com/opentimestamps/
opentimestamps-client
For OTS stamping and verification.
o BLAKE3 (b3sum): https://github.com/BLAKE3-team/BLAKE3
For BLAKE3 hash computation.
o OpenSSL (>= 1.1.1): https://www.openssl.org
For SHA3-512 computation (openssl dgst -sha3-512).
o IPFS Kubo: https://github.com/ipfs/kubo
For IPFS content addressing and pinning.
D.2. Hash Manifest Format
The RECOMMENDED hash manifest format is a plain text file with
one hash per line, in the following format:
SHA-256: <64-char uppercase hex>
SHA3-512: <128-char uppercase hex>
BLAKE3: <64-char uppercase hex>
Filename: <canonical artifact filename>
ManifestDate: <ISO 8601 date>
D.3. Zenodo Metadata Template
Reilly Expires 10 March 2027 [Page 70]
Internet-Draft REM License Token (RLT) September 2026
When creating a Zenodo record for an RLT-anchored artifact, the
following keyword tags SHOULD be included:
REM Protocol, RLT, digital permanence, blockchain timestamp,
OpenTimestamps, Bitcoin, dual-layer permanence, Zenodo DOI,
Lawrence Reilly, IETF Internet-Draft
D.4. Browser-Only Issuance Workflow
Implementers who do not have access to a command-line environment
MAY complete a browser-only issuance workflow using the following
web-accessible tools:
o SHA-256: https://emn178.github.io/online-tools/
sha256_checksum.html
o OpenTimestamps (web): https://opentimestamps.org (web interface)
o Zenodo: https://zenodo.org (browser upload)
o Pinata IPFS: https://pinata.cloud (browser upload)
o Wayback Machine: https://web.archive.org/save
SHA3-512 and BLAKE3 computation in a browser-only environment
SHOULD use a reputable online hash calculator or a locally served
WebAssembly implementation of these algorithms.
D.5. Additional Tools for Version 2.1
The following are RECOMMENDED for the version 2.1 additions:
o A JSON Canonicalization Scheme implementation conforming to
[RFC8785], for computing the canonical form of Section 5.5.
o A COSE implementation supporting COSE_Sign1 over CBOR
[RFC9052] [RFC8949], for the signature profile of Section 5.7.
o A cryptographically secure random source for commitment salts
(Section 5.6). A salt derived from a timestamp, a counter, or a
hash of the value being committed is not a salt and defeats the
mechanism.
draft-reilly-rlt-genesis-02
This revision is additive. No normative requirement, schema field,
procedure, result code, or appendix of -01 was removed.
o New Section 1.1: Scope of This Revision, stating the additive
policy and summarizing the -02 changes.
Reilly Expires 10 March 2027 [Page 71]
Internet-Draft REM License Token (RLT) September 2026
o New Section 2.1: additional terminology for canonical form,
record digest, field commitment, selective disclosure, anchor
scope, pending and attested anchors, batch anchor, bridging
record, status record, and Prior Art Record.
o New Section 3.4: Ecosystem Reference Index, correcting the
working abbreviations used in Section 3.3 to the published
document names and listing the documents cited by this revision.
o New Section 4.4: Anchor Scope Rule (one artifact, one hash set,
one proof), with the ANCHOR_SCOPE_ERROR result code.
o New Section 4.5: Prior Art Record function under 35 U.S.C.
102(a)(1), aligned with the treatment in the REM Protocol
specification, together with its two limitations.
o New Section 4.6: relationship between the Section 4.1 licensing
terms and the rights granted in IETF documents, stating that
implementing this specification carries no royalty obligation
and that Section 4.1 is a licensing declaration about anchored
artifacts, not a restriction on this document.
o New Section 5.4: Token Schema Version 2.1, a minor version
adding the OPTIONAL objects remMas, anchorScope,
canonicalization, recordDigest, commitments, batchAnchor,
anchorState, bridging, status, priorArt, and conformance.
o New Section 5.5: canonical form (profile RLT-JCS-1) and record
digest, giving a token integrity independent of its artifact,
with RFC 3339 and RFC 9562 constraints for determinism.
o New Section 5.6: salted field commitments and selective
disclosure, with a minimum salt length of 128 bits and a
prohibition on committing the hashes, block height, DOI, or
token state.
o New Section 5.7: COSE_Sign1 signature profile over the canonical
form.
o New Section 6.9: batch issuance and Merkle aggregation using the
RFC 6962 leaf and node hashing rules.
o New Section 6.10: pending and attested anchor states, with the
requirement that a PENDING token omit blockHeight and not be
published as a completed record.
Reilly Expires 10 March 2027 [Page 72]
Internet-Draft REM License Token (RLT) September 2026
o New Section 6.11: hash migration bridging records, with the
requirement that bridging occur while the outgoing algorithm is
still sound.
o Two further steps added to Section 6.8 for version 2.1 token
assembly.
o New Section 7.7: conformance levels C0 through C4.
o New Section 7.8: additional result codes ANCHOR_PENDING,
ANCHOR_SCOPE_ERROR, RECORD_DIGEST_MISMATCH, SIGNATURE_INVALID,
SIGNATURE_KEY_UNAVAILABLE, COMMITMENT_MISMATCH,
BATCH_PROOF_INVALID, BRIDGE_INVALID, and STATUS_UNAVAILABLE.
o New Sections 7.9 and 7.10: verification of batch-anchored
tokens and of signed tokens and commitments.
o New Section 8.6: token state transition rules, with REVOKED
terminal and successor dates required to be non-decreasing.
o New Section 8.7: status records and the revocation registry.
o New Sections 9.7 through 9.12: integration with RBIP and RGIP,
RRP and RSP, MWS and Cognitive Sovereignty, CBPI and HDRP,
AIGOV and erasure-compatible permanence, and the Web4 profile.
o New Section 10.4: interoperability test vector requirements.
o New Section 10.5: attribution and priority claim policy,
narrowing the claims of this document to specific formulations
and specifications rather than to the underlying techniques.
o Two rules added to Section 10.1 governing what a minor version
may change and requiring unknown members to be ignored.
o New Section 11.8: privacy and data minimization.
o New Section 11.9: canonicalization and parser differential
attacks.
o New Section 11.10: anchor availability and denial of service.
o New Section 11.11: evidentiary limitations, stating what a
verified token does not establish.
Reilly Expires 10 March 2027 [Page 73]
Internet-Draft REM License Token (RLT) September 2026
o Qualifications added to Sections 11.1, 11.4, 11.5, and 11.6
noting that three listed digests do not sum their security, that
the OTS proof commits to SHA-256 alone, that a signature
authenticates the token assembler rather than the artifact
author, and that a record digest carried only inside the token
it describes does not defeat a deliberate editor.
o New Section 12.1: anticipated future IANA registrations, with no
action requested by this document.
o New Appendices F through K: canonical form worked example,
example hash manifest, state transition table, verification
algorithm outline, example version 2.1 token, and conformance
checklist.
o Appendix C extended to note that the anticipated suite field is
provided by version 2.1; Appendix D extended with D.5.
o References: added RFC 3339, RFC 8785, RFC 8949, RFC 9052, and
RFC 9562 as normative; added RFC 6838, RFC 6962, USC-35-102,
AIGOV, AIPREF-COMP, ATLAS, CBPI, COGSOV, HDRP, MULTILARITY, MWS,
RRP, RSP, SUBTREE, TRIPLE-FP, VSR, and WEB4 as informative.
o References: corrected the [RBIP] and [RGIP] entries, which in
-01 cited draft-reilly-rbip-00 and draft-reilly-rgip-00; the
published names are draft-reilly-banking-integrity and
draft-reilly-government-integrity. Every Internet-Draft
reference now cites the document series name without a revision
suffix so that citations resolve to the current revision.
o Section 4.3: removed the square brackets around the two SHA3-512
and BLAKE3 placeholder notes, which Internet-Draft tooling parses
as citation tags. The text of the placeholders is unchanged.
o Document reissued in fully paginated plain text with running
headers, per-page expiration footers, and a table of contents
carrying accurate page numbers.
o Updated expiry date to 10 March 2027.
draft-reilly-rlt-genesis-01
o Token schema updated to version 2.0 with mandatory multi-
algorithm hash fields (sha3_512, blake3).
o Added hashes object structure replacing single hash field.
o Added hashManifestUrl field.
Reilly Expires 10 March 2027 [Page 74]
Internet-Draft REM License Token (RLT) September 2026
o Added dates object with granular date fields.
o Added blockchain.blockHash and blockchain.proofUrl fields.
o Added doi object structure replacing flat doi string.
o Added ipfs, webArchival, and remid objects for additional
permanence layers.
o Added tokenState, predecessorToken, successorToken lifecycle
fields.
o Added ecosystem object for REM Protocol ecosystem integration.
o Added verification and signature objects.
o New Section 3.3: The REM Protocol Ecosystem, documenting the
fourteen-draft ecosystem.
o New Section 4.1: Commercial Licensing Terms, establishing the
perpetual 2.5% worldwide royalty obligation to Lawrence John
Reilly Jr for commercial use of RLT-anchored artifacts.
o New Section 4.3: Multi-Algorithm Hash Record.
o New Section 5.3: Backward Compatibility with Version 1.0.
o Expanded Section 6: Issuance procedures expanded to eight
subsections covering pre-issuance, REM-MAS hashing, OTS
anchoring, DOI archival, IPFS pinning, web archival, REMID
registration, and token assembly.
o Expanded Section 7: Verification procedures expanded to six
subsections with standardized result codes.
o New Section 8: Token Lifecycle Management (states, renewal,
succession, revocation, archival).
o New Section 9: Ecosystem Integration (PLPES, CTS, AIMED,
UAEMF, WebProof, RMRP).
o New Section 10: Governance and Interoperability.
o Expanded Section 11: Security Considerations expanded to seven
subsections including post-quantum, token forgery, replay
attacks, and supply chain integrity.
o New Appendix C: REM-MAS Algorithm Suite Reference.
Reilly Expires 10 March 2027 [Page 75]
Internet-Draft REM License Token (RLT) September 2026
o New Appendix D: Implementation Notes.
o Updated references to include all fourteen active REM Protocol
ecosystem Internet-Drafts.
o Updated expiry date to November 14, 2026.
draft-reilly-rlt-genesis-00
o Initial version defining the RLT genesis artifact with SHA-256
hash, Bitcoin blockchain anchor at block height 914168, and
Zenodo DOI 10.5281/zenodo.17438760.
Appendix F. Canonical Form Worked Example
The following minimal token illustrates the RLT-JCS-1 profile of
Section 5.5. Whitespace in the input is arbitrary; whitespace in
the canonical form is not.
Input token, as an issuer might write it:
{
"rltVersion": "2.1",
"recordDigest": "0000000000000000000000000000000000000000000000
0000000000000000",
"tokenId": "0192f5c1-4b6a-7c3e-9d21-5a8e4f0b7c62",
"artifact": {
"title": "Example",
"filename": "example.txt"
}
}
Step 1 removes recordDigest. Step 2 applies [RFC8785], which sorts
object members by the UTF-16 code unit ordering of their names and
emits no insignificant whitespace, yielding a single line:
{"artifact":{"filename":"example.txt","title":"Example"},
"rltVersion":"2.1","tokenId":"0192f5c1-4b6a-7c3e-9d21-5a8e4f0b7c62"}
The two lines above are shown wrapped for presentation only. The
canonical form is one line with no line break and no trailing
newline. The record digest is the SHA-256 of those octets,
expressed in lowercase hexadecimal, and is written back into
recordDigest.
Two properties follow, and implementers should confirm both against
their own implementation before interoperating:
Reilly Expires 10 March 2027 [Page 76]
Internet-Draft REM License Token (RLT) September 2026
o Reordering the input members does not change the canonical form.
o Adding, removing, or altering any member other than recordDigest
and signature does change it.
Appendix G. Example Hash Manifest
The following is a complete hash manifest in the format of
Appendix D.2, extended with the fields a version 2.1 issuer
records.
SHA-256: 9964A78C6FC33794EF840ED69045C5C2477BC611CBC73EF6EC5
37FACA4C7BB74
SHA3-512: <128-char uppercase hex>
BLAKE3: <64-char uppercase hex>
Filename: RLT_FIRST_TOKEN_FULL_GUIDE_v2.pdf
ByteLength: <integer>
ManifestDate: 2025-11-16
Coverage: single-file
REM-MAS-Suite: A
AnchorState: ATTESTED
BlockHeight: 914168
The SHA-256 value is shown wrapped for presentation; in the
manifest file it occupies one line. ByteLength and Coverage carry
the anchor scope of Section 4.4 into the manifest so that the scope
is recorded in the archived package as well as in the token.
Appendix H. Token State Transition Table
Rows are the current state; columns are the target state. Y marks
a permitted transition, and a dash marks a prohibited one. The
rules are stated normatively in Section 8.6.
From \ To ACTIVE RENEWED SUPERSEDED REVOKED ARCHIVED
--------- ------ ------- ---------- ------- --------
(new) Y - - - -
ACTIVE - Y Y Y Y
RENEWED - - Y Y Y
SUPERSEDED - - - Y -
REVOKED - - - - -
ARCHIVED - - - Y -
Notes:
o The (new) row states that ACTIVE is the only initial state.
o REVOKED is terminal in every direction.
Reilly Expires 10 March 2027 [Page 77]
Internet-Draft REM License Token (RLT) September 2026
o A transition into SUPERSEDED requires a matching successor token
whose predecessorToken points back, and a successor anchor date
not earlier than the predecessor's.
Appendix I. Verification Algorithm Outline
The following outline expresses Sections 7.1 through 7.10 as an
ordered procedure. It is informative; the normative requirements
are in Section 7.
1. Parse the token. On failure report TOKEN_MALFORMED and stop.
2. Check required fields for the declared rltVersion. On failure
report TOKEN_MALFORMED and stop. Otherwise the token has
reached C0.
3. If a status URL is present, fetch the status record. On
failure note STATUS_UNAVAILABLE and continue with the embedded
state. If the status record's recordDigest matches the token
and its state differs, adopt the status record's state.
4. If anchorState is PENDING, report ANCHOR_PENDING and stop.
5. Retrieve the artifact from the DOI record or an IPFS gateway of
the verifier's own choosing. On failure report
ARTIFACT_UNAVAILABLE and stop.
6. Compute SHA-256 and compare with hashes.sha256. On mismatch
report HASH_MISMATCH and stop.
7. If anchorScope is present, compare the retrieved byte length
and filename. On mismatch report ANCHOR_SCOPE_ERROR and stop.
8. Verify the anchor. If batchAnchor is present, recompute the
Merkle root per Section 7.9 and verify the proof over the root;
otherwise verify the proof over the artifact hash directly. On
failure report BATCH_PROOF_INVALID or OTS_VERIFICATION_FAILED
and stop. Compare the confirmed block height with the recorded
one, reporting BLOCK_HEIGHT_MISMATCH on disagreement. The
token has reached C1.
9. Resolve the DOI and confirm metadata and file presence. On
failure report DOI_UNRESOLVABLE. The token has reached C2.
10. Compute SHA3-512 and BLAKE3 and compare. Attempt IPFS and web
archival retrieval. If all match and at least one further
layer is retrievable, the token has reached C3.
Reilly Expires 10 March 2027 [Page 78]
Internet-Draft REM License Token (RLT) September 2026
11. If canonicalization and recordDigest are present, recompute and
compare, reporting RECORD_DIGEST_MISMATCH on failure. If a
signature is present, retrieve the key and verify, reporting
SIGNATURE_KEY_UNAVAILABLE or SIGNATURE_INVALID as appropriate.
If both succeed, the token has reached C4.
12. Verify any bridging records and any disclosed commitments,
reporting BRIDGE_INVALID or COMMITMENT_MISMATCH on failure.
13. Report the highest level reached, the reason the next level was
not reached, and the token state.
Appendix J. Example RLT Token v2.1
The following adds the version 2.1 members of Section 5.4 to the
example of Appendix A. Only the additional members are shown; all
Appendix A members are also present in a complete token. All
values are illustrative.
{
"rltVersion": "2.1",
"schemaDate": "2026-09-06",
"remMas": {
"suite": "B",
"algorithms": ["SHA-256", "SHA3-512", "BLAKE3"]
},
"anchorScope": {
"coveredFile": "example-rem-artifact-v1.0.pdf",
"byteLength": 481233,
"coverage": "single-file"
},
"canonicalization": {
"profile": "RLT-JCS-1",
"recordDigestAlg": "SHA-256"
},
"recordDigest":
"3f1c0a9d7e5b2648a0c3d5f7091b3d5f7a9c1e3d5f7091b3d5f7a9c1e3d5f709",
Reilly Expires 10 March 2027 [Page 79]
Internet-Draft REM License Token (RLT) September 2026
"commitments": {
"alg": "SHA-256",
"fields": {
"/author/email":
"8a2d4f6b0c1e3a5d7f9b1d3f5a7c9e1b3d5f7a9c1e3d5f7b9d1f3a5c7e9b1d3f"
}
},
"batchAnchor": {
"merkleRoot":
"c4e6a8b0d2f4160820a4c6e8fa1c3e507294b6d8fa1c3e5072b4d6f8a0c2e416",
"leafIndex": 12,
"treeSize": 64,
"inclusionProof": [
"1a3c5e7092b4d6f8a0c2e4160b2d4f6981a3c5e7092b4d6f8a0c2e416082a4c6",
"9b1d3f5a7c9e1b3d5f7a9c1e3d5f7091b3d5f7a9c1e3d5f7091b3d5f7a9c1e3d"
],
"proofUrl":
"https://zenodo.org/records/XXXXXXXX/files/batch-proof.json"
},
"anchorState": "ATTESTED",
"bridging": [],
"status": {
"statusUrl":
"https://zenodo.org/records/XXXXXXXX/files/status.json",
"registry":
"https://zenodo.org/records/XXXXXXXX/files/revocations.json"
},
"priorArt": {
"mode": "public-deposit",
"publiclyAccessibleAt": "2026-09-06",
"depositUrl": "https://zenodo.org/records/XXXXXXXX"
},
"conformance": "C4",
"signature": {
"type": "COSE_Sign1",
"value": "<base64url COSE_Sign1 structure>",
"keyId": "https://example.org/keys/rlt-signing-2026.json"
}
}
Reilly Expires 10 March 2027 [Page 80]
Internet-Draft REM License Token (RLT) September 2026
Note that author.email is null in the published token because it is
committed in commitments.fields; the value and its salt are held by
the issuer and disclosed on request per Section 5.6.
Appendix K. Conformance Checklist
An issuer preparing a version 2.1 token can work through the
following. Each item cites the section that states the
requirement.
Before anchoring:
o The artifact is final and will not be touched again
(Section 6.1).
o The hashes cover exactly one file, and that file is named in
artifact.filename (Section 4.4).
o Nothing is being anchored in cleartext that could later have to
be erased (Sections 9.11 and 11.8).
Anchoring:
o All three REM-MAS digests computed and recorded (Section 6.2).
o OTS proof upgraded and verified, block height recorded, and
anchorState set to ATTESTED (Sections 6.3 and 6.10).
o Artifact, proof, and manifest deposited and a DOI obtained
(Section 6.4).
o At least one further layer applied: IPFS pin or web archive
snapshot (Sections 6.5 and 6.6).
Token assembly:
o tokenId is a UUID conforming to [RFC9562]; all dates conform to
[RFC3339] (Section 5.5).
o anchorScope recorded with the correct byte length (Section 5.4).
o Any withheld field committed with a fresh 128-bit salt, and
none of the prohibited fields committed (Section 5.6).
o recordDigest computed last, after every other field is final
(Section 5.5).
Reilly Expires 10 March 2027 [Page 81]
Internet-Draft REM License Token (RLT) September 2026
o Signature produced over the canonical form, and the public key
published at signature.keyId (Section 5.7).
After publication:
o A status record is published and will stay resolvable
(Section 8.7).
o The claimed conformance level has been verified independently
rather than asserted (Section 7.7).
o No claim is made for the token beyond what Section 11.11 says it
establishes.
Author's Address
Lawrence John Reilly Jr
REM Technologies & Consulting, LLC
United States of America
Email: lawrencejohnreilly@gmail.com
Reilly Expires 10 March 2027 [Page 82]