<?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="info"
     docName="draft-watts-ai-identity-conformance-00"
     ipr="trust200902"
     submissionType="IETF"
     version="3">
  <front>
    <title abbrev="AID-1-TEST">AID-1 Provider-Independent Conformance Requirements and Test-Vector Model</title>
    <seriesInfo name="Internet-Draft" value="draft-watts-ai-identity-conformance-00"/>
    <author fullname="Deonte Watts" initials="D." surname="Watts">
      <organization>Independent Researcher</organization>
      <address>
        <email>deonte@goodshyt.fun</email>
        <uri>https://orcid.org/0009-0005-8586-3650</uri>
      </address>
    </author>
    <date year="2026" month="September"/>
    <area>Security</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>AID-1</keyword>
    <keyword>conformance</keyword>
    <keyword>test vectors</keyword>
    <keyword>identity</keyword>
    <keyword>provenance</keyword>
    <keyword>replay</keyword>
    <abstract>
      <t>
        This document defines provider-independent conformance requirements for
        AID-1.  It specifies the execution model for a deterministic
        machine-readable test-vector corpus, including canonicalization,
        cryptographic, identity-binding, delegation, authorization, temporal,
        revocation, replay, attestation, provenance, and integration cases.
        The conformance corpus contains 69 vectors.  Six replay cases are
        architectural boundary tests, including R5, which requires AID-1
        verification to succeed while a downstream D6 scientific-admissibility
        decision rejects the same evidence.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <t>
        AID-1 is intentionally independent of software-only, TPM, TEE, HSM,
        enclave, cloud, or other implementation providers.  Conformance
        therefore depends on observable verification behavior rather than
        implementation mechanism.
      </t>
      <t>
        This document defines the semantic contract for the AID-1-TEST
        machine-readable corpus and its reference vector runner.
      </t>
    </section>

    <section anchor="requirements">
      <name>Conformance Requirements</name>
      <t>
        An implementation claiming conformance to AID-1 MUST execute the
        complete required vector corpus and MUST produce the expected outcome
        for every required vector.
      </t>
      <t>
        The provider under test MUST NOT receive privileged knowledge of the
        expected result beyond the ordinary input data supplied to an AID-1
        verifier.
      </t>
      <t>
        The same vector corpus MUST be usable without semantic modification
        against SoftwareProvider, MockTPMProvider, MockTEEProvider, and future
        provider implementations.
      </t>
    </section>

    <section anchor="corpus">
      <name>Machine-Readable Corpus</name>
      <t>
        The AID-1-TEST v1 corpus contains 69 deterministic vectors.  Each vector
        SHOULD contain, directly or by stable reference, a base fixture,
        mutation or transformation, expected verification outcome, expected
        failure codes where applicable, and any downstream boundary
        expectations.
      </t>
      <artwork><![CDATA[
aid-1-test-vectors/
  manifest.json
  schema/
    vector.schema.json
    manifest.schema.json
  fixtures/
    identities/
    keys/
    delegations/
    authorizations/
    attestations/
    provenance/
  vectors/
    schema/
    canonicalization/
    crypto/
    identity/
    delegation/
    authorization/
    temporal/
    revocation/
    replay/
    attestation/
    provenance/
    integration/
  replay/
    R1.json
    R2.json
    R3.json
    R4.json
    R5.json
    R6.json
      ]]></artwork>
      <t>
        The machine-readable corpus is the executable test artifact.  This
        document specifies the semantics required for interpreting that corpus.
      </t>
    </section>

    <section anchor="vector-model">
      <name>Vector Execution Model</name>
      <t>
        A reference runner SHOULD evaluate each vector using the following
        conceptual process:
      </t>
      <artwork><![CDATA[
base fixture
     +
specified mutation
     |
     v
deterministic candidate object
     |
     v
AID-1 verifier
     |
     v
actual decision
     |
     v
expected decision
     |
     v
PASS / FAIL
      ]]></artwork>
      <t>
        A mutation MUST be deterministic.  A runner MUST NOT modify fields that
        are outside the mutation specified by the vector.
      </t>
    </section>

    <section anchor="outcomes">
      <name>Expected Outcomes</name>
      <t>
        A vector MAY expect ALLOW, DENY, or INDETERMINATE.  A vector MAY also
        expect one or more standardized failure codes.
      </t>
      <t>
        INDETERMINATE MUST NOT be treated as equivalent to ALLOW for conformance
        purposes.
      </t>
    </section>

    <section anchor="coverage">
      <name>Required Coverage</name>
      <t>The corpus MUST include vectors covering at least:</t>
      <ul>
        <li>JCS canonicalization and rejection of unsupported values;</li>
        <li>Ed25519 positive and negative signature verification;</li>
        <li>tampered-envelope rejection;</li>
        <li>key-substitution rejection;</li>
        <li>identity binding independent from a self-supplied key;</li>
        <li>capability, resource, state, time, and delegation enforcement;</li>
        <li>revoked and unavailable revocation states;</li>
        <li>duplicate nonce and action replay;</li>
        <li>forged or untrusted external attestation;</li>
        <li>key rotation, overlap, supersession, and historical validity;</li>
        <li>audit-chain deletion, reordering, and mutation detection; and</li>
        <li>confused-deputy, audience-confusion, cross-repository replay, delegation-escalation, and stale-credential cases.</li>
      </ul>
    </section>

    <section anchor="replay-cases">
      <name>Replay and Architectural Boundary Cases</name>
      <t>
        Six replay cases, R1 through R6, are reserved as architecture-level
        conformance cases.  These cases are intended to detect accidental
        collapse of trust domains across implementations.
      </t>

      <section anchor="r5">
        <name>R5: AID-1 Valid, D6 Reject</name>
        <t>
          R5 is a mandatory conformance invariant.
        </t>
        <artwork><![CDATA[
AID-1 verification: VALID
D6 scientific-admissibility decision: REJECT
        ]]></artwork>
        <t>
          An implementation MUST pass R5 by preserving the distinction between
          AID-1 identity/provenance verification and downstream scientific
          admissibility.
        </t>
        <t>
          A provider or integration that automatically converts successful
          AID-1 verification into downstream D6 acceptance is non-conformant.
        </t>
      </section>
    </section>

    <section anchor="provider">
      <name>Provider Independence</name>
      <t>
        A provider implementation MAY use software keys, TPM-backed keys,
        TEE-backed keys, HSMs, secure enclaves, or future mechanisms.  The
        provider MUST expose behavior compatible with the AID-1 verifier and
        MUST preserve the same externally observable decision semantics.
      </t>
      <t>
        Provider-specific implementation details MUST NOT alter the expected
        outcome of any provider-independent vector.
      </t>
    </section>

    <section anchor="runner">
      <name>Reference Vector Runner</name>
      <t>
        The reference runner SHOULD load the corpus manifest, validate each
        vector against its schema, construct the candidate object, execute the
        AID-1 verifier, compare actual and expected outcomes, and emit a
        deterministic report.
      </t>
      <t>
        The reference runner SHOULD report at least the vector identifier,
        actual decision, expected decision, observed failure codes, expected
        failure codes, and PASS or FAIL status.
      </t>
    </section>

    <section anchor="release-gates">
      <name>Release Gates</name>
      <t>
        An implementation MUST NOT claim completion of the AID-1 v1 security
        conformance profile until the required gates pass.  These gates include:
      </t>
      <ol>
        <li>JCS conformance and rejection tests;</li>
        <li>Ed25519 positive, negative, tampered-envelope, and key-substitution vectors;</li>
        <li>identity-binding separation from self-supplied key material;</li>
        <li>independent authorization checks for capability, resource, state, time, and delegation;</li>
        <li>revocation and unavailable-registry handling;</li>
        <li>replay resistance;</li>
        <li>external attestation verification;</li>
        <li>rotation and historical-verification behavior;</li>
        <li>audit-integrity checks; and</li>
        <li>adversarial trust-boundary vectors.</li>
      </ol>
    </section>

    <section anchor="security">
      <name>Security Considerations</name>
      <t>
        A conformance suite is security-sensitive because a weak oracle can
        certify incorrect behavior.  The corpus, manifest, schemas, and runner
        SHOULD therefore be content-addressed or otherwise integrity protected.
      </t>
      <t>
        Test providers MUST NOT be permitted to alter vector expectations during
        execution.  CI systems SHOULD pin the corpus revision used for a
        conformance claim.
      </t>
    </section>

    <section anchor="privacy">
      <name>Privacy Considerations</name>
      <t>
        Conformance fixtures SHOULD use synthetic identities, synthetic
        credentials, and non-production attestation material unless a test
        explicitly requires otherwise.  Real personal credentials, production
        secrets, and live private keys MUST NOT be distributed in the public
        corpus.
      </t>
    </section>

    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document requests no IANA actions.</t>
    </section>

    <section anchor="publication">
      <name>Publication and Versioning</name>
      <t>
        The 69-vector corpus SHOULD be versioned independently but SHOULD declare
        the AID-1 specification revision against which it is evaluated.
        Published conformance reports SHOULD identify both the corpus revision
        and the implementation revision.
      </t>
    </section>
  </middle>

  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="AID1">
        <front>
          <title>AID-1: A Cryptographically Bindable Identity and Provenance Architecture for AI Systems</title>
          <author initials="D." surname="Watts" fullname="Deonte Watts"/>
          <date year="2026" month="September"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-watts-ai-identity-00"/>
      </reference>
      <reference anchor="RFC8785" target="https://www.rfc-editor.org/rfc/rfc8785">
        <front>
          <title>JSON Canonicalization Scheme (JCS)</title>
          <author initials="A." surname="Rundgren" fullname="Anders Rundgren"/>
          <author initials="B." surname="Jordan" fullname="Bryan Jordan"/>
          <author initials="S." surname="Erdtman" fullname="Samuel Erdtman"/>
          <date year="2020" month="June"/>
        </front>
        <seriesInfo name="RFC" value="8785"/>
      </reference>
    </references>
  </back>
</rfc>
