PSI-06: Inception-Lock Protocol for Human-Originated Data Signals

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.¶

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

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.¶

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":      "<sha256 hex>",
  "device_id":          "<hardware-bound public key fingerprint>",
  "captured_at":        "<RFC 3339 microsecond precision>",
  "application_id":     "<app bundle identifier>",
  "display_hash":       "<sha256 hex of screen content>",
  "signature_classical":"<Ed25519 base64url>",
  "signature_pq":       "<ML-DSA-65 base64url>"
}

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.¶

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.¶

Author's Address