<?xml version="1.0" encoding="utf-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-singh-psi-age-assurance-01" ipr="trust200902" submissionType="IETF" version="3" xml:lang="en">
<front><title abbrev="PSI-Age">PSI Age Assurance Decision Receipts</title>
<seriesInfo name="Internet-Draft" value="draft-singh-psi-age-assurance-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-Age, a domain profile of Proof of Stateful Integrity (PSI) for age assurance decisions, so that a relying party can later show which provider decision it relied on. This document is superseded in substance by draft-singh-apex-psi-09 and is retained only for continuity.  Each record is sealed as a PSI receipt so that later alteration, reordering, or removal is detectable.  Only digests are sealed.  PSI-Age shows integrity and ordering only; it does not show the age of any person, the accuracy of the method, or compliance with any age assurance law.</t>
<t>The title of revision 00 claimed a zero-knowledge construction. No zero-knowledge proof system is specified; the claim is withdrawn.</t></abstract></front>
<middle>
<section><name>Introduction</name><t>This profile applies the receipt format of <xref target="PSI"/> to one record type.  The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>SHOULD</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>Record Profile</name><t>A record is a JSON object that MUST contain the following members and MAY contain others:</t><ul><li>subject_ref, an opaque one-time identifier</li><li>method_ref</li><li>outcome</li><li>salt, at least 128 bits of randomness</li></ul>
<t>The record holder computes the record digest per <xref target="PSI"/> and submits only the digest for sealing.  Records SHOULD NOT contain personal data.</t></section>
<section><name>Verification</name><t>A verifier given a record and its receipt verifies the receipt per <xref target="PSI"/>.  Verification reports digest match and signature validity only.</t></section>
<section><name>Security Considerations</name><t>The considerations of <xref target="PSI"/> apply.  A record that was false when sealed remains false; a record that was never sealed is not detected as missing unless records are chained.</t></section>
<section><name>IANA Considerations</name><t>This document has no IANA actions.</t></section>
</middle>
<back><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></back></rfc>