AID-1: A Cryptographically Bindable Identity and Provenance Architecture for AI Systems

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

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 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.¶

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

5. Core AID-1 Objects

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;
}

Ed25519.Sign(sk, JCS(envelope))

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";
}

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;
}

export type Operation =
  | "execute"
  | "delegate"
  | "modify"
  | "publish"
  | "read-evidence"
  | "create-credential";

export interface AuthorizationDecision {
  effect: "allow" | "deny" | "indeterminate";
  operation: Operation;
  reasons: string[];
  evaluatedAt: string;
}

export type ClaimSource =
  | "signed-by-key"
  | "github-oidc"
  | "git-object"
  | "artifact-digest"
  | "external-attestation"
  | "self-asserted";

interface ProvenanceClaim<T> {
  value: T;
  source: ClaimSource;
  verified: boolean;
  evidenceRef?: string;
  verifier?: string;
  checkedAt?: string;
}

6. Canonicalization and Hashing

AID-1 signed JSON objects MUST use RFC 8785 JCS 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.¶

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.¶

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.¶
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

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.¶

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:¶

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.¶

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".¶

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.¶

Author's Address