Network Working Group K. Singh Internet-Draft Apex Intelligence Empire Intended status: Informational 10 August 2026 Expires: 11 February 2027 PSI-06: Inception-Lock Protocol for Human-Originated Data Signals draft-singh-apex-psi-06-01 Abstract PSI-06 specifies an inception-lock protocol that cryptographically anchors a raw human-originated data signal (keystroke, biometric, survey response, application screen capture, trip acceptance timestamp) to a signing key at the point of capture. The protocol prevents tampering with source data between capture and submission, enabling verifiable proof of what a user was shown and when they saw it. Receipts are protected by a hybrid dual-signature scheme combining Ed25519 (classical) and ML-DSA-65 (post-quantum), making the evidence chain resistant to both classical and quantum adversaries. This is critical for accountability proceedings involving algorithmic platforms, where the information displayed to the user may differ from the information recorded by the platform. 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 11 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Singh Expires 11 February 2027 [Page 1] Internet-Draft PSI-06 Inception-Lock Protocol August 2026 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 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Receipt Format . . . . . . . . . . . . . . . . . . . . . . . 3 5. Verification . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Use Case: Algorithmic Platform Accountability . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Human-originated data is the most vulnerable point in any integrity chain. When a platform displays a time estimate of "55 min, $25" without qualifying language such as "estimated", the user's experience of that moment diverges from the platform's later recorded data. PSI-06 defines an inception-lock that signs the signal at the point of capture, before any processing or storage, enabling the user to prove what they saw and when. This has direct application to algorithmic accountability proceedings. In the case of gig-economy dispatch platforms, workers accept task offers based on displayed time and earnings estimates. The platform's recorded data may differ from what was displayed. The inception-lock protocol closes this evidentiary gap with a receipt that the platform cannot alter. 2. Requirements Language 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. Singh Expires 11 February 2027 [Page 2] Internet-Draft PSI-06 Inception-Lock Protocol August 2026 3. Protocol The capture device MUST: 1. Canonicalise the raw signal with RFC 8785 (JCS). 2. Sign the canonicalised signal with an Ed25519 key provisioned in hardware or in a trusted execution environment. 3. Sign the same canonicalised signal with an ML-DSA-65 post-quantum key, forming a hybrid dual signature. 4. Emit an inception-lock receipt before returning control to the capturing application. The receipt MUST include: * signal_digest: SHA-256 of the canonicalised signal. * device_id: hardware-bound public key fingerprint. * captured_at: RFC 3339 timestamp with microsecond precision. * application_id: identifier of the capturing application. * display_hash: SHA-256 of the screen content at capture time. * signature_classical: Ed25519 signature over all preceding fields. * signature_pq: ML-DSA-65 signature over all preceding fields. 4. Receipt Format { "psi": "06", "signal_digest": "", "device_id": "", "captured_at": "", "application_id": "", "display_hash": "", "signature_classical":"", "signature_pq": "" } Singh Expires 11 February 2027 [Page 3] Internet-Draft PSI-06 Inception-Lock Protocol August 2026 5. Verification A verifier MUST recompute the SHA-256 digest over the canonicalised signal and validate BOTH signatures. A receipt failing either signature check MUST be treated as unsealed and MUST NOT be admitted into an integrity chain. Implementations MAY additionally anchor the receipt digest in a public PSI-04 ledger to obtain an independent third-party timestamp. 6. Use Case: Algorithmic Platform Accountability When a gig-economy worker accepts a task offer, the application displays time and earnings figures. The inception-lock captures: * The displayed time estimate (e.g., "55 min"). * The displayed earnings estimate (e.g., "$25"). * The absence of qualifying language (e.g., "estimated", "approximately"). * The exact timestamp of acceptance. This creates a cryptographically verifiable record of what the worker was shown at the moment of decision. The platform's internal records of what was displayed can be compared against the inception-locked evidence; discrepancies become provable in formal proceedings. Because the receipt carries a hybrid dual signature, the evidence chain remains valid across the post-quantum transition horizon of such proceedings. 7. Security Considerations The inception key MUST reside in hardware-backed secure storage (TPM 2.0, Secure Enclave, or equivalent). Software-only keys are acceptable for evidentiary purposes but MUST be disclosed to the trier of fact. The hybrid scheme protects against harvest-now, decrypt-later adversaries: the ML-DSA-65 signature remains valid even if Ed25519 is later broken by cryptographically relevant quantum computers. The protocol does not prevent the platform from altering its internal records. It creates an independent chain of evidence that the platform cannot alter. Singh Expires 11 February 2027 [Page 4] Internet-Draft PSI-06 Inception-Lock Protocol August 2026 8. Privacy Considerations The inception-lock receipt contains no personally identifying information beyond the device identifier. Implementations SHOULD support pseudonymous device identifiers that cannot be linked to a natural person without additional information held solely by the user. 9. IANA Considerations This document has no IANA actions. 10. References [FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard", August 2024, . [PSI04] Singh, K., "PSI-04: Evidentiary Document Integrity", July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . Author's Address Kawaljeet Singh Apex Intelligence Empire Balaclava, Victoria Australia Email: kawaljeet.singh3008@gmail.com URI: https://apex-infrastructure.com Singh Expires 11 February 2027 [Page 5]