Lockb0x LLC

contact@steventomlinson.dev

Security Independent Submission This document specifies the Lockb0x Protocol, a standards-based framework for creating Codex Entries (machine-readable Controllable Electronic Records) that bind together storage proofs, blockchain anchors, encryption metadata, signatures, and provenance. The protocol enables interoperability across decentralized and cloud storage systems while providing auditability and compliance with legal frameworks such as UCC Article 12.

The Lockb0x Protocol defines a mechanism for verifiable data provenance and sovereignty across heterogeneous storage backends and blockchains. This Internet-Draft provides a reference specification.

The Lockb0x Protocol defines a verification and provenance layer for digital data. It is not a storage protocol; rather, it operates with existing storage and blockchain systems to provide integrity, custodianship, and auditability. Objectives of the protocol include:

• Data Sovereignty: demonstrating control over how and where data is stored.
• Compliance: enabling a verifiable chain of custody applicable to frameworks such as UCC Article 12 in the United States and GDPR in the European Union.
• Cross-Organization Trust: allowing independent parties to verify shared data without relying on a central authority.

The protocol introduces a Codex Entry abstraction that unifies storage proofs, cryptographic signatures, identity bindings, and blockchain anchors in a consistent, verifiable format.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in .

• Codex Entry: A structured, signed data object that encapsulates integrity proofs, storage references, anchors, identity bindings, and optional encryption metadata.
• Storage Adapter: A module that interfaces with an external storage system (e.g., IPFS, S3, GCS, Azure, Solid Pod) and produces verifiable proofs of storage.
• Anchor: A blockchain transaction or equivalent immutable record that cryptographically attests to the existence of a Codex Entry at a specific point in time.
• Verifier: A tool or process that checks the validity of a Codex Entry by verifying signatures, integrity proofs, storage claims, and anchors.
• Certificate: A human- or machine-readable document generated from a Codex Entry that provides evidence of integrity, custodianship, and anchoring. Formats MAY include JSON, W3C Verifiable Credentials, or X.509.
• Identity Context: Identifiers bound to a Codex Entry that describe the controlling party (individual, entity, or asset) and optional hierarchy fields (org, process, artifact). An additional subject field MAY be included to represent an individual, entity, or asset referenced by the entry.
• Encryption Metadata: Information included in a Codex Entry when assets are encrypted, specifying algorithm, key identifiers, and the last_controlled_by field.

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 when, and only when, they appear in all capitals, as shown here.

The Lockb0x Protocol defines a structured JSON object called a Codex Entry. This is the fundamental unit of the protocol, capturing proofs of integrity, storage, identity, and blockchain anchoring. The full normative Codex Entry is provided in Appendix B. This section provides only an overview of the object structure and its role in the protocol. See the specification for required and optional fields, key ownership semantics, and revision chains. UUIDs MUST conform to .

Storage Adapters translate provider-specific metadata into canonical proofs (e.g., ni-URIs). Supported adapters include IPFS, S3, GCS, Azure Blob, and Solid Pods. Each adapter defines:

• Protocol identifier (e.g., "ipfs", "s3", "solid")
• Method for computing integrity proof
• Required metadata fields (e.g., region, jurisdiction, provider)

Anchoring links a Codex Entry to an immutable, time-stamped record on a blockchain or equivalent ledger. Anchors MUST be created before certificates are issued. Signatures MAY be applied before or after anchoring, but certificates MUST bind both signatures and the anchor. Required fields: chain (), tx_hash, hash_alg. Optional: token_id (NFT anchor).

Verification requires recomputing integrity proofs, validating signatures, and confirming anchors. Verifiers MUST implement JSON canonicalization. Automated verifiers MAY be smart contracts.

Certificates provide human/machine-readable evidence derived from Codex Entries. Formats: JSON, W3C VC, X.509. Certificates MUST bind to anchor transaction IDs, integrity proofs, and signatures. They MAY include expiry or revocation metadata.

Codex Entry Schema Reference { ... see appendix-b-schema.md for full JSON Schema ... }

End-to-end flows for Codex Entries:

1. File -> Codex Entry -> Stellar Anchor -> Verification
2. IPFS Example
3. S3 Example
4. Google Cloud Storage Example
5. Solid Pod Example
6. Multi-Sig Control Flow
7. Revision Chain Flow

(Full example flows are provided in Appendix A.)

Detailed scenarios include: key compromise, malicious storage providers, replay attacks, hash collisions, false jurisdiction claims, insider threats, denial-of-service, and post-quantum risks. Mitigations include HSMs, multi-sig, canonicalization, crypto-agility, and redundant anchors.

Security considerations for the Lockb0x Protocol are discussed in detail in the "Security Threat Models" section. Implementers should review the threat scenarios and recommended mitigations, including the use of HSMs, multi-signature controls, canonicalization, and crypto-agility. Additional risks may arise from improper implementation or integration with external systems.

This document makes no request of IANA.

Normative References IETF JSON Schema Chain Agnostic Standards Alliance

Version -01: Revives the draft following expiration of version -00. No significant technical changes to the protocol were made in this version; it was submitted to maintain active status for ongoing discussion.

This appendix contains the full JSON Schema for Codex Entries. This schema is normative and defines required and optional fields, their types, and constraints.

Codex Entry Full JSON Schema