Network Working Group                                         L. J. Reilly
Internet-Draft                                             November 16, 2025
Intended status: Informational
Expires: May 16, 2026

                 REM License Token (RLT) - Genesis Artifact
                      draft-reilly-rlt-genesis-00

November 16, 2025

Abstract

   This document defines the REM License Token, referred to as the RLT,
   as the genesis artifact of the Reilly EternaMark Protocol for digital
   permanence and verifiable provenance. This specification formally
   defines the token structure, issuance procedures, cryptographic hash
   requirements, blockchain anchoring requirements, DOI archival
   requirements, verification methodology, and security model. The RLT
   represents an implementation of a dual-layer permanence artifact
   combining a blockchain timestamp with DOI-based archival to achieve
   durable, tamper-evident provenance guarantees. 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.

   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 16 May 2026.

Copyright Notice

   Copyright (c) 2025 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
   2. Terminology
   3. Background and Rationale
   4. RLT Genesis Artifact Definition
   5. Token Format and JSON Schema
   6. Issuance and Anchoring Requirements
   7. Verification Requirements
   8. Security Considerations
   9. IANA Considerations
   10. References
        10.1 Normative References
        10.2 Informative References
   Appendix A. Example RLT Token
   Appendix B. Change Log

1. Introduction

   The Reilly EternaMark Protocol defines a dual-layer digital
   permanence model. This model binds cryptographic timestamping on a
   public blockchain with academic-grade DOI archival. The REM License
   Token is the first artifact created using this model. This document
   specifies that artifact in a manner consistent with IETF
   documentation practices, so that it can be implemented, evaluated,
   and extended by independent parties.

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 (RFC 2119 and RFC 8174).

   RLT: REM License Token
   REM: Reilly EternaMark Protocol
   DOI: Digital Object Identifier
   OTS: OpenTimestamps proof file
   DAR: Digital Archival Record

3. Background and Rationale

   Intellectual property, authorship, and digital provenance frequently
   require durable, independently verifiable records. Traditional
   systems rely on centralized registries, contractual agreements, or
   proprietary evidence that may not be globally accessible or
   cryptographically strong.

   The REM Protocol introduces a method for creating tamper-evident
   digital records by combining:

   1. A SHA-256 hash of the artifact to be protected.
   2. A public blockchain timestamp anchoring the hash.
   3. A DOI archival record storing the artifact, metadata, and proofs.

4. RLT Genesis Artifact Definition

   The REM License Token binds together:

   * Author identity information
   * SHA-256 hash of the reference document
   * Blockchain timestamp proof
   * DOI archival reference
   * Token issuance metadata

   The canonical REM License Token genesis artifact is archived under:

      DOI 10.5281/zenodo.17438760

   Metadata Date: November 16, 2025

   SHA-256:
      9964A78C6FC33794EF840ED69045C5C2477BC611CBC73EF6EC537FACA4C7BB74

   Blockchain Anchor:
      Bitcoin Block Height 914168

5. Token Format and JSON Schema

   {
     "rltVersion": "1.0",
     "tokenId": "<unique-id>",
     "author": {
       "name": "Lawrence J. Reilly",
       "ORCID": "<optional>",
       "affiliation": "<optional>"
     },
     "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"
   }

6. Issuance and Anchoring Requirements

   The issuance process MUST include:
   1. Compute SHA-256 hash.
   2. Obtain OpenTimestamps proof.
   3. Confirm blockchain anchor.
   4. Upload artifact + proof to DOI archive.
   5. Receive DOI.
   6. Create JSON token.
   7. Publish token.

7. Verification Requirements

   A verifier MUST:
   * Retrieve JSON token.
   * Retrieve DOI metadata.
   * Hash reference document and compare.
   * Validate OTS proof.
   * Confirm DOI availability.

8. Security Considerations

   Security relies on:
   * SHA-256 integrity
   * Blockchain immutability
   * DOI archival persistence
   * Author identity correctness

9. IANA Considerations

   This document has no IANA actions.

10. References

10.1 Normative References

   RFC2119
   RFC8174

10.2 Informative References

   draft-reilly-rem-protocol-00
   DOI 10.5281/zenodo.17438760

Appendix A. Example RLT Token

   {
     "rltVersion": "1.0",
     "tokenId": "example-uuid-0000",
     "author": { "name": "Lawrence J. Reilly" },
     "license": "CC_BY_4.0",
     "hash": "9964A78C6FC33794EF840ED69045C5C2477BC611CBC73EF6EC537FACA4C7BB74",
     "blockchain": { "chain": "Bitcoin", "blockHeight": 914168 },
     "doi": "10.5281/zenodo.17438760"
   }

Appendix B. Change Log

   draft-reilly-rlt-genesis-00
   * Initial version with corrected IETF-compliant document date.

Author's Address

   Lawrence J. Reilly
   Email: lawrencejohnreilly@gmail.com
