Skip to main content

AID-1 Provider-Independent Conformance Requirements and Test-Vector Model
draft-watts-ai-identity-conformance-00

Document Type Active Internet-Draft (individual)
Author Deonté Watts
Last updated 2026-09-01
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-watts-ai-identity-conformance-00
Internet Engineering Task Force                                 D. Watts
Internet-Draft                                    Independent Researcher
Intended status: Informational                            September 2026
Expires: 5 March 2027

  AID-1 Provider-Independent Conformance Requirements and Test-Vector
                                 Model
                 draft-watts-ai-identity-conformance-00

Abstract

   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.

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 5 March 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

Watts                     Expires 5 March 2027                  [Page 1]
Internet-Draft                 AID-1-TEST                 September 2026

   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.  Conformance Requirements  . . . . . . . . . . . . . . . . . .   2
   3.  Machine-Readable Corpus . . . . . . . . . . . . . . . . . . .   3
   4.  Vector Execution Model  . . . . . . . . . . . . . . . . . . .   4
   5.  Expected Outcomes . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Required Coverage . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Replay and Architectural Boundary Cases . . . . . . . . . . .   5
     7.1.  R5: AID-1 Valid, D6 Reject  . . . . . . . . . . . . . . .   5
   8.  Provider Independence . . . . . . . . . . . . . . . . . . . .   5
   9.  Reference Vector Runner . . . . . . . . . . . . . . . . . . .   6
   10. Release Gates . . . . . . . . . . . . . . . . . . . . . . . .   6
   11. Security Considerations . . . . . . . . . . . . . . . . . . .   6
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   14. Publication and Versioning  . . . . . . . . . . . . . . . . .   7
   15. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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.

   This document defines the semantic contract for the AID-1-TEST
   machine-readable corpus and its reference vector runner.

2.  Conformance Requirements

   An implementation claiming conformance to AID-1 MUST execute the
   complete required vector corpus and MUST produce the expected outcome
   for every required vector.

   The provider under test MUST NOT receive privileged knowledge of the
   expected result beyond the ordinary input data supplied to an AID-1
   verifier.

   The same vector corpus MUST be usable without semantic modification
   against SoftwareProvider, MockTPMProvider, MockTEEProvider, and
   future provider implementations.

Watts                     Expires 5 March 2027                  [Page 2]
Internet-Draft                 AID-1-TEST                 September 2026

3.  Machine-Readable Corpus

   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.

   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

   The machine-readable corpus is the executable test artifact.  This
   document specifies the semantics required for interpreting that
   corpus.

Watts                     Expires 5 March 2027                  [Page 3]
Internet-Draft                 AID-1-TEST                 September 2026

4.  Vector Execution Model

   A reference runner SHOULD evaluate each vector using the following
   conceptual process:

   base fixture
        +
   specified mutation
        |
        v
   deterministic candidate object
        |
        v
   AID-1 verifier
        |
        v
   actual decision
        |
        v
   expected decision
        |
        v
   PASS / FAIL

   A mutation MUST be deterministic.  A runner MUST NOT modify fields
   that are outside the mutation specified by the vector.

5.  Expected Outcomes

   A vector MAY expect ALLOW, DENY, or INDETERMINATE.  A vector MAY also
   expect one or more standardized failure codes.

   INDETERMINATE MUST NOT be treated as equivalent to ALLOW for
   conformance purposes.

6.  Required Coverage

   The corpus MUST include vectors covering at least:

   *  JCS canonicalization and rejection of unsupported values;

   *  Ed25519 positive and negative signature verification;

   *  tampered-envelope rejection;

   *  key-substitution rejection;

   *  identity binding independent from a self-supplied key;

Watts                     Expires 5 March 2027                  [Page 4]
Internet-Draft                 AID-1-TEST                 September 2026

   *  capability, resource, state, time, and delegation enforcement;

   *  revoked and unavailable revocation states;

   *  duplicate nonce and action replay;

   *  forged or untrusted external attestation;

   *  key rotation, overlap, supersession, and historical validity;

   *  audit-chain deletion, reordering, and mutation detection; and

   *  confused-deputy, audience-confusion, cross-repository replay,
      delegation-escalation, and stale-credential cases.

7.  Replay and Architectural Boundary Cases

   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.

7.1.  R5: AID-1 Valid, D6 Reject

   R5 is a mandatory conformance invariant.

   AID-1 verification: VALID
   D6 scientific-admissibility decision: REJECT

   An implementation MUST pass R5 by preserving the distinction between
   AID-1 identity/provenance verification and downstream scientific
   admissibility.

   A provider or integration that automatically converts successful
   AID-1 verification into downstream D6 acceptance is non-conformant.

8.  Provider Independence

   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.

   Provider-specific implementation details MUST NOT alter the expected
   outcome of any provider-independent vector.

Watts                     Expires 5 March 2027                  [Page 5]
Internet-Draft                 AID-1-TEST                 September 2026

9.  Reference Vector Runner

   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.

   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.

10.  Release Gates

   An implementation MUST NOT claim completion of the AID-1 v1 security
   conformance profile until the required gates pass.  These gates
   include:

   1.   JCS conformance and rejection tests;

   2.   Ed25519 positive, negative, tampered-envelope, and key-
        substitution vectors;

   3.   identity-binding separation from self-supplied key material;

   4.   independent authorization checks for capability, resource,
        state, time, and delegation;

   5.   revocation and unavailable-registry handling;

   6.   replay resistance;

   7.   external attestation verification;

   8.   rotation and historical-verification behavior;

   9.   audit-integrity checks; and

   10.  adversarial trust-boundary vectors.

11.  Security Considerations

   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.

Watts                     Expires 5 March 2027                  [Page 6]
Internet-Draft                 AID-1-TEST                 September 2026

   Test providers MUST NOT be permitted to alter vector expectations
   during execution.  CI systems SHOULD pin the corpus revision used for
   a conformance claim.

12.  Privacy Considerations

   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.

13.  IANA Considerations

   This document requests no IANA actions.

14.  Publication and Versioning

   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.

15.  Normative References

   [AID1]     Watts, D., "AID-1: A Cryptographically Bindable Identity
              and Provenance Architecture for AI Systems", Work in
              Progress, Internet-Draft, draft-watts-ai-identity-00,
              September 2026, <https://datatracker.ietf.org/doc/html/
              draft-watts-ai-identity-00>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8785>.

Author's Address

   Deonte Watts
   Independent Researcher
   Email: deonte@goodshyt.fun
   URI:   https://orcid.org/0009-0005-8586-3650

Watts                     Expires 5 March 2027                  [Page 7]