Internet Engineering Task Force D. O. Watts Internet-Draft GoodShyt Group Inc. Intended status: Informational 30 October 2026 Expires: 3 May 2027 AID-1 Provider-Independent Conformance Requirements and Test-Vector Model draft-watts-ai-identity-conformance-01 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 3 May 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 3 May 2027 [Page 1] Internet-Draft AID-1-TEST October 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Conformance Requirements . . . . . . . . . . . . . . . . . . 3 4. Machine-Readable Corpus . . . . . . . . . . . . . . . . . . . 3 5. Vector Execution Model . . . . . . . . . . . . . . . . . . . 4 6. Expected Outcomes . . . . . . . . . . . . . . . . . . . . . . 5 7. Required Coverage . . . . . . . . . . . . . . . . . . . . . . 5 8. Replay and Architectural Boundary Cases . . . . . . . . . . . 6 8.1. R5: AID-1 Valid, D6 Reject . . . . . . . . . . . . . . . 6 9. Provider Independence . . . . . . . . . . . . . . . . . . . . 6 10. Reference Vector Runner . . . . . . . . . . . . . . . . . . . 6 11. Release Gates . . . . . . . . . . . . . . . . . . . . . . . . 7 12. Security Considerations . . . . . . . . . . . . . . . . . . . 7 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 15. Publication and Versioning . . . . . . . . . . . . . . . . . 8 16. Normative References . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Changes since -00 . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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. 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. Watts Expires 3 May 2027 [Page 2] Internet-Draft AID-1-TEST October 2026 3. 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. 4. 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. Watts Expires 3 May 2027 [Page 3] Internet-Draft AID-1-TEST October 2026 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. 5. Vector Execution Model A reference runner SHOULD evaluate each vector using the following conceptual process: Watts Expires 3 May 2027 [Page 4] Internet-Draft AID-1-TEST October 2026 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. 6. 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. 7. 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; * capability, resource, state, time, and delegation enforcement; * revoked and unavailable revocation states; Watts Expires 3 May 2027 [Page 5] Internet-Draft AID-1-TEST October 2026 * 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. 8. 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. 8.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. 9. 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. 10. 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. Watts Expires 3 May 2027 [Page 6] Internet-Draft AID-1-TEST October 2026 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. 11. 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. 12. 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. Test providers MUST NOT be permitted to alter vector expectations during execution. CI systems SHOULD pin the corpus revision used for a conformance claim. Watts Expires 3 May 2027 [Page 7] Internet-Draft AID-1-TEST October 2026 13. 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. 14. IANA Considerations This document requests no IANA actions. 15. 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. 16. Normative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Appendix A. Changes since -00 This section is to be removed before publishing as an RFC. Editorial and tooling-conformance changes only; no technical content was changed. * Added BCP 14 Requirements Language section (document uses uppercase requirement keywords without the boilerplate; idnits error) * Added RFC 2119 reference entry * Added RFC 8174 reference entry * Removed unreferenced bibliography entries (xml2rfc/idnits "unused reference"): AID1, RFC8785 Watts Expires 3 May 2027 [Page 8] Internet-Draft AID-1-TEST October 2026 * Normalized author metadata (full name with ASCII form, initials, organization GoodShyt Group Inc., San Francisco CA postal, email, ORCID URI) * Updated document date and revision number. Author's Address Deonté O'dell Watts GoodShyt Group Inc. San Francisco, CA United States of America Email: deonte@goodshyt.fun URI: https://orcid.org/0009-0005-8586-3650 Watts Expires 3 May 2027 [Page 9]