<?xml version="1.0" encoding="utf-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="info" docName="draft-singh-apex-psi-04-01" ipr="trust200902"
     submissionType="IETF" version="3" xml:lang="en"
     consensus="false">
  <front>
    <title abbrev="PSI-04">PSI-04: State-Chain Receipts for Records Concerning Vulnerable Persons</title>
    <seriesInfo name="Internet-Draft" value="draft-singh-apex-psi-04-01"/>
    <author fullname="Kawaljeet Singh" initials="K." surname="Singh">
      <organization>APEX Infrastructure</organization>
      <address>
        <postal><city>Melbourne</city><region>Victoria</region><country>Australia</country></postal>
        <email>kawaljeet.singh3008@gmail.com</email>
        <uri>https://ai-governance-standard.com</uri>
      </address>
    </author>
    <date year="2026" month="October" day="13"/>
    <abstract>
      <t>This document defines PSI-04, a domain profile of Proof of
      Stateful Integrity (PSI) for records about vulnerable persons, such
      as clinical-trial participants and recipients of disability or aged
      care services.  PSI-04 seals each state transition of a record as a
      PSI receipt chained to the previous one, so that later alteration
      or omission of a transition is detectable.  Only digests are
      sealed; no personal data leaves the record holder.  PSI-04 shows
      integrity and ordering only and does not show that care was
      adequate or that any regulation was met.</t>
      <t>This revision withdraws the multi-party computation and
      zero-knowledge claims of revision 00 and the request for a URI
      scheme.</t>
    </abstract>
  </front>
  <middle>
    <section><name>Introduction</name>
      <t>Records about vulnerable persons are often reviewed long after
      they are written, and disputes turn on whether entries were
      changed after the fact.  PSI-04 applies the receipt format of
      <xref target="PSI"/> to each transition so a reviewer can check
      that the chain they see is the chain that was sealed.</t>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
      "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", and
      "<bcp14>MAY</bcp14>" in this document are to be interpreted as
      described in BCP&#160;14 <xref target="RFC2119"/>
      <xref target="RFC8174"/> when, and only when, they appear in all
      capitals, as shown here.</t>
    </section>
    <section><name>State-Chain Profile</name>
      <t>Each transition is a JSON object with members subject_ref,
      state, actor_ref, prev_transition_hash, and salt.</t>
      <ul>
        <li>subject_ref and actor_ref MUST be opaque pseudonymous
        identifiers held by the record holder; they MUST NOT be names,
        dates of birth, or government identifiers.</li>
        <li>salt MUST be at least 128 bits of fresh randomness, so the
        digest cannot be reversed by guessing.</li>
        <li>prev_transition_hash MUST be the PSI record digest of the
        previous transition for the same subject_ref, or 64 zero
        characters for the first.</li>
      </ul>
      <t>The record holder computes the record digest per
      <xref target="PSI"/> and submits only the digest for sealing.</t>
    </section>
    <section><name>Verification</name>
      <t>A reviewer given the transitions and receipts verifies each
      receipt per <xref target="PSI"/> and checks that every
      prev_transition_hash equals the digest of its predecessor.  A
      missing, reordered, or altered transition causes a mismatch.</t>
    </section>
    <section><name>Security Considerations</name>
      <t>The considerations of <xref target="PSI"/> apply.  In addition,
      PSI-04 cannot detect a false entry sealed at the time it was
      made, nor transitions that were never sealed.  Linking a
      pseudonymous reference to a person relies entirely on the record
      holder's own controls.</t>
    </section>
    <section><name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references><name>References</name>
      <references><name>Normative References</name>
        <reference anchor="PSI" target="https://datatracker.ietf.org/doc/draft-singh-psi/">
          <front><title>Proof of Stateful Integrity (PSI): Signed, Merkle-Committed Receipts for Digital Records</title>
          <author initials="K." surname="Singh"/><date year="2026" month="October"/></front>
          <seriesInfo name="Internet-Draft" value="draft-singh-psi-02"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front><title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner"/><date year="1997" month="March"/></front>
          <seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front><title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba"/><date year="2017" month="May"/></front>
          <seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="8174"/>
        </reference>
      </references>
    </references>
  </back>
</rfc>
