Internet Engineering Task Force D. Watts Internet-Draft Independent Researcher Intended status: Informational 9 October 2026 Expires: 12 April 2027 AID-1: A Cryptographically Bindable Identity and Provenance Architecture for AI Systems draft-watts-ai-identity-00 Abstract This document specifies AID-1, a provider-independent architecture for representing and verifying cryptographically bindable identity, delegation, authorization, action evidence, execution attestation, provenance, and governance information associated with AI systems and AI-mediated actions. AID-1 intentionally separates signature validity, identity binding, authority, execution evidence, provenance, and downstream admissibility. The specification defines trust domains, signed envelopes, external key resolution, delegation credentials, authorization decisions, temporal and revocation checks, replay protection, typed provenance claims, and a deterministic verification order with ALLOW, DENY, and INDETERMINATE outcomes. 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 12 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Watts Expires 12 April 2027 [Page 1] Internet-Draft AID-1 October 2026 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 4. Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Key Binding . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Delegation . . . . . . . . . . . . . . . . . . . . . . . 4 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 4 4.5. Action Evidence . . . . . . . . . . . . . . . . . . . . . 4 4.6. Execution Attestation . . . . . . . . . . . . . . . . . . 5 4.7. Governance . . . . . . . . . . . . . . . . . . . . . . . 5 5. Core AID-1 Objects . . . . . . . . . . . . . . . . . . . . . 5 5.1. Signed Envelope . . . . . . . . . . . . . . . . . . . . . 5 5.2. Trusted Key Record . . . . . . . . . . . . . . . . . . . 6 5.3. Delegation Credential . . . . . . . . . . . . . . . . . . 6 5.4. Authorization Decision . . . . . . . . . . . . . . . . . 6 5.5. Typed Provenance Claims . . . . . . . . . . . . . . . . . 7 6. Canonicalization and Hashing . . . . . . . . . . . . . . . . 7 7. Temporal Validation . . . . . . . . . . . . . . . . . . . . . 8 8. Revocation and Key Status . . . . . . . . . . . . . . . . . . 8 9. Replay Protection . . . . . . . . . . . . . . . . . . . . . . 9 10. External Attestation . . . . . . . . . . . . . . . . . . . . 9 11. Verification Algorithm . . . . . . . . . . . . . . . . . . . 9 12. Decision Semantics . . . . . . . . . . . . . . . . . . . . . 10 13. Failure Taxonomy . . . . . . . . . . . . . . . . . . . . . . 10 14. Wire Schemas . . . . . . . . . . . . . . . . . . . . . . . . 11 15. Explicit Downstream Admissibility Boundary . . . . . . . . . 11 16. Operational State and Authorization . . . . . . . . . . . . . 12 17. Security Considerations . . . . . . . . . . . . . . . . . . . 12 18. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 20. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 13 21. Implementation Independence . . . . . . . . . . . . . . . . . 14 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 23. Normative References . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Watts Expires 12 April 2027 [Page 2] Internet-Draft AID-1 October 2026 1. Introduction AI systems increasingly participate in software development, content production, scientific workflows, operational control, and autonomous or semi-autonomous execution. Existing identifiers such as model names, deployment IDs, API credentials, or embedded public keys do not by themselves establish trusted identity, delegated authority, execution context, or provenance. AID-1 defines a compositional verification architecture in which a cryptographic signature is only one element of a larger trust chain. The architecture is intentionally provider-independent and does not require any specific hardware root of trust. The core doctrine is: Identity != Authority != Action Evidence A conforming implementation MUST preserve this separation. 2. Conventions and Terminology 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] and [RFC8174] when, and only when, they appear in all capitals, as shown here. Actor An identity, human or machine, that is represented as performing or requesting an action. Trusted Key Registry An external trust source that resolves a key identifier to key material and binding status. Delegation A signed grant permitting one subject to exercise specified capabilities on behalf of another subject. Authorization A policy decision determining whether an operation is permitted for a subject, resource, audience, and time. Attestation Independently verifiable evidence about an execution environment, workflow, or identity assertion. Provenance Evidence describing the origin, transformation, integrity, or lineage of an artifact or action. Watts Expires 12 April 2027 [Page 3] Internet-Draft AID-1 October 2026 3. Design Principles AID-1 implementations MUST preserve the following non-equivalences: Signature validity != identity proof Identity proof != delegation Delegation != authorization Authorization != execution attestation Execution attestation != artifact truth Artifact integrity != semantic correctness Successful verification in one trust domain MUST NOT be treated as implicit success in another trust domain. 4. Trust Domains 4.1. Identity The identity domain answers "Who is the actor?" An implementation MUST NOT treat self-asserted identity metadata as sufficient trusted identity evidence unless policy explicitly allows that trust model. 4.2. Key Binding The key-binding domain answers "Which trusted key represents the actor?" A public key supplied inside the artifact being verified MUST NOT be treated as its own trust anchor. 4.3. Delegation The delegation domain answers "May this delegate act for the issuer?" Delegation MUST be represented and validated independently from the underlying signature. 4.4. Authorization The authorization domain answers "May this actor perform this operation on this resource now?" Authorization SHOULD bind at least the operation, resource, subject, audience, time, delegation state, and revocation state. 4.5. Action Evidence Action evidence identifies what was requested or performed, including content-addressed inputs, outputs, commit identifiers, environment identifiers, and other execution-relevant context. Watts Expires 12 April 2027 [Page 4] Internet-Draft AID-1 October 2026 4.6. Execution Attestation Execution attestation answers "Where and under what trusted workflow was the action executed?" Claims copied into a signed payload remain signer assertions unless independently verified against the relevant attestation authority. 4.7. Governance Governance determines whether evidence is presently accepted under revocation, rotation, supersession, retention, and audit policy. 5. Core AID-1 Objects 5.1. Signed Envelope export interface SignedEnvelopeV1 { schema: "miseos.signed-envelope/v1"; algorithm: "Ed25519"; keyId: string; payloadDigest: { algorithm: "sha256"; value: string; }; issuedAt: string; expiresAt?: string; nonce: string; audience: string; actionId: string; authorizationId: string; delegationId?: string; } export interface DetachedSignatureV1 { envelope: SignedEnvelopeV1; signature: string; } A signer MUST sign the JSON Canonicalization Scheme (JCS) representation of the envelope as specified in [RFC8785]. Ed25519 is specified in [RFC8032]. The signature operation is: Ed25519.Sign(sk, JCS(envelope)) The unsigned transport representation MAY include informational public key material, but a verifier MUST resolve keyId through an independent trusted source before treating the key as trusted. Watts Expires 12 April 2027 [Page 5] Internet-Draft AID-1 October 2026 5.2. Trusted Key Record export interface TrustedKeyRecord { keyId: string; subjectId: string; publicKeyPem: string; fingerprintSha256: string; status: "active" | "rotated" | "revoked" | "suspended"; validFrom: string; validUntil?: string; bindingMethod: | "github-oidc" | "github-ssh" | "github-gpg" | "organization-registry" | "manual-root-verification"; } If the required registry cannot be consulted, a verifier MUST NOT return ALLOW solely on the basis of an artifact-supplied key. 5.3. Delegation Credential export interface DelegationCredentialV1 { schema: "miseos.delegation/v1"; delegationId: string; issuerSubjectId: string; delegateSubjectId: string; capabilities: string[]; resourcePatterns: string[]; notBefore: string; expiresAt: string; revocationId: string; audience: string; maxDelegationDepth: number; } 5.4. Authorization Decision Watts Expires 12 April 2027 [Page 6] Internet-Draft AID-1 October 2026 export type Operation = | "execute" | "delegate" | "modify" | "publish" | "read-evidence" | "create-credential"; export interface AuthorizationDecision { effect: "allow" | "deny" | "indeterminate"; operation: Operation; reasons: string[]; evaluatedAt: string; } 5.5. Typed Provenance Claims export type ClaimSource = | "signed-by-key" | "github-oidc" | "git-object" | "artifact-digest" | "external-attestation" | "self-asserted"; interface ProvenanceClaim { value: T; source: ClaimSource; verified: boolean; evidenceRef?: string; verifier?: string; checkedAt?: string; } Implementations SHOULD distinguish self-asserted values from independently verified evidence. 6. Canonicalization and Hashing AID-1 signed JSON objects MUST use JCS as specified in [RFC8785] prior to signing or signature verification. Implementations MUST reject non-JSON values before canonicalization. Rejected values include undefined values, NaN, infinities, Date instances, Map, Set, Buffer, typed arrays, class instances, accessors, and cyclic structures. Watts Expires 12 April 2027 [Page 7] Internet-Draft AID-1 October 2026 Binary content SHOULD be represented using explicit encodings or, preferably, by content digests. export function hashChain(values: JsonValue[]): string { return sha256Jcs({ schema: "miseos.hash-sequence/v1", values, }); } 7. Temporal Validation Time values used for authority-bearing decisions MUST be unambiguous instants. Implementations SHOULD require canonical UTC timestamps. export function parseInstant(value: string): Date | null { const date = new Date(value); if ( !Number.isFinite(date.getTime()) || date.toISOString() !== value ) { return null; } return date; } Unless policy specifies a bounded clock-skew allowance, the required relation is: notBefore <= issuedAt <= verificationTime <= expiresAt Invalid or unparsable timestamps MUST NOT fail open. 8. Revocation and Key Status export interface RevocationRegistry { getStatus( revocationId: string, at: string, ): Promise<"valid" | "revoked" | "unknown">; } For authority-bearing operations, a required revocation status of "unknown" MUST result in either DENY or INDETERMINATE according to policy. It MUST NOT result in ALLOW. Watts Expires 12 April 2027 [Page 8] Internet-Draft AID-1 October 2026 Historical verification SHOULD distinguish evidence that was valid when issued and later revoked from evidence that had already been revoked at the claimed execution time. 9. Replay Protection Authority-bearing AID-1 envelopes MUST include a nonce, stable actionId, audience, and bounded validity period. Where policy requires single-use authorization, the verifier MUST reject a previously consumed nonce/action pair. Implementations SHOULD bind replay protection to the relevant repository, workflow, deployment, environment, or equivalent execution scope when such context exists. 10. External Attestation When GitHub OIDC or another external attestation mechanism is required, a verifier MUST validate the attestation against the appropriate issuer, expected audience, trusted workflow or workload identity policy, and any required repository, workflow reference, workflow SHA, commit SHA, triggering actor, environment, and subject constraints. Merely copying those values into an AID-1 signed object proves only that the signer asserted them. It does not independently verify the attestation. 11. Verification Algorithm A conforming verifier evaluating an authority-bearing AID-1 object MUST perform the following checks in an order that preserves the same security dependencies. An implementation MAY internally optimize checks, provided that no optimization can turn a required failed or unavailable prerequisite into ALLOW. 1. Parse input without coercion. 2. Validate the applicable wire schema. 3. Canonicalize the signed envelope. 4. Resolve keyId through an external trusted source. 5. Verify key status and identity binding. 6. Verify the Ed25519 signature. Watts Expires 12 April 2027 [Page 9] Internet-Draft AID-1 October 2026 7. Verify the payload digest. 8. Verify issuer and audience constraints. 9. Verify external attestation when required. 10. Verify the delegation chain and delegation depth. 11. Verify operation and resource authorization. 12. Verify temporal constraints and clock policy. 13. Verify revocation status. 14. Verify replay constraints. 15. Verify provenance and artifact hashes. 16. Return the final verification decision. 12. Decision Semantics ALLOW Every trust domain required by policy completed successfully. DENY At least one required domain definitively failed. INDETERMINATE No definitive failure has been established, but at least one required verification step could not be completed. INDETERMINATE MUST NOT be interpreted as ALLOW. Examples include: an unavailable revocation registry, which SHOULD yield INDETERMINATE or DENY; an invalid signature, which MUST yield DENY; and a trusted key already revoked at the relevant time, which MUST yield DENY. 13. Failure Taxonomy Watts Expires 12 April 2027 [Page 10] Internet-Draft AID-1 October 2026 export type VerificationFailureCode = | "IDENTITY_BINDING_UNVERIFIED" | "KEY_NOT_TRUSTED" | "KEY_REVOKED" | "KEY_SUSPENDED" | "SIGNATURE_INVALID" | "DELEGATION_MISSING" | "DELEGATION_INVALID" | "DELEGATION_EXPIRED" | "DELEGATION_DEPTH_EXCEEDED" | "AUTHORIZATION_DENIED" | "TEMPORAL_INVALID" | "REVOCATION_UNKNOWN" | "REPLAY_DETECTED" | "AUDIENCE_MISMATCH" | "ATTESTATION_UNVERIFIED" | "PROVENANCE_MISMATCH" | "SCHEMA_INVALID" | "DIGEST_MISMATCH"; Implementations SHOULD return structured per-domain verification status and MAY include additional implementation-specific warnings. 14. Wire Schemas AID-1 deployments SHOULD maintain versioned machine-readable schemas for at least the following object families: schemas/ developer-identity.v1.schema.json trusted-key-record.v1.schema.json signature-envelope.v1.schema.json delegation-credential.v1.schema.json authorization-snapshot.v1.schema.json provenance.v1.schema.json revocation-event.v1.schema.json Schema validation is structural. Cross-object trust and policy constraints MUST be enforced by conformance logic and not assumed from schema validity alone. 15. Explicit Downstream Admissibility Boundary AID-1 verifies identity, authority-related evidence, and provenance according to the policy applied by an AID-1 verifier. It does not determine scientific truth or downstream scientific admissibility. Watts Expires 12 April 2027 [Page 11] Internet-Draft AID-1 October 2026 The following conformance boundary is normative and is referred to as replay case R5 by the companion AID-1 conformance specification: R5 AID-1 verification: VALID Downstream D6 admissibility: REJECT An AID-1 implementation MUST NOT infer downstream scientific admissibility solely from successful AID-1 verification. A downstream admissibility system MUST remain free to reject evidence that is structurally and cryptographically valid under AID-1. 16. Operational State and Authorization Operational state MAY constrain authorization, but state alone MUST NOT be treated as a complete permission decision. A reference state matrix is: +===========+=================================================+ | State | Effect | +===========+=================================================+ | SAFE | Policy-dependent. | +-----------+-------------------------------------------------+ | QUIESCING | No new work or delegation; restricted | | | modification; evidence reads allowed by policy. | +-----------+-------------------------------------------------+ | ISOLATED | No execute, delegate, modify, or publish; | | | restricted evidence access. | +-----------+-------------------------------------------------+ | FORENSIC | No action; evidence access limited to | | | authorized investigators. | +-----------+-------------------------------------------------+ | DENY_NEW | No new work, delegations, or changes; evidence | | | access policy-dependent. | +-----------+-------------------------------------------------+ | REVOKED | No action; audit-only access. | +-----------+-------------------------------------------------+ Table 1: Reference State Matrix 17. Security Considerations The principal security risk addressed by AID-1 is trust-domain collapse: treating one valid signal, especially a cryptographic signature, as sufficient proof of identity, authority, execution environment, provenance, or semantic correctness. Watts Expires 12 April 2027 [Page 12] Internet-Draft AID-1 October 2026 Implementations MUST defend against key substitution, confused-deputy attacks, audience confusion, cross-resource replay, delegation escalation, stale credentials, forged attestations, invalid temporal data, unavailable revocation infrastructure, and artifact mutation. Implementations SHOULD use constant-time comparison primitives for security-sensitive digest comparisons where applicable. Audit systems SHOULD be append-only or cryptographically chained so that deletion, reordering, and mutation can be detected. 18. Privacy Considerations AID-1 may carry identifiers, repository information, workflow context, public keys, delegation relationships, execution metadata, and provenance links. These can enable correlation across systems. Implementations SHOULD minimize collected identity and network context, SHOULD avoid embedding unnecessary personal information, SHOULD apply data-retention limits, and SHOULD separate public provenance evidence from sensitive operational metadata. Pseudonymous identifiers MAY be used when policy does not require disclosure of a civil identity, provided that trusted binding and revocation requirements remain enforceable. 19. IANA Considerations This document requests no IANA actions at this time. Future revisions may define registries for AID-1 algorithms, claim sources, failure codes, schema identifiers, or attestation types if interoperability experience demonstrates that shared registries are required. 20. Conformance Implementations claiming AID-1 conformance MUST preserve the trust- domain boundaries, decision semantics, external key-resolution rule, fail-closed or indeterminate handling of unavailable required trust services, and the downstream admissibility boundary defined in this document. Provider-independent conformance vectors and the reference execution model are defined in the companion document "AID-1 Provider- Independent Conformance Requirements". Watts Expires 12 April 2027 [Page 13] Internet-Draft AID-1 October 2026 21. Implementation Independence AID-1 does not mandate TPM, TEE, HSM, secure enclave, or software- only key storage. Implementations MAY use such technologies, but provider conformance is determined by externally observable AID-1 behavior rather than implementation mechanism. 22. Acknowledgements This document reflects an architecture developed to keep identity, authority, action evidence, attestation, provenance, governance, and downstream admissibility as independently testable trust domains. 23. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, BCP 14, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . Author's Address Deonte Watts Independent Researcher Email: deonte@goodshyt.fun URI: https://orcid.org/0009-0005-8586-3650 Watts Expires 12 April 2027 [Page 14]